On Wednesday, October 17, 2001, at 09:29  pm, Hauke Fath wrote:

> Make sure you operate with hardware handshake - Macintoshes can do 
> either
> line control (DTR) or flow control (RTS) because they have only one
> outgoing handshake line which is wired with both DTR and RTS in 
> "hardware
> handshake" modem cables. Make sure the modem ignores DTR -- usually AT 
> &D0.

I think I was doing that.

> Use a lower MTU in your ppp setup to lose fewer data from a dropped 
> byte.
>
> I had a IIci running with an ISDN modem (max. 8 KByte/sec, interface 
> speed
> 115KBit/sec) for a long time, and performance was fine as long as there
> were no disk accesses.

Mmm. I was running squid to proxy everything, so there was always disk 
access. That was probably the problem.

> I have my Q700 set up as a slip gateway for an old 486 notebook - again
> with 115 KBit/sec. I see the occasional silo overrun, but no big 
> problems.
>
>> Okay... So, looks like there's no way to make it more acceptable!
>>
>> Fortunately, a friend and I built a PC from bits which we had around 
>> our
>> respective bedroom floors (more from his than mine), and I now have an
>> i386 NetBSD machine, which seems pretty good.
>>
>> Purely out of curiosity, now, can anyone explain why the performance
>> isn't on par with that which Mac OS could provide on the same hardware?
>
> The i386 most likely is equipped with a 16550 controller that has a 16 
> byte
> fifo. The 85c30 in 68k Macs only has a 3 byte fifo which means that
> transmission is much more sensitive to interrupt latency. Blocking
> interrupts too long (disk access) means dropped bytes, and a single 
> dropped
> byte means a dropped packet dur for retransmission - worst case, 1500 
> Byte.

Again, looks like squid was the culprit. I'll see whether this i386 
thing can handle squid before I send the other one off to the datacentre.

Thanks for the useful reply. :]

Take care,

~ Matthew