Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!purdue!haven!mimsy!ballast.cs.umd.edu!dna From: dna@ballast.cs.umd.edu (Douglas N. Arnold) Newsgroups: comp.dcom.modems Subject: Best modems for SLIP: summary of responses Keywords: SLIP Message-ID: <17691@mimsy.UUCP> Date: 22 May 89 23:25:27 GMT Sender: nobody@mimsy.UUCP Reply-To: dna@emmy.umd.edu (Douglas N. Arnold) Organization: Dept. of Math., Univ. of Maryland, College Park, MD 20742 Lines: 121 On May 9 I posted the following query to the comp.dcom.modems newsgroup and the suns-at-home mailing list: I'm about to obtain two Sun SPARCstations, which I intend to connect via SLIP over a dialup line across a distance of five or ten miles. I'd like to hear opinions of the best modems for this purpose. I'm interested in peoples' experiences concerning speed, reliability, price, availability, etc. I've heard that PEP modems don't do so well because of the line turnaround time and I've heard that MNP compression has trouble with SLIP packets. Can anyone verify (or contradict)? The replies I received follow (slightly edited). --------------- From: JQ Johnson One point of importance is that telnet traffic is very different from NFS traffic. Telnet is typically 1 or 2 small packets in one direction, then echo and ack. NFS is often a stream of very large packets followed by a response. So a priori the turnaround cost for NFS traffic will be much less than that for telnet and friends. I've been using some Fujitsu 19.2Kb trellis leased line modems, and find that the encoding adds about 60ms latency to the start of each packet. They are full duplex, but the latency translates into longer RTT. --------------- From: weiser.pa@Xerox.COM (Mark Weiser) I use a pair of V.32 9600 baud modems from Codex. They work fine. Avoid modem with compression (MNP), these do not work well with SLIP. --------------- From: Vaughan Pratt I use slip extensively over trailblazers running at close to 18K (line is clean and short). The echo performance is *miserable* compared to a direct line at 9.6K. If you type a burst of characters, the first character is echoed a second later, then the remaining characters are echoed another second later. It is distractingly painful to use slip for interactive work. Some of my delay I think can be attributed to going through a line concentrator at the other end. Timing the round trip delay of echoing single characters without slip, comparing a trailblazer to a Supra 2400 baud modem, it appears that when the trailblazer is used the delay roughly doubles. --------------- From: Sergei A. Gourevitch I can vouch for the fact that Trailblazer plus modems don't do SLIP well. I don't have any reports on which modems do well. --------------- From: watmath!cs.AthabascaU.CA!lyndon@uunet.UU.NET (Lyndon Nerenberg) Your best bet is a *fully* compliant V.32 (ie 9600 FULL DUPLEX BOTH DIRECTIONS AT THE SAME TIME) modem. I know the Hayes doesn't cut it. I haven't tried the Telebit T2500 yet. The T1000/2000 will work although the bac channel delays are noticeable. The version 6 PROMs for the TB's will have onboard SLIP support which will cure that problem. --------------- From: Greg Earle I think I can speak fairly to this; I had my Sun-3/160M at home for about 8 months ... (^: (1) First of all, you will need a robust SunOS 4.0.3 SLIP implementation. I would advise looking in ~ftp/pub/Sun_Patch_tapes_et_al. on this machine: elroy.JPL.NASA.GOV (128.149.1.100) and grab the SLIP distribution from there. This is because it fixes a couple of crucial bugs in Rayan Zachariessen's implementation, and it also adds support for LCK..cua# UUCP/tip-style lockfiles (if you have a SLIP link up and you/someone tries to use tip(1) without a lock file, it wreaks havoc on the SLIP link - trust me). I have also added a (crude) version of a dialer program, that will call the other end up, and prompt for the user account and password to be fed to the other end (uses getpass() so these names are not echoed; enhances security a little). All in all, it's a slightly more robust version than the one you can get from AI.Toronto.EDU. (2) I have been using this version over a Telebit TrailBlazer Plus link to the aforementioned machine, elroy.JPL.NASA.GOV. I should mention that elroy is a poor old Sun-2/170 running SunOS 4.0.1, and it is a main mail/Usenet relay for JPL as well as being the secondary name server for the JPL domain to boot - so a lot of the time, it is VERY loaded and extremely slow. That said, I can say this: the best ping(8) turnaround times I can get on this connection, merely calling within the JPL phone system, is around 1.1 seconds (i.e., 1100 msec.). Remember, this is with 2 TB+'s at each end of the line. To contrast, there is another SLIP link here at JPL, a link which connects an Encore Annex terminal server with SLIP capability, to a Sun which is located in Anaheim CA, about 35 miles away. The nature of this link, on the other hand, is 2 synchronous modems, talking over a 9600-baud dedicated leased line. At each end, there are Black Box converters which switch from Synch to Asynch; the Sun end is plugged into the standard CPU serial port. Not sure about the Encore end; presumed similar. In this case, I was able to ping the remote end of that link from a machine on the same net as the Encore, and was getting consistent turnaround times of 0.3 seconds (i.e., 300 msec.) per packet. So, it seems that even allowing for a factor to creep in (i.e., remote machine overloading due to wimpy old CPU), it seems that the Asynch-Synch leased line method gains a factor of at least 3 in throughput over the Telebit-based method. One thing which we have not tried yet is to try connecting between my machine and elroy at 2400 baud instead, and then see what the ping turnaround times are. We suspect that they won't be much different/worse, and suspect that the non-V.32 nature of the Telebits (we have TB+'s, not T2500's remember) is what is causing the line turnaround slowdowns. FTP's between the two machines are usually running around 800 bytes/sec. ------------------- Thanks to all who responded. I would welcome comments from anyone else who has experience using SLIP with modems. -- Doug Arnold (dna@emmy.umd.edu)