[LARTC] Effect of HZ (system tick) on shaping

[LARTC] Effect of HZ (system tick) on shaping

[Chris Smale]

I was asked to write some traffic shaping scripts for a 100mbit ethernet 
connection on an intel P4 machine running redhat 8.0 (I upgraded 'tc' first  
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?idu486 blah, blah...). The 
scripts I normally use and have verified as working against the vanilla 2.4 
series of kernels didn't seem to do any traffic shaping when used against the 
redhat 8.0 kernel (stock 686 binary release kernel). The filters (HTB with 
SFQ leaves) were all in place and I could see the bytes flowing through the 
correct filters, it just wasn't right. Traffic shaped to 10mbit/s was flowing 
through at 94mbit/s no problem.  

I tried a later version of the HTB code (3.12) with the same kernel and the 
problem persisted.

I then recompiled the redhat-8 kernel with the HZ value set at 512 (rh 
default) and also with the value of HZ set at 100, which is the setting the 
vanilla 2.4 series use. The 100Hz version worked fine whereas the problem 
persisted in the 512Hz version.

So I went a bit deeper into the HTB filter (sch_htb.c). It uses a macro 
PSCHED_GET_TIME for timing purposes, which is defined in 
'include/net/pkt_sched.h'.

Looking in 'pkt_sched.h' I see that for my system PSCHED_CLOCK_SOURCE is 
defined as PSCHED_JIFFIES which means that PSCHED_GET_TIME is expressed as;
'#define PSCHED_GET_TIME(stamp) ((stamp) = psched_time_base + (((unsigned 
long)(jiffies-psched_time_mark))<<PSCHED_JSCALE))'

Note the PSCHED_JSCALE fudge factor that has appeared.... and it is defined in 
terms of the system tick (HZ). This fudge factor is defined in the same file 
as;

	#if HZ = 100
	#define PSCHED_JSCALE 13
	#elif HZ = 1024
	#define PSCHED_JSCALE 10
	#else
	#define PSCHED_JSCALE 0
	#endif

So, for my redhat 8 system tick of 512Hz I reckon I am going to be needing a 
fudge factor somewhere between 10 and 13 (not 0 as it would be looking at 
this code) ..... and sure enough if I add in  '#elif HZ = 512 #define 
PSCHED_JSCALE 12' to the above code in 'pkt_sched.h'  and recompile (system 
tick at 512Hz) the traffic shaping works as I would expect it to. 


Now I start to get confused. I've done a fair bit of searching on the web and 
I cannot find anybody else having mentioned this issue -- makes me suspicious 
that I have missed the point somewhere, but I'll plough on for now...


I wanted to see what redhat did in redhat9 to correct this potential 'issue' 
-- It seems that they haven't applied the variable HZ patches to the redhat9 
kernel (that they did for the redhat8 kernels) so that the system tick is 
fixed at 100Hz for a build on an x86 machine. Issue bypassed.

Anyway... 
It then occured to me that the 2.5/6 series of kernels have a default system 
tick of 1000Hz... so do they cope?  I tried out linux-2.6.0-test1-bk2 with 
the HTB filter and it didn't work as I would have expected, ie the problem, 
as I see it, was still there. The 'pkt_sched.h' code is more or less the same 
as I pasted above and when I recompiled 2.6 with an '#elif HZ = 1000 #define 
PSCHED_JSCALE 10' patch in place, the traffic shaping started working as _I_ 
would expect it to. 


For redhat8 I have seen people complain on this list that shaping doesn't work 
as expected, http://mailman.ds9a.nl/pipermail/lartc/2002q4/005680.html is one 
example.

More recently, http://mailman.ds9a.nl/pipermail/lartc/2003q2/008299.html which 
notes that 2.5.68 doesn't seem to work as expected. I don't know what the 
system tick of 2.5.68 is, the 2.5 series hasn't always had a tick of 1000Hz 
and I don't know when the change to 1000Hz was made.


Anybody got any comments?

Cheers,
CS



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/