Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!howland.reston.ans.net!sol.ctr.columbia.edu!xlink.net!smurf.sub.org!flatlin!bad From: bad@flatlin.ka.sub.org (Christoph Badura) Subject: Re: Modem setup on 386BSD [and a further QUESTION] Organization: Guru Systems/Funware Department Date: Wed, 2 Jun 1993 19:20:10 GMT Message-ID: <C80Dpn.C50@flatlin.ka.sub.org> References: <1u81il$o45@wzv.win.tue.nl> <1993May30.065415.28948@fcom.cc.utah.edu> <C7wwwJ.4Ku@flatlin.ka.sub.org> <1993Jun1.224734.10343@fcom.cc.utah.edu> Lines: 126 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? 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.) 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. >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. >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). >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? >This is complicated under DOS by stupid keyboard interrupt handlers But we're not talking about DOS, we're talking about UNIX. >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. Now if we were talking about Z8530 SIOs, which we aren't since this is c.o.386bsd.questions and SIOs aren't exactly in widespread use in PC, you could make a point in getting more information out of the interrupt vector. But even if we were talking about Zilog's SIOs that wouldn't matter because the PC design doesn't allow for getting an interrupt vector from an arbitrary device. >This isn't the case for the 16550, This is most definitely the case with 16550s since there is a) no way such a chip could possibly gain knowledge about the internal state of other UARTS and b) there is no register from which you can get the number of characters available in the FIFO. >As has been pointed out here time and again, the main limitations are >the serial hardwares TTL connection to the bus (whether a non-asserted >IRQ line is held low or just floats) and the ability to handle interrupts >in a slightly different way (which means all hardware has to support it, >since the masking methodology changes for ALL interrupts in this scenerio). I don't know how electrical limitations in the ISA bus design that prevent interrupt sharing between different boards are relevant to my comment. This affects in know way the need to poll all the UARTs that share an interrupt. You are gatuitously digressing from the subject. 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. >Multiport boards get around this by keeping the data available seperately >for each UART and handling the IRQ signalling using a common mechanism; >this is what Digiboard and Control Systems Hostess boards do. Right but irrelevant to my comment. >[irrelevant discussion about the line discipline handling of some >"smart" serial boards omitted.] >Generally, you will *Never* get interrupt sharing to work happily on >serial ports on seperate boards without some changes, Right, but still irrelevant to my comment. >On the UARTs on Tandy and Zenith machines I've worked with, the fact >remains that there is no register available to determine if a specific >card caused the interrupts, and these are nominally considered PC >hardware. I wonder what the interrupt identification register in the UART is supposed to be good for. -- Christoph Badura --- bad@flatlin.ka.sub.org Personally, I don't care whether someone is cool enough to quote Doug Gwyn--I only care whether Doug Gwyn is cool enough to quote. -- Larry Wall