Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!gatech!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Modem setup on 386BSD [and a further QUESTION] Message-ID: <1993Jun3.224514.24938@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University (Ogden, UT) References: <C7wwwJ.4Ku@flatlin.ka.sub.org> <1993Jun1.224734.10343@fcom.cc.utah.edu> <C80Dpn.C50@flatlin.ka.sub.org> Date: Thu, 3 Jun 93 22:45:14 GMT Lines: 180 In article <C80Dpn.C50@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes: >In <1993Jun1.224734.10343@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > >>In article <C7wwwJ.4Ku@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes: >>>In <1993May30.065415.28948@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >>>>Even if this isn't a problem, polling all the cards and reading one byte >>>>from one or more of them is going to limit the overall throughput >>>>something fierce. >>>Yeah right. If that were the case then FAS wouldn't be able to >>>sustain 115kbps on dumb boards with 16550s with precisely this >>>technique. > >>Nonsense! > >Now what's that? Are you telling me that FAS isn't able to achieve >the throughput it achieves with the polling technique it uses or what? No, I am saying that those techniques are relatively expensive, and that you *WILL* be paying for them in terms of the amount of CPU left over to do other things (like running comm software or doing swapping) being reduced. On a 486/DX50, you probably wouldn't see it. On a 386/SX16 it`s going to eat you alive and you probably won't be able to do much more than serial I/O. It's *not* scalable in any sense of the word. >You seem to be saying: "if you poll several UARTS sharing an interrupt >for available characters when an interrupt occurs that puts a severe >limit on the maximum throughput that can be achieved." (If that's not >what you are saying I suggest you express yourself more precisely.) Yes, I am saying that polling chips to see if they generated an interrupt, then reading the character out of the chip that did it is more expensive than simply reading the character from the chip that generated the interrupt without doing the additional inb's. >I respond: "FAS uses this technique and it's not experiencing a severe >limit." (And FAS puts an amazingly small load on the system, much >smaller than any vendor supplied driver for 386 Unices I have seen.) > >Now tell us again that FAS can't possibly achieve the throughput it >sustains day in day out on hundreds (if not thousands) of 386 UNIX >system throughout the whole world. Nope, that's not what I said. Not to down FAS, but polling is a bad technique to use. A driver that uses an interrrupt and a poll takes more CPU time away from UNIX (or a UNIX clone) doing other things besides serial I/O than does a driver that just uses an interrupt. More instructions, especially ones that do bus I/O, equals more time to do the same job. >>I've been able to do the same thing in commercial DOS, UNIX, >>and MS-Windows serial drivers I've written; the point is to do serial >>I/O at the expense of everything else. > >No, the point is to do serial I/O NOT at the expense of everything >else. And FAS succeeds in doing so. In fact it puts one of the >smallest loads on the machine for highspeed serial drivers. No, that is the *ideal*, not the *point* in writing a high speed serial driver. Eventually, you *must* pay for the bandwidth, and you do it by stealing processing time away from other tasks; the point is to maintain the bandwidth at the expense of other tasks -- basically, the serial driver tends to be a real-time task for the operating system. If you do *not* steal time away from other tasks, you *must* drop characters on the floor. A supposedly high speed serial driver can *not* drop characters on the floor, or it isn't high speed... it a low speed serial driver with high burst rates sometimes. >>You take one interrupt, and >>then instead of waiting for the next interrupt, you mask them and poll >>like hell keeping a contiguous missed character count, on the theory >>that serial communications are "bursty". > >Obviously you don't know zilch about the inner workings of FAS. It >doesn't mask the interrupts and doesn't poll like hell, it just >empties the FIFOs in the UARTS (be they 1 byte deep for a 8250 or 16 >byte deep for a 16550). It's obvious that this must be taking place on hardware capable of taking 11,500 interrupts a second (for 115K with a 1 byte deep FIFO), and that this is not necessarily the normal capability of all PC hardware. If you don't actually poll, you have to take interrupts at an extremely high rate. The 16 character FIFO on a 16550 drops this down to a more reasonable 719 interrupts a seconds that *must* be processed, since any slower results in the FIFO overflowing. I defy you to get 115K baud on an old Leading Edge model M or model D with the default serial hardware without taking one interrupt, disabling subsequent interrupts, and polling like hell. Yes, it's an old 8086 box and not germane to UNIX, but a 386/SX16 isn't much better, especially with 8250's. The interrupt processing latency is just too high, even if you pull tricks like direct queue-to-large-buffer on interrupt and post-apply-parity on buffer-to-buffer copying after interrupt processing. >>Any idiot can do 115k. > >Now is that intended to insult me or all those programmers of UNIX >serial drivers that are incapable of reliably taking input at above >9600 bps? No, it's intended to draw a distinction between doing 115k on a particular piece of hardware and doing it on all hardware and doing it well (inexpensively as possible to the other tasks the CPU is performing). As to 9600 baud, there should be no problem up to 19.2 or 38.4, depending on the number of devices being serviced (or 9600/19.2 if the UARTs have to be asked if they caused the interrupt in a shared interrupt situation), so if that's a stab at unreliable 9600 baud, then so be it. If it has been done, it can be done, and no amount of hand-waving will make it impossible; there are 38.4 drivers therefore a 38.4 driver can be written. >>This is complicated under DOS by stupid keyboard interrupt handlers > >But we're not talking about DOS, we're talking about UNIX. The costs in doing interrupt processing is (or should be) similar, and DOS provides a good example of nearly 0 overhead (since it doesn't have anything better to do with it's single task than process interrupts from a serial port that needs it at the time). It gives us a model for the best performance we can expect if we make that performance at the expense of everything else. THis was simply an issue for that model. >>The problem in checking "data available" on each serial device is that >>this takes as much time as reading multiple characters, and thus isn't >>a friendly thing to do if the "data available" indicators are spread >>over several chips. > >But you have to do it anyway since an interrupt does not carry the >information of its cause. I.e. before you can read a character from >the UART you first have to check if one is available. And of course >the indicators are spread over several chips, because each UART knows >nothing about the internal state of other UARTs. Only if you are trying to do something which DOS (and therefore PC hardware) wasn't designed for: Running COM1/COM3 or COM2/COM4 at the same time. If you don't try to multiplex IRQ's, you don't run into the extra overhead of asking if this UART is the one that caused the interrupt. Multiport boards are a different matter entirely, since there is on-board hardware multiplexing of the interrupt and, generally, supplementary memory to help with small FIFO depths. Don't multiplex interrupts; if you absolutely *must*, be prepared for a lot of pain getting there and a performance loss during demultiplexing in software. >And even *if* interrupt sharing between separate boards on the bus >worked (as, say, on the MCA bus) I don't see how you possibly could >divine the number of interrupting devices out of the fact that the >interrupt routine for a certain vector has been called. You *POLL* and accept the *FACT* that *POLLING COSTS MORE THAN NOT POLLING*, which is the *ENTIRE* problem with interrupt sharing and why it should be *AVOIDED* no matter how nifty the driver software is:there is a hardware limit implied which get worse when doing demultiplexing. >I wonder what the interrupt identification register in the UART is >supposed to be good for. Correctly designed hardware. The PC is *NOT* an instance of this. Obviously, Intel felt that their UART might be used in real hardware someday, and, in a rare flash of insight, actually thought ahead (in all fairness, I can't lay the PC entirely at Intel's feet). Look, if you can write something that polls to get the correct UART that's as fast as something that doesn't, then more power to you. I'm only saying it going to be slower than something that doesn't have to poll to do exactly the same thing (like a "smart" board). That may not mean that it can't do the same speed as unpolled UART ID (one UART, one IRQ), just that in going the same speed it will have to steal time from other things on your system, and as such it won't be as good a choice for a driver if it does the polling even if you have only one card in the machine and don't actually *need* to poll. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.