dorl@vms3.macc.wisc.edu (Michael (NMI) Dorl) (03/08/88)
What is the expected error rate for a large Ethernet? I'd like to know what fraction of the packets could be expected to have some error such as checksum, short packet, long packet.
hedrick@athos.rutgers.edu (Charles Hedrick) (03/12/88)
Ethernet error rates, in terms of CRC, framing, etc., are generally very low. On some of our very heavily loaded networks (lots of diskless Suns) our cisco gateways (Interlan Multibus controllers) and a Sun 4 (Sun's own controller, but note that both the Interlan and Sun controller use the Intel Ethernet chip, so you'd expect their low-level Ethernet handling to be similar) see input errors at the rate of about 3 per million. Output errors are a bit more common, but an output error probably isn't an error of the sort you meant. On our network it most typically means that the system had to try more than N times to get a packet out onto the network, because it was jammed. I see these only on networks with high collision rates, and even there the largest number I see is around 1 in 10,000 packets. This is on a network with an average 10% collision rate, which indicates that it is far too heavily loaded. (We're in the process of splitting it into multiple Ethernets.) Note by the way that collisions are not errors. They are a normal part of the operation of the Ethernet protocol. Collision rates of a percent or so are perfectly normal. However our 10% figure indicates that our network is too heavily loaded.
mogul@decwrl.dec.com (Jeffrey Mogul) (03/18/88)
In article <66@dogie.edu> dorl@vms.macc.wisc.edu (Michael (NMI) Dorl) writes: >What is the expected error rate for a large Ethernet? I'd like >to know what fraction of the packets could be expected to have >some error such as checksum, short packet, long packet. We have a DEC LANBridge100 separating two fairly busy halves of an Ethernet. One feature of this device (no, this is not a plug) is that it keeps statistics, which one can retrieve with the right magic. I've enclosed a statistics report taken this morning. As far as I know, our Ethernet and associated attachments are within spec and well-maintained, so I'm not surprised that the error rate is fairly low. Some interpretation: if "Bridge seconds" is really the number of seconds since the bridge was started, then this one has been running for 230 days (this is not a plug, either). It looks like about 1 out of every 42000 packets is bad on one side, and 1 out of every 5000 packets is bad on the other side; I don't know if collisions are counted as "Bad frames" or not, and it's possible that most of the bad packets were generated in brief bursts of network sickness. -Jeff ---------------------------------------------------------------- Line counters for Line 1 as of 17-MAR-1988 10:47:25 Bridge SSQ1, Address 08-00-2B-04-66-1B Bridge seconds: 19909393 Invalid protocol messages: 0 Filtered frames: 2952389947 Bad frames: 583994 Lifetime exceeded frames: 744 No forwarding entry frames: 0 Forwarding transition count: 1 Collision Presence Test errors: 0 Transmitted Received Frames: 1057044284 4035950595 Bridge frames: 19948975 11 Frames lost: 0 70118 Line counters for Line 2 as of 17-MAR-1988 10:47:26 Bridge SSQ1, Address 08-00-2B-04-66-1B Bridge seconds: 19909393 Invalid protocol messages: 0 Filtered frames: 4195296973 Bad frames: 106159 Lifetime exceeded frames: 10789 No forwarding entry frames: 0 Forwarding transition count: 1 Collision Presence Test errors: 0 Transmitted Received Frames: 1093867616 1008319522 Bridge frames: 19948987 15 Frames lost: 0 515