Subject: Re: Serial changes 1.1-current
To: Phil Knaack <flipk@ncremp.ag.iastate.edu>
From: Operator <oper@mikrobitti.fi>
List: port-i386
Date: 05/22/1996 20:19:27
> >I have a 120 MHz pentium and I get massive overruns using 16550 UARTs
> >and PPP.  Accessing the IDE drive doesn't seem to make things worse,
> >but I think the 3com509 Ethernet card has more effect on the problem.
> 
> 	I find this interesting because I use a P90 with an internal Zoom
> modem and a 4-byte fifo, I doubt it has the 'hardware flow control'; I also
> have a heavily-used 3com509 in this machine. And I get virtually _no_ 
> errors on my PPP link (running at 38.4) to a 486slc/66 with an identical
> modem.

Well, I tested the ports with a null-modem cable between two pentium
boxes, at 115200 bps.  When using ftp over the PPP link I got overruns
so bad that PPP locked up for long periods of time due to some (TCP/IP?)
timeouts.  38400 bps works quite well, but that's not enough for running
fast modems (that's what the users keep telling me, at least).

> 	The P90 uses three IDE disks exclusively, and heavily. This would
> suggest to me that the character-dropping problem is not directly related
> to the "wd" driver.

I agree.

> 	Have you tried the patches (I forget who suggested them) below?
> 
> >sys/kern/tty.c: change 3 clalloc()s in ttymalloc() to 4k.
> >sys/sys/tty.h: change TTYHOG to 4k.
> 
> 	This individual is running 115.2k raw data continuously thru
> a 386-33 on a Hayes/ESP.

No I haven't.  Doesn't the Hayes/ESP have a very large FIFO?  It helps
_a lot_ when the system can't respond to interrupts fast enough.  At
115200 bps you get 11520 bytes / second.  If your UART interrupts the
CPU when there are 4 bytes free in the FIFO, the CPU has 347 us time
to service that interrupt before data gets lost.  This sounds like
a long time to me (at least on a fast pentium), but there must be
something that blocks the serial interrupts long enough for data to get
lost.

Lowering the FIFO treshold might help, but that also means you'll
get even more interrupts, which increases the CPU load.

I would like to try to patch mentioned here by Onno, but I don't know
if it can be applied to recent kernel sources (I'm using 960413)..

  -jm