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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
