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?id=75486 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
