Date: Thu, 07 Jul 2011 08:52:12 -0700 From: perryh@pluto.rain.com To: kob6558@gmail.com Cc: freebsd-net@freebsd.org, spork@bway.net Subject: size-dependent packet loss (Re: bce packet loss) Message-ID: <4e15d62c.nkl6i2oVCMDWLBPl%perryh@pluto.rain.com> In-Reply-To: <CAN6yY1satrdKHkteL_-_YGEASPEf_%2BXr1kS6KLM7io8hd6Kuhw@mail.gmail.com> References: <alpine.OSX.2.00.1107042113000.2407@freemac> <BE3848B9-96C4-4F67-9565-60382DA7D6DB@mac.com> <CAN6yY1u6%2Bh3qcM6KmASMBQqGE8H7GuCoPYt-5U_aLS=BHz313Q@mail.gmail.com> <7575C8FD-4E99-4A27-833F-312230078E9E@mac.com> <CAN6yY1satrdKHkteL_-_YGEASPEf_%2BXr1kS6KLM7io8hd6Kuhw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman <kob6558@gmail.com> wrote: > ... Years ago, when coaxial Ethernet the norm ... Aha! Another old-timer who has been around long enough to remember 10Mb Ethernet! Maybe something in the following will ring a bell? I have a (to me) very strange problem, for which I have a usable workaround but no actual solution, when I try to send "large" packets from an ancient Sun-3/50 (or 3/60, the same thing happens with either) through any hub I have ever tried to connect it to: * Packets up to about 750 or 800 bytes get through just fine, but the loss rate goes up sharply as size increases beyond that and reaches 100% somewhere around 900 or 950 bytes. (A hub that is smart enough to show such things logs a "late collision" error when it drops one of these large-ish packets.) * The problem does not seem to be related to high overall data rate: it arises even sending only one packet per second (e.g. ping). The obvious explanation is "physical layer problems", e.g. bad 10Base2 termination, but that does not hold up under investigation: * There is no problem _receiving_ large packets via the same connection: I can FTP an arbitrarily large file from an i386 (running either FreeBSD or Windows) through the hub _to_ the Sun box, but an attempt to FTP a 1KB file _from_ the Sun through the hub will never complete because the data packet is always dropped (unless I arrange to set the MTU to, say, 640 bytes so that large packets aren't used). It does not matter which end is controlling the FTP session: a "put" issued from the Sun or a "get" issued from the i386 -- either of which transfers the file from the Sun to the i386 -- will fail; a "get" from the Sun or a "put" from the i386 will work (transferring the file in the other direction). * If I move the 10Base2 tee connector from the hub to a 10Base2 port on the i386, so that the Sun and i386 boxes are connected directly by 10Base2 and no hub is involved, everything works properly in both directions. This pretty well eliminates cabling/termination as a factor. (Of course, this approach requires the i386 to have a 10Base2 connection; most of mine are new enough that they don't.) * It does not matter if the connection from the Sun-3 to the hub is made via coax using the built-in 10Base2 transceiver, coax using an external transceiver, or 10BaseT (necessarily using an external transceiver, since these Suns have only AUI and 10Base2 built in); nor does it seem to matter what brand of hub is used or even whether it is 10Mb-only or 10/100. Nor does it seem possible to blame the hub: I've tried several, of different brands, and all behave the same way; and there's no problem communicating among i386 systems through any of these hubs. Restricting the MTU to 640, and the NFS read and write data sizes (which must be a power of 2) to 512, is a usable workaround, but I would really like to understand what is going on!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4e15d62c.nkl6i2oVCMDWLBPl%perryh>