tucker@ccvaxa.UUCP (02/12/86)
The main reason rawIP packets are SO MUCH FASTER than UDP/IP is
that the UDP layer does a big checksum on the entire data section.
This can easily be turned off (even if you have binary only) by
changing the value of a variable in the kernel called:
"udpcksum" (1 for checksum, 0 for no checksum)
This should increase the speed of UDP/IP to that of rawIP. Note
that as long as you are running on ethernet the UDP checksum isn't
really needed. Ethernet does a full packet checksum for you.
I would suggest using bigger packets to get higher speeds in
general. You should be able to send UDP/IP packets in the 2k-8k
range (depends on the socket space limit set in udp_usrreq.c on
you VAX UNIx). Your micro graphics station must also support IP
fragmentation to handle this. If you can change your kernel
you can increase the UDP socket space limit even higher if you
want. Take care when doing this. The maximum possible with
IP fragmentation is 64k at a shot.
Tim Tucker
Gould Electronics
tucker@gswd-vms.ARPA
..ucbvax!ihnp4!uiucdcs!ccvaxa!tuckerkarn@petrus.UUCP (Phil R. Karn) (02/15/86)
> The main reason rawIP packets are SO MUCH FASTER than UDP/IP is > that the UDP layer does a big checksum on the entire data section. > This can easily be turned off (even if you have binary only) by > changing the value of a variable in the kernel called: > > "udpcksum" (1 for checksum, 0 for no checksum) WARNING! WARNING! DANGER, WILL ROBINSON!!!! Quoting from RFC-817, "Modularity and Efficiency in Protocol Implementation" by David D. Clark: "There is one area which is generally accepted as causing noticeable and substantial overhead as part of TCP processing. This is computation of the checksum. It would be nice if this cost could be avoided somehow, but the idea of an end-to-end checksum is absolutely central to the functioning of TCP. No host implementor should think of omitting the validation of a checksum on incoming data." I believe this is just as valid for UDP. The Berkeley routed is a major UDP user. It already suffers greatly from an endearing naivete regarding incoming datagrams, and only the end-to-end checksums protect against all hell breaking loose should an Ethernet controller, bridge, or gateway decide to corrupt a routing (or any other) packet. This DOES happen. I have seen the buffer memories go bad in an Ethernet controller. This delightful piece of hardware would gladly corrupt received packets without notice, or garble outgoing packets (being careful, of course, to put a perfectly valid 32-bit CRC on the corrupted packet before sending it). Most recently, some garbage machine names started showing up in our ruptime listings. The problem turned out to be a flakey Ethernet bridge, and further investigation showed that all of our SUNs had set udpcksum to zero by default. I immediately patched this on as many Suns as I could find, especially those acting as IP gateways. The "udpcksum" (and "tcpcksum") "options" in 4.2BSD are, in my opinion, brain-damaged hacks that should be removed as soon as possible, along with the blind acceptance of any UDP datagram or TCP segment having a zero checksum field. Phil Karn