lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Try to Increase Jumbo Packet size beyond 9K


From: Kieran Mansley
Subject: Re: [lwip-users] Try to Increase Jumbo Packet size beyond 9K
Date: Wed, 15 Oct 2008 09:15:31 +0100

On Tue, 2008-10-14 at 23:59 +0200, Timmy Brolin wrote:
> address@hidden wrote:
> > Kieran Mansley wrote:
> >> On Mon, 2008-10-13 at 08:58 -0400, bill wrote:  
> >>> TCP checksum (which we in the end disabled because we are always on an
> >>> internal lan)     
> >> I hope you're not transferring any important data over this connection.
> >> I would not trust any network to get the bits right all the time.  It
> >> would be fine for a large class of applications (e.g. where the data has
> >> no persistence when it arrives, or for those that would often use UDP)
> >> but a really bad idea for others.
> >>   
> > I agree on this. We only discovered a bug in one MAC because of TCP
> > checksum errors. The MAC said the CRC was correct...
> >
> > Simon
> Why? The Ethernet 32bit CRC is lightyears better than the 16 bit TCP
> checksum at detecting errors (unless your MAC is broken of course...)
> Modern industrial Ethernet protocols for example cannot afford a lot of
> overhead per packet, so they rely entirely on the Ethernet CRC.

I'm not advocating the use of the TCP checksum to replace the Ethernet
CRC - I think you should use both as they are complementary and detect
different (overlapping) sets of errors.

If you'll allow me to over-simplify a little, the Ethernet CRC is a
point-to-point checksum that protects against bit errors introduced on
the physical link between nodes in the network.  It is checked when it
arrives at a piece of equipment in the network and recomputed as it
leaves, and so does not protect against errors introduced within each
node that a packet might traverse.  If the packet is corrupted in this
way it will appear to have the correct CRC (as it was computed after the
corruption was introduced) and so you will get bit-rot in your data.
The probability of this is proportional to the number of hops in the
network.

The TCP checksum is an end-to-end protocol.  It is only checked and
computed by the two nodes that are communicating, and therefore protects
against any error (well, most - there are some it won't detect of
course) in the network between them.  Unless you're doing something like
checksum-offload, it covers all the network hardware the packet
encounters, including for example the PCI bus and the network card
within the PC.

Software engineers sometimes assume that hardware is perfect and has no
bugs, but that's often not the case.

Kieran





reply via email to

[Prev in Thread] Current Thread [Next in Thread]