pkt_sched.h only handles 100Hz and 1024Hz sys ticks

From: Chris Smale (chris.smale@ueccs.co.uk)
Date: Wed Jul 30 2003 - 08:15:23 EST


[1.] One line summary of the problem:
'include/net/pkt_sched.h' only handles the cases where HZ is 100 or 1024.

[2.] Full description of the problem/report:
I have no problems shaping network traffic in vanilla 2.4 kernels --
everything works as I expect it to.
I had problems with the Redhat8 binary kernel and the 2.6.0-test1-bk2 kernel
(which is the only version of 2.5/6 I have used). Traffic shaping wouldn't
work in the same way it would for the 2.4 vanilla kernels.

The common factor between the redhat8 and the 2.6 kernel, as I saw it, is that
the system tick is not 100Hz - 512Hz for the redhat8 and 1000Hz for the 2.6
kernel.

Forgetting the redhat8 kernel and looking at the 2.6 kernel (though I believe
it to be the same issue); the traffic shaping filters use the
PSCHED_GET_TIME(...) #define, as defined in 'include/net/pkt_sched.h'. The
value reported by this define depends on a fudge factor of 'PSCHED_JSCALE'
which is defined as (all still in pkt_sched.h);

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

So for both the kernels PSCHED_JSCALE will be 0. If I add my own fudge
factors, ie 1000Hz -> PSCHED_JSCALE 10 and 512Hz -> PSCHED_JSCALE 11 and
recompile, the traffic shaping seems to work as I would expect it to.

It would seem more sensible to check for ranges for HZ and define
PSCHED_JSCALE appropriately. See below.

[3.] Keywords (i.e., modules, networking, kernel):
networking, traffic shaping

[4.] Kernel version (from /proc/version):
Linux version 2.6.0-test1-bk2 (root@laetitia) (gcc version 3.2 20020903 (Red
Hat Linux 8.0 3.2-7)) #4 Tue Jul 29 16:10:26 BST 2003

[5.] Output of Oops.. message (if applicable) with symbolic information
     resolved (see Documentation/oops-tracing.txt)
Not relevant.

[6.] A small shell script or example program which triggers the
     problem (if possible)
Should be fairly self-evident that there is an issue with the code as it
stands.

[7.] Environment
Not relevant.

[7.1.] Software (add the output of the ver_linux script here)
Linux laetitia 2.6.0-test1-bk2 #4 Tue Jul 29 16:10:26 BST 2003 i686 i686 i386
GNU/Linux

Gnu C 3.2
Gnu make 3.79.1
util-linux 2.11z
mount 2.11z
e2fsprogs 1.27
jfsutils 1.0.17
reiserfsprogs 3.6.2
pcmcia-cs 3.1.31
quota-tools 3.06.
PPP 2.4.1
isdn4k-utils 3.1pre4
nfs-utils 1.0.1
Linux C Library 2.2.93
Dynamic linker (ldd) 2.2.93
Procps 3.1.11
Net-tools 1.60
Kbd 1.06
Sh-utils 2.0.12
Modules Loaded vfat fat nfs lockd sunrpc ntfs sch_sfq sch_htb
i810_audio ac97_codec soundcore e100 mousedev hid usbcore rtc

[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.00GHz
stepping : 4
cpu MHz : 1995.087
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 3932.16

[7.3.] Module information (from /proc/modules):
vfat 13056 1 - Live 0xd08ae000
fat 41632 1 vfat, Live 0xd08b6000
nfs 144300 1 - Live 0xd0944000
lockd 57168 2 nfs, Live 0xd08da000
sunrpc 116676 5 nfs,lockd, Live 0xd08fc000
ntfs 87440 1 - Live 0xd08c3000
sch_sfq 4608 3 - Live 0xd088b000
sch_htb 22272 1 - Live 0xd08a2000
i810_audio 26624 0 - Live 0xd0880000
ac97_codec 17024 1 i810_audio, Live 0xd080c000
soundcore 7104 1 i810_audio, Live 0xd0819000
e100 58756 0 - Live 0xd0892000
mousedev 7508 1 - Live 0xd0809000
hid 23296 0 - Live 0xd0812000
usbcore 95316 2 hid, Live 0xd0826000
rtc 10660 0 - Live 0xd0805000

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
Not relevant.
[7.5.] PCI information ('lspci -vvv' as root)
Not relevant.
[7.6.] SCSI information (from /proc/scsi/scsi)
Not relevant.
[7.7.] Other information that might be relevant to the problem
       (please look in /proc and include all information that you
       think to be relevant):

[X.] Other notes, patches, fixes, workarounds:

Maybe the following code snippet would be more appropriate? I adapted it from
the old SHIFT_HZ code.

        #if HZ >= 48 && HZ < 96
        #define PSCHED_JSCALE 14
        #elif HZ >= 96 && HZ < 192
        #define PSCHED_JSCALE 13
        #elif HZ >= 192 && HZ < 384
        #define PSCHED_JSCALE 12
        #elif HZ >= 384 && HZ < 768
        #define PSCHED_JSCALE 11
        #elif HZ >= 768 && HZ < 1536
        #define PSCHED_JSCALE 10
        #else
        #error Invalid Value of HZ for pkt_sched
        #endif

Cheers,
Chris Smale

-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html



This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:02 EST