Date: Mon, 13 Jul 92 09:41:51 EST From: Dwight D. McKay (The Moderator) Reply-To: Suns-at-Home@orchestra.ecn.purdue.edu Subject: Suns-at-Home Digest V5 #28 To: Suns-at-Home-List Suns-at-Home Digest Mon, 13 Jul 92 Volume 5 : Issue 28 Today's Topics: Info on SCSI serial multiplexors PPP, T1600, and interactive delays Suns-at-Home Digest V5 #27 [PPP delays --ddm] +--------------------------------------------------------------------+ | Submissions: suns-at-home \ @orchestra.ecn.purdue.edu | | Requests: suns-at-home-request > -- or -- | | Archives: suns-at-home-archives / ...rutgers!pur-ee!... | +--------------------------------------------------------------------+ ---------------------------------------------------------------------- Date: Mon, 13 Jul 92 01:33:23 +0300 From: Vassilis Prevelakis Subject: Info on SCSI serial multiplexors To: Suns-at-Home@ecn.purdue.edu Some time ago I remember seeing an add for a box with 8 or 16 serial ports that could plug into the SCSI port of a Sun. Does anyone have any details about such a product (prices, company address etc) Thanks **vp vp@ariadne.csi.forth.gr Vassilis Prevelakis ------------------------------ Date: 9 Jul 92 22:33:00 EDT From: Karl (K.B.) Klashinsky Subject: PPP, T1600, and interactive delays To: suns-at-home@orchestra.ecn.purdue.edu, dan@diamond.bbn.com Hiya. This came up about six months ago on one of the comp.protocols newsgroups. Someone had discovered that the delay was introduced intentionally in the TCP layer. Apparently, under normal network circumstances, the delay is not noticeable, but when the "network" is a point-to-point link across a modem, the extra delay becomes an issue (as Dan has discovered). Their solution was to obtain the BSD source for telnet/telnetd, and modify them so that the TCP_NODELAY socket option is used. This socket option eliminates the delay mentioned above. I use SLIP to connect my Sun3 to the network at work. I installed the "hacked" telnet (on my Sun3 at home) and telnetd (on my Sparc at work), and have been using it for over six months. Does it help? Well, when I first installed it, I did notice a difference, but it may have been subjective. Hope that helps. ------------------------------ Date: Thu, 09 Jul 92 21:43:17 EDT From: smb@ulysses.att.com Subject: Suns-at-Home Digest V5 #27 [PPP delays --ddm] To: Suns-at-Home@ecn.purdue.edu Dan Franklin complains about PPP delays, and wonders, incredulous, if they could be the modem's fault. Yup, that's the problem; I've done some fairly elaborate measurements to prove it. And the T1600 is among the worst of the lot, though I haven't tested any yet that I consider to be really good. I don't have the exact numbers handy, I'm afraid. A cure? None that I know of, short of switching modems. The T3000 is better, as are the AT&T Paradyne 3820, the AT&T 2296, and the UDS V.3225. I've heard that some USR modems are low-delay, but I haven't measured any. My technique is fairly simple. I use a SPARCstation, because of the high-resolution clock. I have one process sitting there, reading bytes, and writing out timestamps to a file. I have another that writes single bytes, and records timestamps. I then merge the two files, and subtract the timestamps. I characterize the delay by the median of a few hundred trials. I calibrated this by putting a loopback RS-232 connector onto my machine. The delay was something like 18 ms. I then tried a modem, in local loopback mode. Local loopback goes out to the phone line interface, and then back in, testing all of the modulation and demodulation circuitry. I subtracted the control case from the local loopback, to determine the round-trip time through the modem. To test remote modems, I dial them up, then exit to modem command mode and invoke remote digital loopback. Again, I measure the median delay; this time, I subtract the local loopback case. Finally, I go all the way to the remote host, using a loopback program. The numbers I got were very consistent, and quite shocking. The two AT&T modems had round trip delays of about 20 ms. The UDS was, I think, about 30 ms. And the Telebit was much higher, though I don't recall the exact number. Note carefully that in a real-world case -- which has two modems in the path -- ping, or character echo, goes through two modem round trips. In other words, there's 40 ms gone, right off the top. I showed that the delay was per ``burst'' of characters by measuring the ping delay (via PPP) for various packet sizes. Plotting the measurements showed that there was a constant offset, with the slope of the line determined almost completely by the serialization delay of injection bits onto the wire at 9600 bps. I'm a bit surprised to hear that Telebit wasn't responsive. When I called them, they agreed that there was a delay problem with the T1600. Since they couldn't or wouldn't tell me when the problem would be fixed, we did the only thing we could -- we returned the modems (they were evaluation units) and didn't buy any. Incidentally, all modems have delays when using MNP, or when in buffer mode. I ran all my tests in direct mode, to eliminate such variables. --Steve Bellovin ------------------------------ End of Suns-at-Home Digest ******************************