Re: [LARTC] HTB doesn't give me the promised rate: cpufreq?

From: Andy Furniss <lists@andyfurniss.entadsl.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HTB doesn't give me the promised rate: cpufreq?
Date: Mon, 27 Aug 2007 20:20:51 +0000	[thread overview]
Message-ID: <46D33223.20508@andyfurniss.entadsl.com> (raw)
In-Reply-To: <20070826221407.GA1944@DervishD>

DervishD wrote:
>     Hi all :)
> 
>     I've been using a tc setup for almost two years, but at some point
> (probably when I switched to kernel 2.6.x, but I'm not sure) it has
> started making something very weird.
> 
>     For a certain class, the rate is 125000bit and the ceil is
> 270000bit, but the fastest rate I get is about 75-80000bit, instead of
> the "promised" 125000, *with no other traffic in the device*.
> 
>     If I disable tc entirely, the upload rate is more than 300000bit (a
> little below the line capacity, which is 320000bit), but as soon as tc
> is enabled again, the upload speed drops again to 75-80kbit. There is no
> other traffic on the device, really, it's just like if the htb couldn't
> queue packets fast enough :???
> 
>     I've thought that the culprit may be cpufreq. I have cpufreq scaling
> activated, and cpufreq reduces the clock speed from 1800MHz to 1000MHz
> when the processor is idle. This is more or less the same amount that I
> "lose" in the rate. May this be the problem? How to fix without
> deactivating cpufreq?

Could be - I don't know. Forgetting cpufreq htb can be limited by Hz if 
the burst size is too small.

tc -s -d class ls dev ... should show the size being used.

> 
>     I'm using htb+sqf, and I can post here my tc setup if needed (is
> quite short), including the filters. It should be OK, since it has been
> working for almost two years. Right now I cannot disable cpufreq because
> temperature problems, and I cannot shut down the machine either, so I
> cannot test if cpufreq is the culprit, that's why I'm asking. I haven't
> found anything while googling, either.

If you have perturb too low on sfq the packet reordering it causes could 
make the sender back off too much.

Andy.

> 
>     If anybody has any idea about this problem, please tell. Thanks a
> lot in advance :))
> 
>     Raúl Núñez de Arenas Coronado
> 

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc