Date: Thu, 13 Nov 1997 21:25:13 +1100 From: Bruce Evans <bde@zeta.org.au> To: mouth@ibm.net, tlambert@primenet.com Cc: bde@zeta.org.au, hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Message-ID: <199711131025.VAA08134@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> Why can't we handle large bursts of input? > >Bruce can correct me, but I believe it's because the FASTINTR code >expects to run to completion, and that expectation means that it >can't take more than a small amount of time to process the interrupt. >Processing the additional caharacters puts it over the limit. This becomes important for some fifo size, but the immediate problem is that one of the watermarks only has 64 characters of headroom. There are also some limits from having to fit the headroom in a 256 byte software fifo. The buffer size was chosen to support speeds of up to 115200 bps, without much thought given to fitting the headroom. Fastintr handlers are already not so fast with 16550s. The normal worst case is sending 16 characters and receiving 15 characters and handling a modem status change. This takes about 70 usec with a reasonably fast processor on an 8MHz ISA bus. (It can take much longer, perhaps infinitely long, if the modem status changes a lot.) This means that 3 active 16550s may increase the interrupt latency too much for a 16450 to work at 115200 bps (the maximum viable latency is 87 usec), and 3 active 16550s may increase the interrupt latency too much for another 16550 to work with the default agressive fifo trigger level (the maximum viable latency is 2*87 usec). Multiply some of these numbers by 4 for 64-bit fifos and you have seriously high (normal worst case) latencies. (My definition of ``high'' is anything that would stop an 8250 from working at 115200 bps - 87 usec :-). I will reduce this when faster speeds become common.) Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711131025.VAA08134>