* [BUG?/SCHED] netem and tbf seem to busy wait with some clock sources
@ 2007-02-15 15:40 Lucas Nussbaum
0 siblings, 0 replies; only message in thread
From: Lucas Nussbaum @ 2007-02-15 15:40 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]
Hi,
While experimenting with netem and tbf, I ran into some strange results.
Experimental setup:
tc qdisc add dev eth2 root netem delay 10ms
Linux 2.6.20-rc6 ; HZ=250
I measured the latency using a modified "ping" implementation, to allow
for high frequency measurement (one measure every 0.1ms). I compared the
results using different clock sources.
See http://www-id.imag.fr/~nussbaum/sched/clk-latency.png
The results with CLK_JIFFIES are the ones I expected: one clearly sees
the influence of HZ, with latency varying around 10ms +/- (1/2)*(1000/HZ).
On the other hand, the results with CLK_GETTIMEOFDAY or CLK_CPU don't
seem to be bound to the HZ setting. Looking at the source, I suspect
that netem is actually sort of busy-waiting, by re-setting the timer to
the old value.
I instrumented netem_dequeue to confirm this (see [1]), and
PSCHED_US2JIFFIE(delay)) returns 0, causing the timer to be rescheduled
at the same jiffie. I could see netem_dequeue being called up to 150
times during a jiffie (at HZ=250).
So, my question is: Is this the expected behaviour ? Wouldn't it be
better to set the timer to jiffies + 1 if the delay is 0 ? Or to send
the packet immediately if the delay is 0, instead of waiting ?
I got similar results with tbf (frames being spaced "too well", instead
of bursting).
[1] http://www-id.imag.fr/~nussbaum/sched/netem_dequeue.diff
Thank you,
--
| Lucas Nussbaum PhD student |
| lucas.nussbaum@imag.fr LIG / Projet MESCAL |
| jabber: lucas@nussbaum.fr +33 (0)6 64 71 41 65 |
| homepage: http://www-id.imag.fr/~nussbaum/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2007-02-15 16:18 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-15 15:40 [BUG?/SCHED] netem and tbf seem to busy wait with some clock sources Lucas Nussbaum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.