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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20070215154007.GB25685@xanadu.blop.info>
Date:	Thu, 15 Feb 2007 16:40:07 +0100
From:	Lucas Nussbaum <lucas.nussbaum@...g.fr>
To:	netdev@...r.kernel.org
Subject: [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@...g.fr        LIG / Projet MESCAL |
| jabber: lucas@...sbaum.fr    +33 (0)6 64 71 41 65 |
| homepage:        http://www-id.imag.fr/~nussbaum/ |

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)