Date: Mon, 1 Jul 1996 05:13:18 +1000 From: Bruce Evans <bde@zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, bde@zeta.org.au, hdalog@zipnet.net, msmith@atrad.adelaide.edu.au Cc: Kevin_Swanson@BLaCKSMITH.com, chuckr@glue.umd.edu, freebsd-hardware@FreeBSD.org, jparnas@jparnas.cybercom.net Subject: Re: muliport boards - building a PPP dialup server Message-ID: <199606301913.FAA24422@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> This is below the breakeven point. >Only if you assume no other interrupt-driven I/O is going on, and that >no other code has critical sections where interrupts are masked (or where >task switches don't happen, so that the TTY driver's buffers in RAM can't >be emptied). This is a good assumption. In FreeBSD, sio and cy interrupts have priority over all other interrupts. There is a problem if there are multiple serial boards of different capabilities on separate interrupts or under separate drivers (e.g., a 16-port 16550 board would starve a 1-port 8250 board). There would be problems if other drivers had high priority interrupt handlers. Then it might be necessary to prioritize or fairly schedule the interrupt handlers. This would normally involve returning from each interrupt handler after doing as little as possible to give the scheduler a chance to pick the highest priority interrupt. >Add moderate to heavy disk I/O and things can REALLY break down. You may Nope. In FreeBSD, disk i/o has no effect on serial interrupt handling in FreeBSD (except DMA may steal cycles). >recall that, a few months ago, I had to rewrite parts of the wd drivers >to disable a hard disk's "sleep" feature, and discovered that they busy >wait -- the maximum wait is several seconds, in fact -- in the kernel. >This can cause FIFO overruns in the TTY drivers if not in the UARTs. Certainly not in the UARTs. There's nothing special about the serial drivers here (except that their lowest level will keep working). The wd driver may interrupt any interrupt handler except the clock interrupt handler. It increases the interrupt mask to the union of bio_imask and the previous mask. If it then busy-waits, it blocks disk interrupts and everything that is already masked. Lossage is most likely for network input at 100 Mb/s. Tty input will most likely be lost due to applications not being able to run to read the tty buffers. >Thus, when in doubt, I always go for extra buffering. I have been using a >Hayes ESP (the old one, whose 1K receive buffers are hidden) on the busiest >ports to provide an extra margin of safety. With the MTU set to about 500 >characters, two whole PPP packets can fit in time of need. This won't make much difference under FreeBSD. It may even be harmful. The pseudo-dma buffers are sized suitably for 16550s. If the UART's fifo is larger than about 128, then the pseudo-dma buffers won't be able to take all the input. Flow control may fix the problem in practice (just like it does for a modem with a bug buffer connected to a UART with a small fifo). OTOH, hugh tty buffers are necessary if the system is swapping heavily or is running many hog processes. E.g., with 100 hog processes running for 1/10 second each, you need 10 seconds worth of buffering - 115 KB tty buffers! The default tty buffer size of 1KB isn't even enough for one hog process. Flow control may fix this problem in practice. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606301913.FAA24422>