Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: SLIP failing at high baud rates? Message-ID: Date: 19 Apr 91 06:57:57 GMT References: <91108.150403JGF1@psuvm.psu.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 22 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.