🚀 go-pugleaf

On getting reasonable interactive performance during bulk data transfers:

One of the reasons re-ordering the transmit queue only produces a
moderate gain in interactive responsiveness is buffering in the modem
itself.  The packet may go to the front of the queue, but there can be
more than a kilobyte of data that needs to be transmitted before it
reaches the wire.  See if your modem allows adjustment of its internal
buffer size.

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.

If you can lower the TCP window size to something small (~512 bytes)
you'll improve interactive performance during FTP's a /lot/.  This will
slow down your transfer some (as will lowering the MTU), but it will
actually help interactive performance in spite of any modem buffering.
Alas, it can be difficult to coax most Unix systems to lower their TCP
window size; I did it with KA9Q and managed a threefold improvement in
round-trip times with only a 20% hit on the (one-way) FTP throughput.
The trick was getting the window size down to the point where ACKs
were getting back just in time.  (It was a while ago, but I think
this was with an MTU of 384 and window size of 512.)

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

		-Ed Hall
		edhall@rand.org