Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.erols.net!www.nntp.primenet.com!nntp.primenet.com!news1.best.com!nntp1.best.com!usenet
From: dillon@flea.best.net (Matt Dillon)
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: 17 Nov 1996 08:17:53 GMT
Organization: BEST Internet Communications, Inc.
Lines: 73
Message-ID: <56mhnh$6jg@nntp1.best.com>
References: <56cfhc$h8b@access5.digex.net> <56le6q$2c6@panix2.panix.com> <56m0bb$qiq@nntp1.best.com> <56m1os$oln@panix2.panix.com>
NNTP-Posting-Host: flea.best.net
Xref: euryale.cc.adfa.oz.au comp.unix.admin:50521 comp.protocols.ppp:15918 comp.unix.questions:91397 comp.unix.bsd.freebsd.misc:31136 comp.unix.bsd.netbsd.misc:4871
:In article <56m1os$oln@panix2.panix.com>,
:Thor Lancelot Simon <tls@rek.tjls.com> wrote:
:>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
On a pentium class machine, DMA would yield at least a 5:1 improvement
in cpu efficiency, mainly because the cpu doesn't stall doing the I/O
reads individually. With DMA, the data is already in memory, and the
cpu can snarf it up at memory speeds rather then I/O speeds, and most
pentium chipsets decouple the PCI/ISA DMA from main memory bus (i.e.
no stall).
The standard way to do serial I/O in this fashion is to have a idle
timer... if you are DMA'ing in blocks of 256 bytes, and 200 bytes come
in, the idle timer times out after X ticks to close out the DMA. Most
FIFO-based serial chips like the signetics series chips use the same
trick, but make it transparent. So even though you are getting
character rates of, say, 11.5 KBytes/sec, you only get one interrupt
every X characters rather then an interrupt for each character. However,
you still pay the instruction-stall overhead if you are read data from
the I/O board with the cpu (FIFO or not), whereas you do not pay the
stall overhead with DMA.
On a 200 MHz pentium, stalls are *very* costly... if a typical
I/O read from an ISA card takes 1uS, you just stalled a single
instruction for 200 cycles! Thus, you can probably do 5 to 50 times
the number of serial ports with a PCI+DMA or ISA+DMA solution then you
could ever do with a ISA+READ-ON-INTERRUPT solution. This is probably
part of the impetus to going to SCSI device based multi-port serial
devices... SCSI controllers are almost always DMA based.
-Matt