tcp-ip@ucbvax.ARPA (06/04/85)
From: Jeff Mogul <mogul@Navajo>
IP fragmentation is admittedly
a bad thing to do on a regular basis. BRL avoids this by keeping most
of our LAN's at 1008 (for historical reasons mostly, the gateways
originally didn't know how to fragment).
One of the less successful performance "improvements" in 4.2BSD
was that the TCP tried to use 1024 byte segments, since this
allowed 4.2 to use page-remapping techniques instead of copying.
However, this is really a complete loss in our environment, where
we had Vaxen connected to a 3Mb ether which is gatewayed to the
ARPAnet (the current hardware situation is a little different).
FTPing from another 4.2 machine across the ARPAnet would seldom
work, because those 1024-byte segments turned into an almost-1024-
byte fragment followed by a tinygram. The local gateway dumps the
tinygram onto the ethernet almost immediately following the first
fragment, and the Vax interface (no buffering) drops back-to-back
packets, i.e., the tinygram. This happens over and over, so even
though 90% of the bytes are getting through, the segment is never
acked and the connection fizzles.
We solved this by hacking the TCP code to force 576-byte segments
unless it is sure that no gateway was in the path, in which
case it uses the LAN MTU. This works fine, and we can keep our
LAN MTUs high (1500 bytes) to reduce the packet counts in the
dominant case.tcp-ip@ucbvax.ARPA (06/05/85)
From: Ron Natalie <ron@BRL.ARPA> Yes, we realized this to. Our gateway had slight software modifications to cope with this. Fortunately the Ethernet has a little buffering on the boards (at least Interlan does), unfortunately some of the other strange devices we use here, did not. -Ron
tcp-ip@ucbvax.ARPA (06/05/85)
From: Murray.pa@Xerox.ARPA There is another hack that's worth remembering if anybody is having troubles catching back-to-back packets: Slow down the transmitter. Some of our Ethernet drivers do that with only a few words of microcode. On the first (re)transmission, set the collision timer to 1ms. There are obviously variations and optimizations. The point is that it's trivial to implement and a small delay won't be noticed by most applications but it can be a lifesaver in a few critical cases. Credit where it's due dept: Ed Taft came up with this trick when our Alto based file servers couldn't keep up with our Dorados.