Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.Hawaii.Edu!news.uoregon.edu!hunter.premier.net!news.mathworks.com!howland.erols.net!panix!news.panix.com!not-for-mail From: tls@panix.com (Thor Lancelot Simon) Newsgroups: comp.unix.admin,comp.protocols.ppp,comp.unix.questions,comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc Subject: Re: Best Unix for SLIP/PPP Server- Best Reliability/Cost? Date: 16 Nov 1996 22:45:32 -0500 Organization: Panix Lines: 42 Message-ID: <56m1os$oln@panix2.panix.com> References: <56cfhc$h8b@access5.digex.net> <56igd8$if@anorak.coverform.lan> <56le6q$2c6@panix2.panix.com> <56m0bb$qiq@nntp1.best.com> Reply-To: tls@rek.tjls.com NNTP-Posting-Host: panix2.panix.com Xref: euryale.cc.adfa.oz.au comp.unix.admin:50514 comp.protocols.ppp:15916 comp.unix.questions:91389 comp.unix.bsd.freebsd.misc:31126 comp.unix.bsd.netbsd.misc:4869 In article <56m0bb$qiq@nntp1.best.com>, Matt Dillon <dillon@flea.best.net> wrote: >:In article <56le6q$2c6@panix2.panix.com>, >:Thor Lancelot Simon <tls@rek.tjls.com> wrote: >:>In article <56igd8$if@anorak.coverform.lan>, >:>Brian Somers <brian%anorak.coverform.lan@awfulhak.demon.co.uk> wrote: >:.. >:> >:>Curt pointed out that much of the larger multi-port serial-port hardware for >:>PCs is polled. I'm interested in the impact of this on throughput on those >:>serial ports; Curt, can you tell me more? > > They are (or should) still be interrupts, but possibly fixed-period > interrupts. i.e. one interrupt per millisecond if data is present... > or something like that. This isn't really polled, but it does allow > 486/pentium caches to work better in terms of taking the load. Well, that's going to work about like a DMA-completion interrupt on a serial port that does DMA, I'd think, except that the CPU doesn't have to move the data. The kind of purely polled serial port interface I've seen once before worked with a tight loop that serviced all of the serial ports on the machine: turn off hardware flow control, wait a very short interval, read some data, turn on flow control, go to the next port. You do get a guarantee that you won't get more data than you can handle, this way, depending how much CPU time you are willing to spend spinning through the loop. I seem to remember that they finally had to do this on certain DEC terminal servers to handle all of the ports running at 38400 without losing data. You do get a guarantee that you won't lose data, but the problem is that throughput on each port drops as you add more ports, and drops further as you give the machine other tasks to do. For a terminal server, you can get away with this by ensuring that you have "enough" CPU, but I still am far from in love with this design -- or any similar polled design. Note that serial port hardware that automatically frobs the flow control line when its FIFO hits a trigger point is essentially a refinement of this technique, but I still wouldn't want to run it totally interruptless, and I'd still think that you'd do better with DMA. -- Thor Lancelot Simon tls@panix.COM There's nothing like rancid bear fat to keep you happy. -Perry Metzger