From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 18:05:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12069106566C for ; Thu, 7 Jul 2011 18:05:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id E685C8FC0C for ; Thu, 7 Jul 2011 18:05:06 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LNZ00M6U67A6DA0@asmtp024.mac.com> for freebsd-net@freebsd.org; Thu, 07 Jul 2011 11:04:22 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-07_07:2011-07-07, 2011-07-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107070140 From: Chuck Swiger In-reply-to: Date: Thu, 07 Jul 2011 11:04:22 -0700 Message-id: References: <7575C8FD-4E99-4A27-833F-312230078E9E@mac.com> To: Kevin Oberman X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Charles Sprickman Subject: Re: bce packet loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:05:07 -0000 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