🚀 go-pugleaf

In article <3841@randvax.rand.org> edhall@rand.org (Ed Hall) writes:
   One of the reasons re-ordering the transmit queue only produces a
   moderate gain in interactive responsiveness is buffering in the
   modem itself.

Steve Willens at Livingston told me that TOS queue sorting in their
PortMaster terminal server yields observable and measurable
improvements, even over modems.  But we haven't seen that it helps
much in our UNIX environment.

I suspect the difference is that a terminal server's protocol handling
and queue sorting happens so close to the iron.  After our daemon
write()s the packet to /dev/tty, it still must traverse layers of line
disciplines, STREAMS modules, or whatever, each of which adds its own
buffering and therefore its own latency, before it reaches the TD pin
on the serial port.  Any advantage a particular packet gains in queue
sorting is overwhelmed by the flow-smoothing effect of all those
layers.

Of course, this is just my own pessimistic suspicion.  I'd love to
learn someday that the problem resides somewhere we can do something
about it :-)

   Lowering the MTU can help, too, since once a 1500-byte packet
   starts its way to the modem, you're going to have to wait for it to
   finish.

Shrinking your packets is the quickest and easiest thing to do, and
one of the few things a user can affect.  Also, make sure that your
PPP or SLIP does RFC-1144 "VJ" TCP header compression.

   I wish that Unix allowed more tinkering with TCP/IP parameters...

Write to bsdi-info@bsdi.com for information about their
fully-tinkerable UNIX-like operating system.  There's nothing more
adjustable than a tapeful of source.