Re: Interrupt statistics?

From: Bruce Evans <bde_at_zeta.org.au>
Date: Wed, 15 Oct 2003 07:02:50 +1000 (EST)
On Tue, 14 Oct 2003, Nate Lawson wrote:

> On Mon, 13 Oct 2003, M. Warner Losh wrote:
> > In message: <20031013105145.J28323_at_root.org>
> >             Nate Lawson <nate_at_root.org> writes:
> > : Given that, my biggest concern now is IO corruption.  Are there any
> > : devices that have a low interrupt rate (or bus mastering rate) that cannot
> > : handle a few hundred us latency added to their handler startup?  I'm
> > : thinking something like a floppy drive where the time between interrupts
> > : is great enough that cpu_idle() is called but that need to be serviced
> > : quickly or data is over/underrun.
> >
> > sio/uart
> >
> > At 115200 baud, you have 173us to service the interrupt when the FIFO
> > interrupt level is set to HI.  At 460800 at HI you have 43us.  With
> > the more conservative MED settings, these numbers are 4 times better
> > (670us and 173us).  200us is smack dab in the middle of these times.
> > This is inbound data, so things could be idle and there be issues.
> >
> > Not sure about other devices.
>
> Ok, I've instrumented the driver and found that most of the time, sleeps
> are 2-6 ms.  Once in a while, they are a few hundred us.  Rarely, they are

5 ms would be average with HZ=100.

> tens of us.  I'll test the driver with periodic serial IO to see if there
> is any data loss.  I assume it's ok to tell people who are running high
> serial port speeds to disable the lowest sleep states.

I thought that serial devices weren't being considered because you asked
about devices with a low interrupt rate.  As I understand it, devices with
a fast interrupt rate will prevent any sleeping by interrupting often.

If they are a problem, then the above numbers need adjustments:

At 115200 bps (no bauds please), you have
(86.8 * (rx_fifo_size - rx_fifo_trigger_level)) us to service the
interrupt.  With unbuffered UARTs or with buffered UARTS and the trigger
level set to 1 less than the size, you have 86.8 us.  At 3686400 bps
you have 2.713 us worst case (I've tested 3686400 bps on a Celeron366
but can't quite get it to work; 921600 bps works well enough to not
lose interrupts).  That is for one port.  For multiple ports, the time
between interrupts may be much shorter than the inter-character time,
but it can't be much shorter or the system would overload.  The
conservative MEDH settings are the default for FreeBSD, but at 921600
bps they only give half as much time as the HI settings do at 115200
bps, so they should not be needed unless there are many active ports
(else 921600 bps and unbuffered 115200 bps won't work).

> > the more conservative MED settings, these numbers are 4 times better
> > (670us and 173us).  200us is smack dab in the middle of these times.
> > This is inbound data, so things could be idle and there be issues.

sio actually has more problems with outbound data at 921600 bps.  Output
interrupts normally occur just 1 character time before the output
completes, so at 921600 bps there is only 10.8 us to respond before
missing opportunities to send, and it is easy to be doing something else
for 10.8 usec (e.g., reading the input fifo for the same UART or filling
the output fifo for another UART, not to mention other system activity).

Bruce
Received on Tue Oct 14 2003 - 12:04:32 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:25 UTC