Date: Wed, 15 Oct 2003 07:02:50 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Nate Lawson <nate@root.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: Interrupt statistics? Message-ID: <20031015062929.P42153@gamplex.bde.org> In-Reply-To: <20031014104224.R31046@root.org> References: <20031011234314.P23991@root.org> <20031012.095503.129593225.imp@bsdimp.com> <20031014104224.R31046@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Oct 2003, Nate Lawson wrote: > On Mon, 13 Oct 2003, M. Warner Losh wrote: > > In message: <20031013105145.J28323@root.org> > > Nate Lawson <nate@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031015062929.P42153>