Date: Sat, 27 Feb 88 18:54:48 EST From: Dwight D. McKay (The Moderator) Reply-To: Suns-at-Home@mckay.UUCP Subject: Suns-at-Home Digest V1 #6 To: Suns-at-Home-List Suns-at-Home Digest Sat, 27 Feb 88 Volume 1 : Issue 6 Today's Topics: /usr/diag/sysdiag on Sun-2's Van Jacobson's TCP fixes and SLIP +--------------------------------------------------------------------+ | Submissions: suns-at-home \ @ea.ecn.purdue.edu | | Requests: suns-at-home-request > -- or -- | | Archives: suns-at-home-archives / ...ihnp4!pur-ee!mckay!... | +--------------------------------------------------------------------+ ---------------------------------------------------------------------- Date: Tue, 23 Feb 88 09:33:06 PST From: pur-ee!coherent.com!celeste (Celeste C. Stokely) Subject: /usr/diag/sysdiag on Sun-2's To: suns-at-home@ea.ecn.purdue.edu >Are the files in the /usr/diag directory used during >boot-time or for periodic maintenance? /usr/diag files, for any Sun architecture, are there for serious hardware debugging. They are intended for use by Sun Field Service personnell. I don't even think that they are documented anywhere (unless it showed up in recent docs). So, you could certainly delete the ones that test things you don't have, like maybe the gp2test or ipctest or color or dcp (The original Sunlink board). Barring really gross hardware problems, you could load them off tape when field service needed them, unless of course they're debugging a bad tape problem. I've only seen them used a couple of times in 3 years, and one of those times, before all the nice tests came on the distribution tape, I think, the field service person had his own tape and loaded them on. ..Celeste Stokely Coherent Thought Inc. UUCP: ...!{ames,sun,uunet}!coherent!celeste Domain: celeste@coherent.com Internet: coherent!celeste@ames.arpa or ...@sun.com or ...@uunet.uu.net VOX: 415-493-8805 SNAIL:3350 W. Bayshore Rd. #205, Palo Alto CA 93404 ------------------------------ Date: Sun, 21 Feb 88 02:39:19 PST From: pur-ee!xerox.com!weiser.pa Subject: Van Jacobson's TCP fixes and SLIP To: suns-at-home@ea.ecn.purdue.edu Ever been annoyed by how careful you have to be using SLIP from home? How if you try to kill an rcp in the middle the modems can still be busy for many minutes afterwards flushing out old packets? How a busy transfer can keep any other transfers over your SLIP line from working? I sure have, and now I have found a solution: Van Jacobson's TCP fixes. Van Jacobson, at lbl, has been putting fixes into 4.3bsd tcp code, trying to break the world speed record. I discovered tonight that his fixes also make very slow links behave much much better. The instructions for getting his code are appended to the end of this mail. I had to add a "I/sys/inet" to the front of the CFLAGS line in his makefile to make it all work on my SunOS 3.5 system, otherwise no problems or changes at all. And what a difference in performance! The figures below are for transfers FROM a Sun-3/60 runing SunOS 3.5 with Jacobson's code TO a Sun-4/260 running 3.2GAMMA without Jacobson's code. (Modem used is a Codex-2260 9600 baud modem, used over regular dialup lines) My straight, not trying to do anything else, rcp performance improved (from 700 bytes/sec to 800 cps). I think is because the old code would pile up more and more mbufs in the queue, until it had to dump some, resulting in pseudo retransmissions after very long xfers. But the real improvement came in the ability to share the line with multiple transfers. The simple test of running an rcp while pinging over the same serial line used to show ping round-trips steadily increasing, up to half a minute or so. With Jacobson's code, the ping RTT's max out at around 4 seconds, and never get higher. (Actually, they go up to 4, then suddently drop to 3, then slowly increase to four by 100ms/sec, then drop, etc. over and over). I could also easily remote login, edit, etc., simultaneous with heavy transfers over the link, which often didn't work before. And now aborted rcp's or ftp's free the serial line almost immediately. Echo's of typing over a busy serial link are better, but still not great: as the ping times show, you might have to wait 4 seconds to see the echo. But 4 seconds is better than forever! -mark ---------mail from van jacobson--------- Return-Path: Received: from lbl-csam.arpa by Xerox.COM ; 09 NOV 87 20:45:07 PST Received: by lbl-csam.arpa (5.58/1.18) id AA11742; Mon, 9 Nov 87 20:43:30 PST Message-Id: <8711100443.AA11742@lbl-csam.arpa> To: end2end-tf@venera.isi.edu, ietf@gateway.mitre.org, shep@ALLSPICE.LCS.MIT.EDU, weiser.pa, loverso@multimax.arpa Cc: karels@okeeffe.berkeley.edu Subject: new beta-test version of 4bsd TCP available Date: Mon, 09 Nov 87 20:43:28 PST From: Van Jacobson A new version of the experimental, 4bsd TCP is available for anonymous ftp from host lbl-rtsg.arpa (128.3.254.68 or 128.3.255.68). Ftp file xtcp.tar.Z, a 50KB compressed tar archive. Uncompress the file and extract the README file from it for more information. This version contains the timer and congestion control algorithms Mike Karels and I talked about at the recent end2end and ietf meetings. We have been running some variation of this tcp at LBL and UCB for the past six months. All the bugs we know about have been fixed and this version has been stable for several weeks (stability of previous versions was measured in days, hours or milliseconds). We have attempted to #ifdef this version so it will configure itself for any stock 4.2 or 4.3bsd system. Unfortunately, there are a number of vendor-supplied systems that are 4.2/3 hybrids (e.g., Sun OS 3.4, Ultrix 2.0). If you get unsatisfied externals when linking a system with this tcp, try adjusting the #if for the missing routine. E.g., you might get an unsatified external for tcp_ctloutput when linking this for Sun 3.4. You might try changing the #if around tcp_ctloutput (in tcp_usrreq.c) from #if BSD>=43 to #if BSD>=43 || SUN>=34 and add -DSUN=34 to the Makefile. I would *not* assume that a system that's not 4.2 is 4.3 and add a -DBSD=43 to the Makefile: I have heard (marketing) people from both Sun and DEC say their systems have the 4.3bsd network code. They lie. Neither Sun 3.x (x<6) nor Ultrix use 4.3bsd network code (although both systems contain random pieces of the 4.3 code). I suggest you find which random pieces you have by cut-and-try. And, if you end up with something that works, please send me a note so I can incorporate your experience into the distribution notes. If you grabbed an earlier version of xtcp, you probably want to replace it with this version. One major and several minor bugs were fixed. The major bug was the retransmit timer wasn't being initialized for a connection initiator's SYN packet. I.e., SYNs wouldn't be retransmitted for the "connect" side. The minor bugs were: fast retransmit code would sometimes not shrink the congestion window; rtt was off by 1 and retransmit would happen 500ms late on an ethernet; an MSS option was sent on some RST packets; the receiver's estimate of the sender's buffer size wasn't being computed correctly; and a rare race on a packet arriving between a "socket" call and a "listen" call was squashed. Good luck. Please let me know about problems. - Van [Van's TCP/IP is also wonderful for use over the ARPAnet. We've been using it successfully at Purdue for about two months now. --ddm] ------------------------------ End of Suns-at-Home Digest ******************************