Scenario: Two machines, both with DEC ATMWorks boards, both
connected to a DEC Gigaswitch, all OC3 over fiber. Both machines
are running Digital Unix v3.2g-3.
Machine B has been fully rebooted, and has not yet sent or
received any ATM traffic. Machine A pings machine B with
"ping -c 3 machineb-atm" (hostnames swizzled in this description).
The result:
machinea% ping -c 3 machineb-atm
PING MACHINEB-ATM.PDL.CS.CMU.EDU (x.x.x.x): 56 data bytes
64 bytes from 128.2.192.52: icmp_seq=2 ttl=255 time=0 ms
64 bytes from 128.2.192.52: icmp_seq=1 ttl=255 time=9925 ms
64 bytes from 128.2.192.52: icmp_seq=0 ttl=255 time=11232 ms
This is 100% reproducible.
Since the ATM infrastructure itself can't reorder (and even if it
did, it would reorder cells, not AAL-encapsulated packets), I'm
guessing that one of the following is happening:
1 the receiving ping sent the replies in the wrong order
2 the transmitting machine queued the ICMP packets in some
outgoing queue while the VC was established; this queue
turned out to be LIFO, not FIFO, and so the packets were
transmitted in reverse order
3 the receiving machine queued the ICMP reply packets in a
similar manner while the reverse VC was still being established;
LIFO-not-FIFO struck, and the replies were all transmitted
together in reverse order
My guess is #3. Unfortunately, DEC's ATM drivers don't support
the packetfilter, so I can't verify this. Has anyone else seen
this phenomena? Have any other guesses? Any suggestions for how
to track down the problem?
I'm concerned that if there are LIFO packet queues somewhere in
the kernel, TCP performance may suffer greatly (since DEC's TCP
does not include SACK support).
Any suggestions or information would be greatly appreciated!
Thanks,
Jim.Zelenka_at_cs.cmu.edu
Received on Tue Aug 12 1997 - 17:07:47 NZST