lwip-users
[Top][All Lists]
Advanced

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

RE: [lwip-users] Max throughput and LWIP


From: Bill Auerbach
Subject: RE: [lwip-users] Max throughput and LWIP
Date: Mon, 4 Feb 2008 12:03:40 -0500

> > The biggest thing which significantly increased the speed was to turn
> > off incoming IP/UDP/TCP checksum checking.  If I leave the checking
> > on, I get around 650MbS with jumbo frames.  This ~940MbS was standard
> > frames.  Since the Ethernet controller has CRC checks, I don't think
> > the lwIP checking is required.  I was going to pose to the group this
> > week what is the downside of this disabling of the checksumming,
> > because the speed impact is substantial.
> 
> This is a really bad idea if you care about your data (though there are
> some example of where you might legitimately not care).  The CRC
> protects against bit errors on each link.  It is a point-to-point check,
> recomputed at each node in the network.  Therefore if any piece of
> equipment or software on the route of your packet has a bug that
> corrupts the data it is unlikely that the CRC will protect you.  The
> checksums are end-to-end, so are computed and checked only at the source
> and destination, so any (well, most) errors generated in between will be
> spotted.  The simple answer is you need checksums on unless you have a
> good understanding of why you don't!  And even then you probably need
> them on.

The two devices communicating probably will be directly connected.  Though
the user could put this on his LAN, I would think the router would direct
traffic from the PC right back to the lwIP device and then only the router
could or would introduce errors that TCP checksumming would be required to
check, is this right?

Has anyone seen substantial improvement by inlining and/or using assembly
for the checksumming?  I think the quality of today's compilers would make
the return on this minimal.

Thanks Kieran,

Bill





reply via email to

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