Federico Giannici wrote:
Geoff Steckel wrote:
I worked on a commercial product based on altq on which a 1KHz clock
was very useful. This used slow (400MHz) Pentium-class CPUs, and the
increase in system overhead over a 100Hz clock was approximately 2%.
Without the fast clock, accurately and consistently managing
bandwidth down to 1% slices was difficult.
We too have problems to obtain an accurate bandwidth management with
many queues (hfsc) with low bandwidth percentages (sometimes a queue
gets almost all bandwidth and other queues starve...)
Do you think that increasing clock could help?
The CPU is an Athlon 1.2 GHz, but CPU usage is quite low (85% idle
time on average). Do you think a faster CPU could help?
Thanks.
Maybe. It depends on your link speed, packet sizes, and queue parameters.
Getting good bandwidth management at low rates has problems if the time
it takes to transmit a MSS packet (say 1500 bytes) is large relative to
the time quota. On a T1 (1.5 megabit) link, a 1500 byte packet takes
approximately 80 milliseconds to transmit. Depending on how the queue
parameters are set, a 1% quota HFSC queue could get a lot more or a lot
less. In this case, increasing the clock resolution won't help. On a
100Mbit link or higher, a fast clock is essential to get good queue
discipline because there's no other way to reliably restart transmission
on an idle link. Another factor which can upset queue discipline is the
output buffer queue length, which if too long can make problems under
some circumstances.
I haven't looked at altq or hfsc code in years, so YMMV.
