Date: Mon, 3 Mar 1997 00:53:40 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: hackers@freebsd.org Cc: jrb@cs.pdx.edu Subject: [driver testing] Odd network behaviour? Message-ID: <199703021423.AAA20864@genesis.atrad.adelaide.edu.au>
next in thread | raw e-mail | index | archive | help
Julian, Garrett, as intimates of the 82586 club, I'd really appreciate any ideas you might have here... I've been pounding on Jim B's Wavelan driver for a while and driving myself slowly nuts trying to work out some odd behaviour. I've come to the point where I think some external input would be helpful. A shred of background; the Wavelan cards use intel i82586's, and generally look like ethernet cards from the programmer's point of view (modulo some extra bits). The behaviour I'm seeing is basically that when a 'fast' (slow Pentium) host sends to a 'slow' (486/66) host, the send randomly pauses. I've just been using ftp for this testing; with hashmark printing on it's easy to see the output pause, often for a second or longer. This problem is seperate from the one where the card occasionally loses transmit interrupts, but may (?) be related. Here's a tcpdump snapshot of a hiccup (wide window, people): 00:26:23.316162 wl1.ftp-data > wl2.40024: . ack 301497 win 14752 (DF) [tos 0x8] (ttl 64, id 3915) 00:26:23.316687 wl2.40024 > wl1.ftp-data: . 301497:302957(1460) ack 1 win 17520 (DF) [tos 0x8] (ttl 64, id 18617) 00:26:23.324176 wl2.40024 > wl1.ftp-data: . 302957:304417(1460) ack 1 win 17520 (DF) [tos 0x8] (ttl 64, id 18618) 00:26:23.331677 wl2.40024 > wl1.ftp-data: . 304417:305877(1460) ack 1 win 17520 (DF) [tos 0x8] (ttl 64, id 18619) 00:26:23.339123 wl2.40024 > wl1.ftp-data: . 305877:307337(1460) ack 1 win 17520 (DF) [tos 0x8] (ttl 64, id 18620) 00:26:23.341309 wl1.ftp-data > wl2.40024: . ack 302957 win 17520 (DF) [tos 0x8] (ttl 64, id 3917) 00:26:23.347098 wl2.40024 > wl1.ftp-data: . 307337:308797(1460) ack 1 win 17520 (DF) [tos 0x8] (ttl 64, id 18621) 00:26:23.349305 wl1.ftp-data > wl2.40024: . ack 302957 win 17520 (DF) [tos 0x8] (ttl 64, id 3918) 00:26:23.356650 wl1.ftp-data > wl2.40024: . ack 302957 win 17520 (DF) [tos 0x8] (ttl 64, id 3919) 00:26:24.750418 wl2.40024 > wl1.ftp-data: . 302957:304417(1460) ack 1 win 17520 (DF) [tos 0x8] (ttl 64, id 18622) 00:26:24.759661 wl1.ftp-data > wl2.40024: . ack 308797 win 11680 (DF) [tos 0x8] (ttl 64, id 3920) 00:26:24.760119 wl2.40024 > wl1.ftp-data: . 308797:310257(1460) ack 1 win 1752 (DF) [tos 0x8] (ttl 64, id 18623) wl2 is the 'fast' host sending, and 'wl1' is the slow host receiving; the trace is taken on wl2. To my eyes, this looks like the packet 302957:304417 was lost somehow by the receiver, and was eventually resent. But why the long silence before the retransmit? Hiccups usually seem to occur after three or four back-to-back packets from the 'fast' system (but not always), so I guess there's some overrun happening somewhere. And, for the '586-experienced, why would the second frame in the group of four have been lost but not the others? If I artificially slow the data stream down (by inserting large DELAYs in the output code), the hiccups eventually die away (at about 10ms/packet). There's no sign of receiver resource starvation... This is the last stumbling block before I pack this code off for general use, and it's got me stumped. Any ideas would be greatly appreciated. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703021423.AAA20864>