Just how reliable is NFS?

[Ron McDaniels]

Per RFC768, "User Datagram Protocol":

"Checksum is the 16-bit one's complement of the one's complement of the pseudo
header of informantionfromthe IP header, the UDP header, and the data. . .".

I would like to point out that the 32-bit CRC generated with every Ethernet
packet and checked by the receiver of the packet is (orders of magnitude?)
a far more reliable detector of transmission errors than the artifact of the
1st generation of computers, the checksum. If your Ethernet driver passes
corrupted packets into the higher protocol levels, it is because it is ignoring
the fact that the Ethernet controller chip has run out of memory or some
similar problem and not because an error has crept by the CRC checking logic.

In my experience, we have never encountered an Internet checksum error with our
very vanilla flavored implimentation of BSD 4.2 networking (at least, not
since I fixed the 82586 Ethernet controller chip NO RESOURCES bug in my
Ethernet controller driver;-).

BTW, a ones-complement checksum across a threaded list of mbufs takes a lot
longer than you might intuit. The cleverest assembly language programming
really pays off. I added a switch in my in_cksum routine which causes it to
immediately return a zero. Makes a network of Celerity C1200s and C1260s
run about 8% faster with a heavy TCP networking workload. Problem is that
the "foreign" machines on our net don't understand this and refuse to talk
to me.


R. L. (Ron) McDaniels

CELERITY COMPUTING . 9692 Via Excelencia Way . San Diego, California . 92126
(619) 271-9940 . {decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ron
"Yes, my Precious. . . we hates them socket(2)eses!"