Weird ping statistics...

[Johnny Billquist <bqt%softjar.se@localhost>]

I was just testing the local network on the 8650 here, and noticed a 
very strange thing.

Setup: a local ethernet network. Two machines. One PDP-11 and one VAX. 
Running ping, once at a time, from the PDP-11 and the VAX.
(The PDP-11 running my own IP-stack, just in case you wonder.)

Now, I would expect ping times to be somewhat similar from both sides, 
but they were not.

Running on the PDP-11:
.ping krille
PING Krille.Update.UU.SE (130.238.19.20): 16 data bytes
16 bytes from 130.238.19.20: icmp_seq=1 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=2 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=3 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=4 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=5 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=6 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=7 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=8 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=9 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=10 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=11 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=12 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=13 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=14 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=15 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=16 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=17 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=18 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=19 ttl=255 time=0 ms
16 bytes from 130.238.19.20: icmp_seq=20 ttl=255 time=0 ms
----Krille.Update.UU.SE PING Statistics----
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
.

Running from the VAX:
Krille:local/bqt> ping mim
PING mim.Update.UU.SE (130.238.19.211): 56 data bytes
64 bytes from 130.238.19.211: icmp_seq=0 ttl=64 time=121.044 ms
64 bytes from 130.238.19.211: icmp_seq=1 ttl=64 time=205.748 ms
64 bytes from 130.238.19.211: icmp_seq=2 ttl=64 time=204.506 ms
64 bytes from 130.238.19.211: icmp_seq=3 ttl=64 time=234.709 ms
64 bytes from 130.238.19.211: icmp_seq=4 ttl=64 time=30.544 ms
64 bytes from 130.238.19.211: icmp_seq=5 ttl=64 time=160.720 ms
64 bytes from 130.238.19.211: icmp_seq=6 ttl=64 time=69.346 ms
64 bytes from 130.238.19.211: icmp_seq=7 ttl=64 time=8.665 ms
64 bytes from 130.238.19.211: icmp_seq=8 ttl=64 time=8.767 ms
64 bytes from 130.238.19.211: icmp_seq=9 ttl=64 time=9.040 ms
64 bytes from 130.238.19.211: icmp_seq=10 ttl=64 time=8.972 ms
64 bytes from 130.238.19.211: icmp_seq=11 ttl=64 time=11.386 ms
64 bytes from 130.238.19.211: icmp_seq=12 ttl=64 time=8.109 ms
64 bytes from 130.238.19.211: icmp_seq=13 ttl=64 time=18.590 ms
64 bytes from 130.238.19.211: icmp_seq=14 ttl=64 time=7.756 ms
64 bytes from 130.238.19.211: icmp_seq=15 ttl=64 time=7.390 ms
64 bytes from 130.238.19.211: icmp_seq=16 ttl=64 time=199.498 ms
64 bytes from 130.238.19.211: icmp_seq=17 ttl=64 time=7.783 ms
64 bytes from 130.238.19.211: icmp_seq=18 ttl=64 time=8.776 ms
64 bytes from 130.238.19.211: icmp_seq=19 ttl=64 time=8.236 ms
^C
----mim.Update.UU.SE PING Statistics----
20 packets transmitted, 20 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.390/66.979/234.709/84.827 ms
Krille:local/bqt>


Some additional details, that might be worth pointing out: The resultion 
of times on the PDP-11 is 20ms, so anything less than that will just be 
0. So the consistent 0ms times are not a bug. If I ping something a bit 
further away I do indeed get longer times, which are visible. It's just 
that this is close enough, and fast enough, that not a single clock tick 
happens to pass before the reply comes back.

The VAX was running a make update on a pkgsrc directory meanwhile, but 
this was equally true for the pings in both directions.

The wildly varying times when running ping from the VAX to the PDP-11 
seems weird, and not good. Obviosuly, the IP stack itself is running at 
full speed without problems, since ICMP echo reply packets go out as 
soon as the echo request comes in. So, somewhere between the IP stack, 
and userland, serious delays are introduced. Or else scheduling is 
messing things up. Or something else I can't really think of is causing 
this behaviour.

Anyone seen anything similar, or have any good ideas on why this 
happens? I think it's a sign that something is not right anyway.

Oh, and the mandatory:
Krille:local/bqt> uname -a
NetBSD Krille.Update.UU.SE 5.99.40 NetBSD 5.99.40 (Krille) #367: Sat Jan 
15 01:56:58 CET 2011 
root%GW.SoftJAR.SE@localhost:/usr/obj/sys/arch/vax/compile/Krille vax


        Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol