Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uunet!mcsun!ukc!strath-cs!baird!jim From: jim@cs.strath.ac.uk (Jim Reid) Newsgroups: comp.protocols.nfs Subject: Re: Summary: NFS over links slower than 10 Mbit/sec Message-ID: Date: 8 Feb 91 13:43:59 GMT References: <1991Feb5.031603.2969@amd.com> <7371@exodus.Eng.Sun.COM> <7645@exodus.Eng.Sun.COM> Sender: jim@cs.strath.ac.uk Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland. Lines: 27 In-reply-to: brent@terra.Eng.Sun.COM's message of 8 Feb 91 07:32:12 GMT In article <7645@exodus.Eng.Sun.COM> brent@terra.Eng.Sun.COM (Brent Callaghan) writes: In article , meissner@osf.org (Michael Meissner) writes: > Always set UDP checksums, even over ethernet. Back in a previous > life, I was on a local ethernet where I could not reliably build GCC > without one .o being corrupted. Whomever in Sun made the choice not > to checksum NFS packets should have his/her/its head examined.... When NFS first shipped on Suns, we had just one or two MIPS of CPU to play with. UDP checksumming was a significant overhead. Bit errors on most ether networks was (and is) very low. Now, with most workstations provide 10 - 30 MIPS, the performance impact of checksumming is not an issue - particularly when implemented as part of a memory copy operation. As I recall, the reason why UDP checksumming was not switched on for NFS was nothing to do with performance (though it was bound to be a small contributory factor). In the early days of Sun and NFS, most vendors were using the 4.2 BSD TCP/IP code. This didn't compute UDP checksums properly, so it would sometimes accept corrupted packets and reject valid ones. Disabling UDP checksumming meant that protocols on top of UDP like NFS had a better chance to communicate with each other, especially when they ran on machines with different byte ordering. This BSD bug has long since been fixed and hopefully most vendors have picked it up by now. Jim