JGF1@psuvm.psu.edu (04/19/91)
I'm using FTP's SLIP, and my machine locks up at times when I use baud rates higher than 4800. I'm using COM2 on a Compaq 386/33. Any thoughts on what's happening? Thanks!
hedrick@athos.rutgers.edu (Charles Hedrick) (04/19/91)
You asked about SLIP hangin at speeds above 4800 using FTP Inc's SLIP. A few months ago I tried SLIP at home using a 9600 bps modem. I found that as it came "out of the box", only KA9Q works reliably. There were problems in the device-level code that can cause hangs in both FTP, Inc's code and the SLIP packet driver distributed by Clarkson. Fortunately, there are fixes for both. FTP asked me to test their most recent SLIP kernel, and it worked fine. This was as couple of month ago, so I assume anything you get from them now would work. I installed a workaround in the SLIP packet driver, which I believe is available from Clarkson. I'm not an MS/DOS programmer, so I didn't have the expertise to do what I regard as a real fix, however I think for most cases my hack will solve the problem. I should note that FTP doesn't let you adjust the MSS. I found it impossible to get a set of parameters that gave as good responsiveness at 9600 as with KA9Q if the MSS is properly chosen. However this may be academic, since even with with KA9Q tuned as well as I could, I found I preferred Kermit to TCP. My primary objection is echo delay, which means that using header compression should resolve my problem. Unfortunately cisco hasn't chosen to implement header compression on their terminal servers yet, so that isn't available to me. There seems to be a big difference between 9600 and 19200. We use SLIP over 19200 lines in a pilot project in a dorm. It feels quite nice.
it1@Isis.MsState.Edu (Tim Tsai) (04/19/91)
I've been using SLIP8250 at 19.2K for more than half a year now, and I've not had any serious problem with it (I think if I hit scroll-lock during a flurry of screen activities I can lock up the machine. I'm using CUTCP and it doesn't happen at work on an ethernet card. Also if I type something while somebody picked up the phone, I'd lock up the machine as well.. This is understandable though.) At one time I also had two PC's connected together at 38.4K with a null modem cable and it worked fine as well [using FTPBIN. Either Clarkson's 2.2D or CUTCP]. -- Now I lay me down to rest, a pile of books upon my chest. If I should die before I wake, that's one less test I'll have to take.
gordon@FTP.COM (Gordon Lee) (04/19/91)
Attn Russ: this a bug report for SLIP8250
From: Tim Tsai
Subject: Re: SLIP failing at high baud rates?
I've been using SLIP8250 at 19.2K for more than half a year now, and
I've not had any serious problem with it
There's been a lot of talk about SLIP failing in PC's at high speeds,
then again there have been many people like Tim who claim to have seen
no problem. In order to clear up confusion and doubt, here's the story:
It's a Hardware Problem. (I've always wanted to say that for real)
haha, enough fun. The gory detail:
Both the clarkson SLIP8250 driver and FTP's SLIP
driver for PC/TCP are built to drive an 8250 UART chip.
The 8250 UART generates one interrupt for each character sent or
received. A "transmit holding register empty" interrupt tells the
driver that the chip sent the last byte it was asked to send, and now
it is ready to send another. Well, remember that the chip may also
be receiving characters at the same time. Under heavy load, interrupts
of both types may be flying back and forth at high speed, and in weaker
board designs, some are dropped. The trick to a successful driver is
to put a timeout in the loop used to wait for a transmit completion
interrupt. This ensures you don't wait forever (PC lockup).
This only happens in certain hardware setups, I use the following setup
to reproduce the condition: Everex EV170A serial board in an AGI 1700C (286).
I setup this PC and another PC with a SLIP link and let them ping each
other non-stop, eventually, the AGI would hang. The timeout prevents this.
- GL
PS. the fix is in PC/TCP 2.05 pl1 for both SLIP and PPP.
== Gordon Lee FTP Software Inc
== voice: (617) 246-0900 26 Princess St
== fax: (617) 245-7943 Wakefield, MA 01880jbvb@FTP.COM ("James B. Van Bokkelen") (04/19/91)
The intermittent hangs were a result of lost interrupts, and at least somewhat dependendt on whose COM port hardware you were using. The fix is in 2.05 pl1 SLIP.EXE and PPP.EXE. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
JGF1@psuvm.psu.edu (04/19/91)
Thanks for the info. I am using SLIP v2.05. For lack of other things to try, I changed from Com2 to Com1. Works great now.
dag@tc.fluke.COM (David Gunderson) (04/22/91)
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
gordon@FTP.COM (Gordon Lee) (04/23/91)
From: David Gunderson <fluke!dag@beaver.cs.washington.edu>
Subject: Re: SLIP failing at high baud rates?
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.
In the case of most SLIP/PPP drivers, BIOS is circumvented entirely.
== Gordon Lee FTP Software Inc
== voice: (617) 246-0900 26 Princess St
== fax: (617) 245-7943 Wakefield, MA 01880romkey@ASYLUM.SF.CA.US (John Romkey) (04/23/91)
Date: Mon, 22 Apr 91 16:12:39 -0400
From: Gordon Lee <gordon@ftp.com>
Reply-To: gordon@ftp.com
From: David Gunderson <fluke!dag@beaver.cs.washington.edu>
Subject: Re: SLIP failing at high baud rates?
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.
In the case of most SLIP/PPP drivers, BIOS is circumvented entirely.
That was my first reaction, too, but I think what David Gunderson was
saying is that there are other parts of the BIOS, not the COM drivers,
that disable interrupts and may increase the interrupt latency in the
system to the point where it can't help but drop characters.
- john romkey Epilogue Technology
USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141gordon@FTP.COM (Gordon Lee) (04/23/91)
Subject: SLIP failing at high baud rates?
From: romkey@asylum.sf.ca.us (John Romkey)
That was my first reaction, too, but I think what David Gunderson was
saying is that there are other parts of the BIOS, not the COM drivers,
that disable interrupts and may increase the interrupt latency in the
system to the point where it can't help but drop characters.
Thank you for the clarification, I stand corrected and further edified.
== Gordon Lee FTP Software Inc
== voice: (617) 246-0900 26 Princess St
== fax: (617) 245-7943 Wakefield, MA 01880brian@telebit.com (Brian Lloyd) (04/24/91)
For what it is worth, the Telebit NetBlazer supports Van Jacobson's IP/TCP header compression for both SLIP and PPP connections. I can attest to the fact that header compression is a big win as far as echo delay is concerned. I have several systems as home (two PC's, a MacIntosh, and a 386 system running Unix) that use a NetBlazer with one modem to connect to Telebit's network. I have had up to three people doing TELNET or rlogin sharing the same link. Except when all three ask for a full screen update at once, you can't tell that there is anyone else using the link. -- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333
phys169@csc.canterbury.ac.nz (04/29/91)
In article <1991Apr22.151501.18590@tc.fluke.COM>, dag@tc.fluke.COM (David Gunderson) writes: > > All this points out that the PC's implemenation of RS-232 isn't too > robust and shouldn't be trusted in critical situations. > Well, it is at least better than many mini computers where even things like the system clock spoil fast real time responses. The answer is either to install an interface that has a bigger buffer (perhaps with its own CPU - there are a few around) or to write the software to take bursts of data, responding to the first header byte perhaps via an interrupt but then disabling interrupts and polling. You can get 115Kbaud quite easily then. Unfortunately, this latter method is the exact same problem (turning off interrupts for a relatively long period of time) that in other software was causing our problem in the first place! Moral of story: if you want a fast response, you want a dedicated processor. The advantage/disadvantage with the PC is that is is relatively easy to make the main CPU dedicated to what ever job you are interested in, at the expense of others. People should be asking for better bufferring in the IO cards instead, but have developed the cheap-n-nasty habit of grabbing the main processor for the job, a trick that is fine if you're the only one that wants it. Even then, when it comes to some networking jobs, e.g. X-windows, you can't really beat a dedicated processor for value for money. Getting the main CPU to respond to trivial jobs quickly is like training an elephant to tap-dance! Just my thoughts, Mark Aitchison, Dept. of Physics, University of Canterbury, New Zealand.