[LARTC] netem bug?

[LARTC] netem bug?

[Pedro Ancona Lopez Mindlin]

Hi all,

I'm running some tests with netem and I noticed some strange behaviour 
that looks like a bug: I'm pinging another machine and adding delay with 
netem. When I tell netem to give me a 10ms delay, it works fine. The 
problem is that when I ask for a 11ms delay, it gives me 20ms! It 
happens for any value between 11ms an 20ms, and it repeats for values 
over 20ms, now rounding up to 30ms.

Here is an example:

# ping x.x.x.x
PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
64 bytes from x.x.x.x: icmp_seq=1 ttld time=0.197 ms
64 bytes from x.x.x.x: icmp_seq=2 ttld time=0.100 ms
64 bytes from x.x.x.x: icmp_seq=3 ttld time=0.081 ms
64 bytes from x.x.x.x: icmp_seq=4 ttld time=0.099 ms

# tc qdisc add dev eth0 root netem delay 10ms
# ping x.x.x.x
PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
64 bytes from x.x.x.x: icmp_seq=1 ttld time=1.11 ms
64 bytes from x.x.x.x: icmp_seq=2 ttld time=9.04 ms
64 bytes from x.x.x.x: icmp_seq=3 ttld time=9.24 ms
64 bytes from x.x.x.x: icmp_seq=4 ttld time\x10.0 ms


# tc qdisc change dev eth0 root netem delay 11ms
# ping x.x.x.x
PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
64 bytes from x.x.x.x: icmp_seq=1 ttld time\x13.1 ms
64 bytes from x.x.x.x: icmp_seq=2 ttld time .0 ms
64 bytes from x.x.x.x: icmp_seq=3 ttld time .0 ms
64 bytes from x.x.x.x: icmp_seq=4 ttld time .0 ms

# tc qdisc change dev eth0 root netem delay 23ms
# ping x.x.x.x
PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
64 bytes from x.x.x.x: icmp_seq=1 ttld time".2 ms
64 bytes from x.x.x.x: icmp_seq=2 ttld time).8 ms
64 bytes from x.x.x.x: icmp_seq=3 ttld time).1 ms
64 bytes from x.x.x.x: icmp_seq=4 ttld time0.0 ms

# uname -a
Linux yyy 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC 2004 i686 GNU/Linux


Is this a known bug? Is there any fix? I also noticed that the first 
ping has always a smaller value. Can someone explain that?

Thanks,

Pedro.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] netem bug?

[Catalin(ux aka Dino) BOIE]

> Hi all,
>
> I'm running some tests with netem and I noticed some strange behaviour that 
> looks like a bug: I'm pinging another machine and adding delay with netem. 
> When I tell netem to give me a 10ms delay, it works fine. The problem is that 
> when I ask for a 11ms delay, it gives me 20ms! It happens for any value 
> between 11ms an 20ms, and it repeats for values over 20ms, now rounding up to 
> 30ms.
>
> Here is an example:
>
> # ping x.x.x.x
> PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
> 64 bytes from x.x.x.x: icmp_seq=1 ttld time=0.197 ms
> 64 bytes from x.x.x.x: icmp_seq=2 ttld time=0.100 ms
> 64 bytes from x.x.x.x: icmp_seq=3 ttld time=0.081 ms
> 64 bytes from x.x.x.x: icmp_seq=4 ttld time=0.099 ms
>
> # tc qdisc add dev eth0 root netem delay 10ms
> # ping x.x.x.x
> PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
> 64 bytes from x.x.x.x: icmp_seq=1 ttld time=1.11 ms
> 64 bytes from x.x.x.x: icmp_seq=2 ttld time=9.04 ms
> 64 bytes from x.x.x.x: icmp_seq=3 ttld time=9.24 ms
> 64 bytes from x.x.x.x: icmp_seq=4 ttld time\x10.0 ms
>
>
> # tc qdisc change dev eth0 root netem delay 11ms
> # ping x.x.x.x
> PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
> 64 bytes from x.x.x.x: icmp_seq=1 ttld time\x13.1 ms
> 64 bytes from x.x.x.x: icmp_seq=2 ttld time .0 ms
> 64 bytes from x.x.x.x: icmp_seq=3 ttld time .0 ms
> 64 bytes from x.x.x.x: icmp_seq=4 ttld time .0 ms
>
> # tc qdisc change dev eth0 root netem delay 23ms
> # ping x.x.x.x
> PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
> 64 bytes from x.x.x.x: icmp_seq=1 ttld time".2 ms
> 64 bytes from x.x.x.x: icmp_seq=2 ttld time).8 ms
> 64 bytes from x.x.x.x: icmp_seq=3 ttld time).1 ms
> 64 bytes from x.x.x.x: icmp_seq=4 ttld time0.0 ms
>
> # uname -a
> Linux yyy 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC 2004 i686 GNU/Linux
>
>
> Is this a known bug? Is there any fix? I also noticed that the first ping has 
> always a smaller value. Can someone explain that?

The "problem" is the 2.4 kernel because HZ is 100.
Ping is not rescheduled quickly enough to measure correctly the rtt.

On my 2.6 kernel (HZ\x1000) it work almost perfect.

Hope it helps.

>
> Thanks,
>
> Pedro.
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>

---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] netem bug?

[Michael Renzmann]

Hi.

Catalin(ux aka Dino) BOIE wrote:
> The "problem" is the 2.4 kernel because HZ is 100.

That was my idea, too.

> On my 2.6 kernel (HZ\x1000) it work almost perfect.

If the OP thinks of changing HZ, the following links might be a good help:
http://www.plumlocosoft.com/kernel/
(especially 013-j64.diff.bz2 and 014-vhz.diff.bz2)

http://kerneltrap.org/node/464/1528

The mentioned patches allow to change HZ to something else than 100 
while retaining compatibility to userspace and other stuff that might 
rely on HZ being 100. Note that kernel image as well as (most probably 
all) modules have to be recompiled and replaced for the patch to take 
effect.

Bye, Mike
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/