Date: Mon, 19 Jun 1995 10:51:08 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, hsu@clinet.fi Cc: current@freebsd.org Subject: Re: kern/528: interrupt-level buffer overflows Message-ID: <199506190051.KAA11834@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Its a leased line, no hardware handshake. WIth decent uarts it shouldn't a >problem to run even at 115k (It did work with Linux on 386/16 and FreeBSD >on 486/66, about 11kbytes per second for ftp transfer). The FreeBSD driver was developed on a 386preDX/20 with an 8250. The speed was about 9.5 KB.sec for ftp. Hardware handshaking was probably required to avoid problems from transient loads. >I can think of increasing the serial buffers (256 characters sounds low) >and if the problem is interrupt latency, dropping the trigger level on >uarts. Any ideas? You would get silo overflows if the problem was in the interrupt handler. Increasing the buffer sizes would probably fix it. The tty input buffer (of size TTYHOG) must be more than twice as large as the interrupt buffer (of size RS_IBUFSIZE). > > I've heard that some systems 20 times as fast as a 386/16 are too slow for > > a 38400 bps link. >With 16550's? Less than 300 interrupts per second? Actually with 8530's (?), but it's not hard to find examples where serial interrupts would be delayed for several ms if the serial driver didn't use fast interrupts. Consider this code in syscons/update_leds(): s = spltty(); kbd_cmd(...); kbd_cmd(...); splx(s); Last time I checked, my keyboard took a ms or two to set the leds. That is the best case. If the keyboard is disconnected, then kbd_cmd() will take about 1 second to time out. Any driver that polls may cause this type of denial of service. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506190051.KAA11834>