zeeff@b-tech.UUCP (Jon Zeeff) (08/11/88)
In article <531@micropen> dave@micropen (David F. Carlson) writes: > About the serial port problems on the '286. I think serious thought should be given to supporting the NS16550AN. This is a plug in replacement for the existing uart that gives you a 16 byte fifo. At least the problem would go from "there is nothing that can be done" to "you need to buy a new chip". I don't know what the cost is though. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
james@bigtex.uucp (James Van Artsdalen) (08/12/88)
In article <4690@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) wrote: > I think serious thought should be given to supporting the NS16550AN. > This is a plug in replacement for the existing uart that gives you a > 16 byte fifo. At least the problem would go from "there is nothing > that can be done" to "you need to buy a new chip". I don't know what > the cost is though. I believe the part has settable high- and low-water marks also. This means that it can not only prevent lost characters at high speed (due to the kernel having interrupts disabled for long periods), but is can also lessen the system load at high speeds by dramatically cutting the number of interrupts to be serviced. For example, let's suppose uPort modified the serial driver such that when the line was put in raw mode, the 16550AN was set to generate an interrupt every tenth character. The interrupt handler would then get ten bytes for the overhead of one interrupt, and would still have six character times to respond to the interrupt. I think it patently obvious that such a driver would not only let all of the machines run Trailblazer+ at 19.2Kbps, but that it would do so with less system load than 2400bps current takes. There would be a higher user-level load because uucico would be doing more file writes and checksum calculations, but I think we could all live with that. I find it somewhat annoying right now that I can't run my TB+ at 19.2Kbps under any conditions with a fast 386. >:-( As a subtle hint to the various vendors taking a break from the flame wars, you can buy these nifty parts from Arrow Electronics for about $22. Their phone number is 1-800-932-7769. You want the 16550AN part, not the 16550N (the N suffix is just package type: the A is significant). I've already got one sitting in my serial board to prove compatibility - I'd be happy to beta test (hint, hint). -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
dave@micropen (David F. Carlson) (08/12/88)
In article <5909@bigtex.uucp>, james@bigtex.uucp (James Van Artsdalen) writes: > In article <4690@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) wrote: > > I think serious thought should be given to supporting the NS16550AN. > > This is a plug in replacement for the existing uart that gives you a > > 16 byte fifo. At least the problem would go from "there is nothing > > I believe the part has settable high- and low-water marks also. This > means that it can not only prevent lost characters at high speed (due > to the kernel having interrupts disabled for long periods), but is can > also lessen the system load at high speeds by dramatically cutting the > number of interrupts to be serviced. > The PIC (interrupt controller) doesn't "lose" interrupts, it allows them to be masked long enough that the 1 deep fifo on the 8250 family is overrun. Further interrupt events while a pending interrupt is still flagged does nothing to the CPU but the events that they represent are possibly irrevocably lost. > For example, let's suppose uPort modified the serial driver such that > when the line was put in raw mode, the 16550AN was set to generate an > interrupt every tenth character. The interrupt handler would then get > ten bytes for the overhead of one interrupt, and would still have six > character times to respond to the interrupt. > > James R. Van Artsdalen ...!uunet!utastro!bigtex!james But raw mode is defined (often) to return in *less* than 10 characters. The "win" of the fifo is that overruns are nearly impossible, which allows the driver to make interrupt latency almost a non-issue. Getting in and out of an interrupt routine every 0.5 milliseconds is very tough. Having a kernel timer set up to check serial status every 8 milliseconds (when interrupts have been received recently) is very much easier on the OS as a whole and the fifo guarantees that characters would not be lost. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
james@bigtex.uucp (James Van Artsdalen) (08/13/88)
In article <532@micropen>, dave@micropen (David F. Carlson) wrote: > The PIC (interrupt controller) doesn't "lose" interrupts, it allows them > to be masked long enough that the 1 deep fifo on the 8250 family is overrun. > Further interrupt events while a pending interrupt is still flagged does > nothing to the CPU but the events that they represent are possibly > irrevocably lost. This sounds like a distinction without a difference. I don't care *what* part is responsible for the fact that a character was lost ("overrun", if that's what you wanted). All I know is that a character came, an interrupt was signaled, but the CPU saw neither, and the character was lost. Fiddling with the PIC or using CLI are all the same to a lost character... > But raw mode is defined (often) to return in *less* than 10 characters. Specifically, uucp uses a VMIN of 6 when sending data (70 when receiving). Zmodem defaults to 133. Who knows what kermit does - it probably sets up a committee to decide. :-) > The "win" of the fifo is that overruns are nearly impossible [...] That's what I meant to say. But I also think you underestimate the load that 2000 interrupts/sec (19.2Kbps) places on the system - the kernel is rather slow about interrupts. If you reduce the interrupts by a factor of 10 or VMIN, whichever is less, you'll substantially cut system load. In any program that does sustained high-speed receiving (such as Zmodem or uucp), VMIN is already set greater than 1 to cut the potential load of 2000 read(2) calls per second, which probably the kernel couldn't handle anyway. bigtex appears to be able 30% loaded when uucico talks TB+: I imagine it's worse for the 286s. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
rick@pcrat.UUCP (Rick Richardson) (08/13/88)
In article <5909@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes: >In article <4690@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) wrote: >> I think serious thought should be given to supporting the NS16550AN. >$22. Their phone number is 1-800-932-7769. You want the 16550AN >part, not the 16550N (the N suffix is just package type: the A is >significant). I've already got one sitting in my serial board to >prove compatibility - I'd be happy to beta test (hint, hint). I've got four of them in my Digicom/4 on my 286 running Venix SVR2. And one more in a standard IBM serial card. I've been running a very slightly hacked driver since February with these parts. The parts work, the driver changes are very minor. Although my 386 doesn't need the extra help right now, I'm in process of hacking the asy driver to handle these parts as well. Someday the 286 will be retired from being the communications hub around here, and I want to be ready... -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
rick@pcrat.UUCP (Rick Richardson) (08/13/88)
In article <532@micropen> dave@micropen (David F. Carlson) writes: >> For example, let's suppose uPort modified the serial driver such that >> when the line was put in raw mode, the 16550AN was set to generate an >> interrupt every tenth character. The interrupt handler would then get >But raw mode is defined (often) to return in *less* than 10 characters. >The "win" of the fifo is that overruns are nearly impossible, which allows >the driver to make interrupt latency almost a non-issue. Getting in and But the 16550A will automatically timeout and generate the interrupt for less than N characters if something is in the FIFO and it has been idle (I think) 4 character times. -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
zeeff@b-tech.UUCP (Jon Zeeff) (08/14/88)
In article <553@pcrat.UUCP> rick@pcrat.UUCP (Rick Richardson) writes: >>> I think serious thought should be given to supporting the NS16550AN. > >these parts. The parts work, the driver changes are very minor. >Although my 386 doesn't need the extra help right now, I'm in process >of hacking the asy driver to handle these parts as well. Someday While I really think that that uport should be interested in doing this, let us know if you get the '386 patches done. 19,200 support and a lower system load would be nice. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (08/15/88)
In article <4690@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: >In article <531@micropen> dave@micropen (David F. Carlson) writes: >> >About the serial port problems on the '286. > >I think serious thought should be given to supporting the NS16550AN. >This is a plug in replacement for the existing uart that gives you a >16 byte fifo. At least the problem would go from "there is nothing >that can be done" to "you need to buy a new chip". I don't know what >the cost is though. > This chip makes a very large difference to any 286 or 386 based system, provided you have a driver which can utilize it. I'm just finishing a multi-port card driver for a customer which supports this chip (just have to do the install disks). Because it is a commercial product I can't distribute the source but is there any interest in low cost (~$50) version which will support the standard IBM ports and some generic multiport cards? This driver also supports the 8250, and 16450. A fair amount of work went into making the driver as efficent as possible for these chips including an assembler interrupt service loop. Each serial port has three device's associated, with/without modem control and with modem controls for getty. This allows for very simple use of a modem for incoming and outgoing calls without having to turn the getty on and off. Simply enable the getty on the getty device. The open does not complete until carrier is detected. Opens on the other devices are blocked if the getty device is fully open. If they succeed the getty device is blocked until they are finished. Full duplex CTS/RTS flow control is supported. It is enabled with the RTSFLOW/CTSFLOW termio bits if your system has them (late model SCO XENIX) or via a bit in the minor device number. You can configure up to thirty two port addresses, four interrupts, with a maximum of sixteen ports per interrupt. The driver automatically determines whether you are using an 8250, 16450, or 16550 device. Currently the driver runs on Bell Tech 386, SCO Xenix 386, SCO Xenix 286, and IBM Xenix 286. Microport 286 shouldn't be too hard. The 16550 part is available but hard to get. Try Arrow(?) and Hamiliton-Avnet. Cost should be under $30. With this chip in place you get a 16 byte FIFO for both incoming and outgoing data. This substantially reduces the system overhead. One test we did showed that for supporting two outgoing 19.2 datastreams the system overhead was about the same as for a popular smart card doing the same. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
zeeff@b-tech.UUCP (Jon Zeeff) (08/16/88)
In article <1856@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes: > >I'm just finishing a multi-port card driver for a customer which supports this >chip (just have to do the install disks). > >is there any interest in low cost (~$50) version which will support the >standard IBM ports and some generic multiport cards? If you add Microport '286 and Microport '386 support, I think you will find a fair number of customers - '286 users to make things work and '386 users to support Trailblazers. You might also talk about licensing it to Microport - they need it. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu