- * To insure we get good interactive response, the MTU wants to be
- * the smallest size that amortizes the header cost. (Remember
- * that even with type-of-service queuing, we have to wait for any
- * in-progress packet to finish. I.e., we wait, on the average,
- * 1/2 * mtu / cps, where cps is the line speed in characters per
- * second. E.g., 533ms wait for a 1024 byte MTU on a 9600 baud
- * line. The average compressed header size is 6-8 bytes so any
- * MTU > 90 bytes will give us 90% of the line bandwidth. A 100ms
- * wait is tolerable (500ms is not), so want an MTU around 256.
- * (Since TCP will send 212 byte segments (to allow for 40 byte
- * headers), the typical packet size on the wire will be around 220
- * bytes). In 4.3tahoe+ systems, we can set an MTU in a route
- * so we do that & leave the interface MTU relatively high (so we
- * don't IP fragment when acting as a gateway to someone using a
- * stupid MTU).
+ * SLMTU is a hard limit on output packet size. To insure good
+ * interactive response, SLMTU wants to be the smallest size that
+ * amortizes the header cost. (Remember that even with
+ * type-of-service queuing, we have to wait for any in-progress
+ * packet to finish. I.e., we wait, on the average, 1/2 * mtu /
+ * cps, where cps is the line speed in characters per second.
+ * E.g., 533ms wait for a 1024 byte MTU on a 9600 baud line. The
+ * average compressed header size is 6-8 bytes so any MTU > 90
+ * bytes will give us 90% of the line bandwidth. A 100ms wait is
+ * tolerable (500ms is not), so want an MTU around 296. (Since TCP
+ * will send 256 byte segments (to allow for 40 byte headers), the
+ * typical packet size on the wire will be around 260 bytes). In
+ * 4.3tahoe+ systems, we can set an MTU in a route so we do that &
+ * leave the interface MTU relatively high (so we don't IP fragment
+ * when acting as a gateway to someone using a stupid MTU).
+ *
+ * Similar considerations apply to SLIP_HIWAT: It's the amount of
+ * data that will be queued 'downstream' of us (i.e., in clists
+ * waiting to be picked up by the tty output interrupt). If we
+ * queue a lot of data downstream, it's immune to our t.o.s. queuing.
+ * E.g., if SLIP_HIWAT is 1024, the interactive traffic in mixed
+ * telnet/ftp will see a 1 sec wait, independent of the mtu (the
+ * wait is dependent on the ftp window size but that's typically
+ * 1k - 4k). So, we want SLIP_HIWAT just big enough to amortize
+ * the cost (in idle time on the wire) of the tty driver running
+ * off the end of its clists & having to call back slstart for a
+ * new packet. For a tty interface with any buffering at all, this
+ * cost will be zero. Even with a totally brain dead interface (like
+ * the one on a typical workstation), the cost will be <= 1 character
+ * time. So, setting SLIP_HIWAT to ~100 guarantees that we'll lose
+ * at most 1% while maintaining good interactive response.