[BUG?/SCHED] netem and tbf seem to busy wait with some clock sources

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/ |