From: creed@taligent.com (Creed Erickson) Subject: Re: 16550A FIFO IRQ setting question and ideas Date: Fri, 2 Jul 1993 18:46:52 GMT
In article <1993Jul1.025919.890@n5ial.mythical.com>, jim@n5ial.mythical.com
(Jim Graham) wrote:
>
> Oh, good....a fun one! I love datacomm issues (I suppose that's why I made
> a career of it...that, or it's just one of those strange, unexplainable
> things <grin>).
>
> In article <1993Jun30.062729.5571@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro)
> writes:
>
> >When doing a trace on a kermit process under Linux, data often came
> >in in 8 byte chunks. I figured this might be related to the set-up of
> >the FIFO's on the UART, i.e. how many bytes must be received before an
> >IRQ is triggered. I looked through serial.c and serial.h and noticed
> >that there is a FIFO control register which can set the FIFO trigger
> >to either 1, 4, 8, or 14 bytes.
>
> This has to do with the way the 16550 operates. Basically, it can be set
> to wait until either a certain number of characters are in the FIFO, or a
> certain amount of time has elapsed before issuing an interrupt. The idea
> here is that the software will then receive *ALL* of the characters that
> are waiting in one interrupt cycle, thus reducing the amount of overhead
> used in context switching.
>
Please allow me to correct/clarify on a fine, but important, point here:
The 16550 FIFO can do nothing to reduce the context switching overhead,
that's a run-time constant. What does happen is the number of interrupts,
and hence the number of trips into the kernal, are reduced with
consequential reduction of overall system load. To the practically minded,
this may be a trivial distinction, but there are significant technical
differences. Anyway, this is not the major advantage of the 16550.
> The adjustment is used for fine-tuning, but setting the trigger at 14 bytes
> is potentially dangerous. If you're doing high-speed I/O, and your system
> is also very busy, the CPU might not get around to processing the serial
> port interrupt for a while. During this time, the FIFO could overflow if
> you haven't left it any breathing room. I'd suggest setting it back to
> 8 bytes.
This is the crux of the issue. If the interrupt dispatch latency is > one
character time (say 260 microseconds for an 8N1 38400 connection), then the
UART might be overrun. Using the FIFO set to interrupt on the 1st byte,
there is 16 times the tolerance (roughly 4.1 milliseconds in this example
scenario) for the kernal to respond. Setting the interrupt to the 4th byte
will quarter the number of interrupts for streamed data (e.g., a file
transfer) while still allowing the interrupt dispatch about 3 millseconds
to respond.
How this should be balanced for any given system is dependent on many
points, not the least of which is how the port is typically used.
Nevertheless, as a rule of thumb for multi-tasking systems, I would
recommend you set it to either 4 or 8.
=====
Creed Erickson creed@taligent.com
Spurious Interrupt, System Environments Group, Taligent, Inc
FAX (408) 253-8927 My opinions, not Taligent's