Date: Thu, 07 Jul 2011 11:04:22 -0700 From: Chuck Swiger <cswiger@mac.com> To: Kevin Oberman <kob6558@gmail.com> Cc: freebsd-net@freebsd.org, Charles Sprickman <spork@bway.net> Subject: Re: bce packet loss Message-ID: <B92EEE0F-7640-4C77-9E92-B619944ABDEB@mac.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
On Jul 6, 2011, at 5:50 PM, Kevin Oberman wrote: [ ... ] > Any modern Ethernet should be running full-duplex. Sure. With a price point of ~$10 per port for unmanaged gigabit switches nowadays, this is cheap enough that it's widely deployed even for SOHO and small offices. Also, I don't believe many vendors are even making ethernet hubs anymore.... > I am not aware of any switch, router, not NIC that counts FCS > (checksum) errors as "drops". Drops are not errors > according to 802. When a packet is received by the network stack and the various checksums at the ethernet frame (ie, the FCS field), IP header, and higher level protocol like UDP/TCP/etc are checked, the packet is dropped if the various checksums doesn't validate. A checksum error is not the same thing as dropping a packet due to resource constraints, as you mention: > The term is normally reserved for clean packets which > are thrown away due to the lack of > resources to retain them or due to policy (policer, RED, or other > queue management technique). ...so I gather you would prefer the phrase "the packet is discarded if a checksum doesn't validate"? [ ... ] > Finally, collisions are simply not errors. They are not counted as > errors and do not result in any packet loss. They are simply a normal > part of half-duplex operation. Normal collisions are an expected part of half-duplex operation, and the NIC takes responsibility for retransmitting the packet after a randomized delay without involving higher parts of the network stack. Late collisions aren't expected, however, and the NIC doesn't take responsibility for retransmitting the packet. > Years ago, when coaxial Ethernet the > norm, Van Jacobson wrote a short article describing the lack of impact > of collisions. He pointed out that in a common pathological case > involving the ACK in an FTP transfer always colliding with the > transmit of the of the next packet. He measured good-put of over 9Mbps > with 100% collisions. (Collision rate is non-intuitive because the > maximum collision rate is not 100%, but 1600% because a maximum of 16 > collisions are allowed before the transmission attempt stops and an > error of excessive collisions is declared. Again, this is just > backgound information, not relevant to the issue at hand. Yes, although the impact of collisions against an FTP data stream is a best-case scenario, as the FTP data packets are almost all going to be at the size of the MTU. If there's a collision, it should noticed during the first 64 octets as expected, whereas a clean transmission gets 1500 bytes of data through. Even with 10 collisions for each 1500 byte data packet going though, you'd probably still get around 7Mbps. Redo the experiment with 64-byte ICMP flood ping (or 84 bytes if you want to count the 802.3 preamble and frame gap), and such a high collision rate will have a much more noticeable impact. Regards, -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B92EEE0F-7640-4C77-9E92-B619944ABDEB>