Newsgroups: comp.protocols.tcp-ip.ibmpc
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!fluke!dag
From: dag@tc.fluke.COM (David Gunderson)
Subject: Re: SLIP failing at high baud rates?
Message-ID: <1991Apr22.151501.18590@tc.fluke.COM>
Organization: John Fluke Mfg. Co., Inc., Everett, WA
References: <9104191316.AA14684@ftp.com>
Date: Mon, 22 Apr 91 15:15:01 GMT

The reason that you can "lose" interrupts on the PC COM ports is not
entirely related to the COM port hardware itself. There are some
BIOS implementations (mostly related to display adapters) that feel
free to disable interrupts (execuite a CLI instruction) any time
they want to. At 19.2K baud, you have approx. 0.5 ms between characters.
If interrupts are disabled for longer than this, an incoming character
will overrun the last character received before it can be removed from
the input buffer. If the COM port interrupt handling software detects
overrun, a re-transmit can be requested, but if not, a character is
lost.

I also had a recent problem with "very fast" machines (a 486 EISA bus
machine running 33 MHz). In this case, the UART issued the interrupt
request and the interrupt processing routine was entered before the
input character was ready in the receive buffer. This caused a problem
in the state logic of the UART (in this case, a ASIC clone) where the
software thought the interrupt had been cleared and the hardware thought
it was still pending. The "FIX???" is to insert delay within the interrupt
processing routine, but who wants to do this. I had to to get the program
working, but it makes me feel really bad to slow something like that down.

All this points out that the PC's implemenation of RS-232 isn't too 
robust and shouldn't be trusted in critical situations.

--David Gunderson