Xref: utzoo comp.unix.xenix:8688 comp.unix.i386:1381 Path: utzoo!attcan!telly!eci386!jmm From: jmm@eci386.uucp (John Macdonald) Newsgroups: comp.unix.xenix,comp.unix.i386 Subject: Re: Equinox multi port boards Summary: why polling drivers can be a big win Keywords: polling interrupts com driver Message-ID: <1989Nov23.170735.10026@eci386.uucp> Date: 23 Nov 89 17:07:35 GMT References: <458@gallium.UUCP> Reply-To: jmm@eci386.UUCP (John Macdonald) Organization: R. H. Lathwell Associates: Elegant Communications, Inc. Lines: 82 In article <458@gallium.UUCP> garyb@gallium.UUCP (Gary Blumenstein) writes: > > [ a very favouable review of the Equinox 24 port serial board ] > > Also, >I don't fully understand how this board can install without using an IRQ. >It is advertised as using "polling" and that this makes a faster setup >when used with a well written driver. Can someone explain this? When an interrupt occurs, the system must stop executing the user process that was being executed, save all register and control information needed to be able to restart the process that might be affected by running the interrupt handling routine, invoke the interrupt routine, check whether a different process has become highest priority because of the interrupt, and restart the (old or newly available) user process. If the interrupt is occuring because of an input character from a com board, then the amount of work to process the input character (the total time spent in the interrupt handling routine) is generally much less than the amount of work involved in getting in and out of the interrupt handler routine (as described in the above paragraph). Most (if not all) systems have a clock interrupt that is used for controlling system internal timing functions (like time-of-day, driver timeouts, and user process alarms). This interrupt generally occurs a number of times per second (60 or 100 is typical) - the number is chosen by the system implementors to provide a good balance between getting the smallest time resolution needed and putting the smallest possible load on the system with the interrupt handling. A polling device driver arranges to have the timer interrupt handler invoke it occassionally (perhaps 10 times per second). Since the interrupt overhead has already been budgeted for the clock interrupt, there is no extra overhead for the system to invoke the polling driver (except a function call, but that is trivial compared to the process state saving and restoring). The polling driver then checks to see if there is any work for it to do, does what it can, and then returns to the clock interrupt handler. This makes the clock interrupt take slightly longer for no reason whenever there is nothing that must be done on for the polled device. However, it saves one or more (possibly a huge number) of process state save and restore operations whenever there is work that it can do. A com board's input is an especially good match for this type of handling. On output you usually can set up a large buffer of characters to send at once, and this can usually be done so as to only generate one interrupt, so there is not much difference (although a polling driver can keep filling the output buffer before it is fully emptied, so there is some gain here). On input, however, such buffering is not easily done. When a character arrives, the system has no way of telling whether it is necessary to process this character immediately, or whether it is save to wait a while, so interrupt-based drivers must usually get an interrupt for every incoming character. (If the driver falls behind, it may end up processing more than one character per interrupt, but in that case the system is being overloaded by the input processing and cannot continue with anything else until the input level slows down.) With a polling driver, there is no need to get an interrupt - the character will be picked up by the next poll. If input is coming at 9600 baud, then there might be 100 characters all processed during a single (tenth of a second) poll. At high baud rates, there might be more processed at once. If multiple ports are active, more might be processed at once also. A human user will not notice a tenth-second delay in echoing (if they do, then the polling could be done more often). A machine to machine transmission will normally be done without echoing, but even if there is echoing, the first character will be delayed and then both input and output will proceed at full speed. Of course, a polling device driver is not always the best choice. To work well it requires that the hardware be able to take care of itself for long periods of time. Thus a com board must have enough intelligence to collect lots of input characters and buffer them until the polling driver happens to come along and accept them. It is generally not appreciated for input characters to be lost because of insufficient buffering. It is also desired that there be enough output buffering to be able to maintain full speed, since sending one character at 9600 baud every tenth of a second looks much the same as full speed transmission at 100 baud. (A processor is not necessarily required to make a polling driver possible, a UART with 100 character input and output buffers could be handled this way as long as the polling frequency is high enough to sustain the transmission rate without loss.) -- 80386 - hardware demonstrating the fractal nature of warts. | John Macdonald EMS/LIM - software demonstrating the fractal nature of warts. | jmm@eci386