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 ttl=64 time=0.197 ms 64 bytes from x.x.x.x: icmp_seq=2 ttl=64 time=0.100 ms 64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=0.081 ms 64 bytes from x.x.x.x: icmp_seq=4 ttl=64 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 ttl=64 time=1.11 ms 64 bytes from x.x.x.x: icmp_seq=2 ttl=64 time=9.04 ms 64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=9.24 ms 64 bytes from x.x.x.x: icmp_seq=4 ttl=64 time=10.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 ttl=64 time=13.1 ms 64 bytes from x.x.x.x: icmp_seq=2 ttl=64 time=20.0 ms 64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=20.0 ms 64 bytes from x.x.x.x: icmp_seq=4 ttl=64 time=20.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 ttl=64 time=22.2 ms 64 bytes from x.x.x.x: icmp_seq=2 ttl=64 time=29.8 ms 64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=29.1 ms 64 bytes from x.x.x.x: icmp_seq=4 ttl=64 time=30.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/
> 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 ttl=64 time=0.197 ms > 64 bytes from x.x.x.x: icmp_seq=2 ttl=64 time=0.100 ms > 64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=0.081 ms > 64 bytes from x.x.x.x: icmp_seq=4 ttl=64 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 ttl=64 time=1.11 ms > 64 bytes from x.x.x.x: icmp_seq=2 ttl=64 time=9.04 ms > 64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=9.24 ms > 64 bytes from x.x.x.x: icmp_seq=4 ttl=64 time=10.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 ttl=64 time=13.1 ms > 64 bytes from x.x.x.x: icmp_seq=2 ttl=64 time=20.0 ms > 64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=20.0 ms > 64 bytes from x.x.x.x: icmp_seq=4 ttl=64 time=20.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 ttl=64 time=22.2 ms > 64 bytes from x.x.x.x: icmp_seq=2 ttl=64 time=29.8 ms > 64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=29.1 ms > 64 bytes from x.x.x.x: icmp_seq=4 ttl=64 time=30.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=1000) 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/
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=1000) 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/