Hi all :)
I''ve tested this and having a cpufreq that slows down the CPU
affects the rate of HTB. My ondemand cpufreq governor scales down the
CPU frequency about 40% and this is more or less the slowdown the rate
suffers, 40%.
Any known way of dealing with this without having to disable
cpufreq?
Thanks in advance :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It''s my PC and I''ll cry if I want to... RAmen!
Hi, DervishD DervishD wrote:> Hi all :) > > I''ve tested this and having a cpufreq that slows down the CPU > affects the rate of HTB. My ondemand cpufreq governor scales down the > CPU frequency about 40% and this is more or less the slowdown the rate > suffers, 40%. > > Any known way of dealing with this without having to disable > cpufreq? > > Thanks in advance :) > > Ra?l N??ez de Arenas Coronado >What kernel-version do you use? In 2.6.22 another timer is used for psched. Maybe NO_HZ could interfere on this issue too. Bye, Andreas.
Hi Andreas :) * Andreas Mueller <andreas@stapelspeicher.org> dixit:> DervishD wrote: > > Hi all :) > > > > I''ve tested this and having a cpufreq that slows down the CPU > > affects the rate of HTB. My ondemand cpufreq governor scales down the > > CPU frequency about 40% and this is more or less the slowdown the rate > > suffers, 40%. > > > > Any known way of dealing with this without having to disable > > cpufreq? > > > > What kernel-version do you use?Sorry, I forgot to include that documentation... I''m using 2.6.20.14, and I was waiting until 2.6.22 stable branch reached at least 10 (I''m tired of regressions with all 2.6.x kernels, so I try to avoid updating if possible).> In 2.6.22 another timer is used for psched.I''ll give it a try, then, but not before 2.6.22.10 at least.> Maybe NO_HZ could interfere on this issue too.Currently I have CONFIG_HZ_1000=y and CONFIG_HZ=1000, and no tickless idle since that feature was introduced in a later kernel. Probably the problem is the shared timer and I will have to use 2.6.22 kernel to have it if I dare upgrading ;)) Thanks for the information, Andreas :) Ra?l N??ez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It''s my PC and I''ll cry if I want to... RAmen!
On Tue, 28 Aug 2007 09:47:38 +0200 DervishD <lartc@dervishd.net> wrote:> I''ve tested this and having a cpufreq that slows down the CPU > affects the rate of HTB. My ondemand cpufreq governor scales down the > CPU frequency about 40% and this is more or less the slowdown the rate > suffers, 40%.This is expected behaviour when CONFIG_NET_SCH_CLK_CPU is defined: Say Y here if you want to use the CPU''s cycle counter as clock source. This is a cheap and high resolution clock source, but on some architectures it is not synchronized on all processors and doesn''t handle cpu clock frequency changes.> Any known way of dealing with this without having to disable > cpufreq?Yes, specify a different clock source in your kernel configuration. --atj
Hi Adam :) * Adam James <ad@heliosphan.co.uk> dixit:> On Tue, 28 Aug 2007 09:47:38 +0200 > DervishD <lartc@dervishd.net> wrote: > > > I''ve tested this and having a cpufreq that slows down the CPU > > affects the rate of HTB. My ondemand cpufreq governor scales down the > > CPU frequency about 40% and this is more or less the slowdown the rate > > suffers, 40%. > > This is expected behaviour when CONFIG_NET_SCH_CLK_CPU is defined:Sh*t! I thought I changed that when I turned on cpufreq and set it to jiffies, but I''ve seen my /proc/kconfig.gz and it''s not true, I have CONFIG_NET_SCH_CLK_CPU :(((( Sorry for the noise, I''m embarrassed... And thanks a lot for your help. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It''s my PC and I''ll cry if I want to... RAmen!
I wonder if somebody has got good results (accurate shaping) using 2.6.22?
I am testing with 2.6.22.1, and I haven''t been able to get accurate
shaping.
For instance, I tried:
$TC qdisc add dev eth0 root handle 1: htb default 1
$TC class add dev eth0 parent 1: classid 1:1 htb
rate 100000kbit ceil 100000kbit burst 24k cburst 24k
$TC class add dev eth0 parent 1:1 classid 1:10 htb
rate 20000kbit ceil 20000kbit burst 24k cburst 24k
and class 1:10 shapes the traffic to 19900kbit instead of 20000kbit
(bandwidth tests made with ftp and iperf)
My corresponding kernel settings are:
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HPET_TIMER=y
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_CPU_FREQ is not set
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_FIFO=y
Notice that in 1.26.22 there are new patches for Clock Source:
http://lists.openwall.net/netdev/2007/03/16/22
"These patches convert the packet schedulers to use ktime as only clock
source and kill off the manual clock source selection. Additionally all
packet schedulers are converted to use hrtimer-based Watchdogs, greatly
increasing scheduling precision."
Regards,
Mario Antonio
On Wed, 29 Aug 2007, Mario Antonio Garcia wrote:> I wonder if somebody has got good results (accurate shaping) using 2.6.22? > > I am testing with 2.6.22.1, and I haven''t been able to get accurate shaping. > For instance, I tried: > $TC qdisc add dev eth0 root handle 1: htb default 1 > $TC class add dev eth0 parent 1: classid 1:1 htb > rate 100000kbit ceil 100000kbit burst 24k cburst 24k > $TC class add dev eth0 parent 1:1 classid 1:10 htb > rate 20000kbit ceil 20000kbit burst 24k cburst 24k > > and class 1:10 shapes the traffic to 19900kbit instead of 20000kbit > (bandwidth tests made with ftp and iperf)That seems pretty close. What values do you get with older kernels?
I used to get an average of 18900kbit. My hope was that these new patches would bring better accuracy. Notice the 24 cburst. I am just trying to compensate the inaccuracy this way. If I remove the cburst, obviously the shape rate I get goes down. Perhaps I am missing something. I am just a novice trying to get exact bandwidth shaping. I have tested all the clock source types with no good results. Regards, Mario Antonio ----- Original Message ----- From: "Patrick McHardy" <kaber@trash.net> To: "Mario Antonio Garcia" <dino@webjogger.net> Cc: <lartc@mailman.ds9a.nl> Sent: Friday, August 31, 2007 5:43 AM Subject: Re: [LARTC] Clock Source Kernel settings in 2.6.22> On Wed, 29 Aug 2007, Mario Antonio Garcia wrote: > >> I wonder if somebody has got good results (accurate shaping) using >> 2.6.22? >> >> I am testing with 2.6.22.1, and I haven''t been able to get accurate >> shaping. >> For instance, I tried: >> $TC qdisc add dev eth0 root handle 1: htb default 1 >> $TC class add dev eth0 parent 1: classid 1:1 htb >> rate 100000kbit ceil 100000kbit burst 24k cburst 24k >> $TC class add dev eth0 parent 1:1 classid 1:10 htb >> rate 20000kbit ceil 20000kbit burst 24k cburst 24k >> >> and class 1:10 shapes the traffic to 19900kbit instead of 20000kbit >> (bandwidth tests made with ftp and iperf) > > > That seems pretty close. What values do you get with older kernels? > > > >
[Please keep me in CC/To, I don''t read lartc often] Mario Antonio Garcia wrote:> I used to get an average of 18900kbit. > My hope was that these new patches would bring better accuracy.Well, you''re up from 94.5% to 99.95%, so they seem to do :)> Notice the 24 cburst. I am just trying to compensate the inaccuracy > this way. If I remove the cburst, obviously the shape rate I get goes > down. > > Perhaps I am missing something. I am just a novice trying to get > exact bandwidth shaping. I have tested all the clock source types with > no good results.A couple of comments: - The patches so far only improve things on x86 - Try to test using UDP (not sure if you did) or simply a ping flood, TCP is not ideal. - iproute calculates burst values automatically. With the higher precision clock source you can use a smaller value (also done automatically if you don''t specify them). - HFSC is more precise than HTB (and not the least more complicated to configure if you use only linear service curves)