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 | | [EMAIL PROTECTED] LIG / Projet MESCAL | | jabber: [EMAIL PROTECTED] +33 (0)6 64 71 41 65 | | homepage: http://www-id.imag.fr/~nussbaum/ |
signature.asc
Description: Digital signature
