From owner-freebsd-hackers Tue Nov 11 21:18:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06652 for hackers-outgoing; Tue, 11 Nov 1997 21:18:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06621 for ; Tue, 11 Nov 1997 21:18:26 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-170.ca.us.ibm.net (slip129-37-53-170.ca.us.ibm.net [129.37.53.170]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id FAA121406; Wed, 12 Nov 1997 05:18:18 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Date: Wed, 12 Nov 1997 06:19:34 GMT Message-ID: <34693467.2988634@smtp-gw01.ny.us.ibm.net> References: <199711120305.OAA00642@godzilla.zeta.org.au> In-Reply-To: <199711120305.OAA00642@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id VAA06625 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997 14:05:03 +1100, Bruce Evans wrote: > "silo overflow", > >RTS flow control is almost useless for preventing this error, since > the interrupt handler must run to invoke RTS flow control. Did you know that the 650 UART has on-chip "auto" RTS flow control which can be invoked by the chip itself when the UART FIFO trigger level is reached? That's why I want to use my 650 UARTs in 650 mode rather than 550 compatibility mode. > "interrupt-level buffer overflow", > >The gap between the high water mark and the end of the fifo (256 - 192) >needs to be larger than the hardware fifo size. I think it is for >the 16550, so the 16550 bug must be elsewhere. You mean 650? A Startech 16C650 has a 32 byte FIFO buffer while the quad 16C654, four UARTs on a chip, each have 64 bytes. I increased the software buffer size from 256 to 512, and that seemed to reduce the number of overflows, but a burst of disk activity would still trigger one even with the larger buffer. >All buffer sizes are too small for 230400 bps. I have a 3Com ISDN T/A attached to a serial port at 230400 bps. I can saturate that link with a large download, start another download on an analog modem at 57600 bps, FTP upload my XFree86 directory from another machine via 10Mbps ethernet, and copy a directory from CD to the same hard drive receiving the FTP upload, never getting any serial overflows with the UARTs running in 550 compatibility mode. And the machine is only a 486 DX4-100. >The software fifo is large enough for 22 msec worth of input at 115200 > bps and the timeout handler normally runs every 10 msec to drain it. >12 msec to spare is normally plenty, but 2 msec for 230400 bps wouldn't I've never seen my ISDN link exceed throughput of 15k bytes per second, so I suppose my average bit rate of 150,000 is safe even in 550 mode. Hmmm ... the ISDN adapter is talking to the serial port at 230400 in short bursts ... I wonder how many bytes might arrive in one burst ... but then again, why should that be a problem only in 650 mode and not in 550 mode? I can change my ISDN port back to 115200 and still get overflows in 650 mode -- even the 57600 modem will overflow in 650 mode. John