Hi all :)
I noticed lately that my traffic control rates were being very slow,
about 40% less than expected, and finally spotted the problem: cpufreq.
Looks like HTB puts buckets according to the requested rate but
assuming that the CPU is running at its default clock or something like
that.
Any way of fixing this without disabling cpufreq?
I'm using kernel 2.6.20.14, Athlon64 1000/1800MHz, HZ=1000 and a
combination of HTB/SFQ in my traffic control.
Thanks a lot 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!
On Tue, 28 Aug 2007 09:51:55 +0200
DervishD <[email protected]> wrote:
> Hi all :)
>
> I noticed lately that my traffic control rates were being very slow,
> about 40% less than expected, and finally spotted the problem: cpufreq.
>
> Looks like HTB puts buckets according to the requested rate but
> assuming that the CPU is running at its default clock or something like
> that.
>
> Any way of fixing this without disabling cpufreq?
>
> I'm using kernel 2.6.20.14, Athlon64 1000/1800MHz, HZ=1000 and a
> combination of HTB/SFQ in my traffic control.
>
> Thanks a lot in advance :)
>
> Raúl Núñez de Arenas Coronado
>
Is the problem configuration of network scheduler clock? In 2.6.20 and earlier, you
could use CPU cycle counter (later kernels only use time of day). So try
switching to jiffies or gettimeofday.
--
Stephen Hemminger <[email protected]>
Hi Stephen :)
* Stephen Hemminger <[email protected]> dixit:
> On Tue, 28 Aug 2007 09:51:55 +0200 DervishD <[email protected]>
> wrote:
> > I noticed lately that my traffic control rates were being very
> > slow, about 40% less than expected, and finally spotted the
> > problem: cpufreq.
>
> Is the problem configuration of network scheduler clock? In 2.6.20 and
> earlier, you could use CPU cycle counter (later kernels only use time
> of day). So try switching to jiffies or gettimeofday.
Yes, the problem is that I'm stupid and I thought I was using
jiffies, but I have CONFIG_NET_SCH_CLK_CPU. I'll rebuild my kernel ASAP
and set the proper value...
Thanks for your help. It's embarrassing I didn't check the clock
source for the packet scheduler...
Sorry for the noise.
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 Aug 28 2007 15:23, Stephen Hemminger wrote:
>> I noticed lately that my traffic control rates were being very slow,
>> about 40% less than expected, and finally spotted the problem: cpufreq.
>>
>> Looks like HTB puts buckets according to the requested rate but
>> assuming that the CPU is running at its default clock or something like
>> that.
>>
>Is the problem configuration of network scheduler clock? In 2.6.20 and earlier, you
>could use CPU cycle counter (later kernels only use time of day). So try
>switching to jiffies or gettimeofday.
This should not have been removed. CPUs with constant_tsc
could still be used with "CPU cycle counter" method.
Jan
--
On Wed, 29 Aug 2007 17:26:24 +0200 (CEST)
Jan Engelhardt <[email protected]> wrote:
>
> On Aug 28 2007 15:23, Stephen Hemminger wrote:
> >> I noticed lately that my traffic control rates were being very slow,
> >> about 40% less than expected, and finally spotted the problem: cpufreq.
> >>
> >> Looks like HTB puts buckets according to the requested rate but
> >> assuming that the CPU is running at its default clock or something like
> >> that.
> >>
> >Is the problem configuration of network scheduler clock? In 2.6.20 and earlier, you
> >could use CPU cycle counter (later kernels only use time of day). So try
> >switching to jiffies or gettimeofday.
>
> This should not have been removed. CPUs with constant_tsc
> could still be used with "CPU cycle counter" method.
>
>
> Jan
It was removed because the core clock subsystem now manages the choice
of CPU clock correctly and should provide the highest resolution possible
on the hardware.
Plus a whole bunch of grotty macro code gets removed. And the math
handling was more standard/simpler.
--
Stephen Hemminger <[email protected]>