Date: Sat, 29 Jun 1996 06:34:55 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: jparnas@jparnas.cybercom.net, chuckr@glue.umd.edu, Kevin_Swanson@BLaCKSMITH.com, freebsd-hardware@FreeBSD.org Subject: Re: muliport boards - building a PPP dialup server Message-ID: <199606291034.GAA03826@hda.com> In-Reply-To: <199606290719.QAA20648@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jun 29, 96 04:49:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Fast has nothing to do with it. Interrupt rates do. > > You should sit down and read some of the stuff that Bruce Evans has posted > on the subject over the years; most particularly his analysis of where the > actual load in handling serial ports comes from. Some key points : > > - A 486 can service around 40,000 ISA interrupts per second, assuming > minimal interrupt processing time. > - Most of the CPU overheard in handling serial in/output is in the tty > layer. As you know once you're in the interrupt routine it will check all ports, meaning that in the special case of input streaming in on multiple ports you will have a big reduction in interrupt load. I second looking up some of Bruce's postings. Now a few caveats I should have included in my last message about four ports continuous at 115200, since it doesn't translate over to general usage. I'm using my own software in a dedicated environment. I had to look in the driver to find the "right" settings of TTY flags to get a fast path through the driver, and I'm wondering if I'll have to tweak things when I upgrade the OS. The data is only coming in - nothing is going back out again. I can't vertically scroll an Xterm with the serial mouse without dropping input on the streaming data during a test session. If we were to double the size of the test stand to 8 devices I'd take a page from Henry's book and dedicate a small 486 to collect the data and then send it to the analysis system over ethernet. However, it is actually five ports at 115200, since we have a debug port running the same software to the same type of device that we think nothing of using during a collection sequence. And I sometimes establish a PPP link at 57.6 on a modem control line while the testing is going on. The overhead on the system is not dramatic - you don't notice that anything is going on other than the "xterm scroll" problem. We stay in X, leave drives NFS exported, etc. -- Peter Dufault Real-Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606291034.GAA03826>