Date: Mon, 12 Oct 92 12:42:27 EST From: Dwight D. McKay (The Moderator) Reply-To: Suns-at-Home@orchestra.ecn.purdue.edu Subject: Suns-at-Home Digest V5 #38 To: Suns-at-Home-List Suns-at-Home Digest Mon, 12 Oct 92 Volume 5 : Issue 38 Today's Topics: Fujitsu disk drive problem NFS via serial lines (Suns-at-Home Digest V5 #37) (6 msgs) +--------------------------------------------------------------------+ | Submissions: suns-at-home \ @orchestra.ecn.purdue.edu | | Requests: suns-at-home-request > -- or -- | | Archives: suns-at-home-archives / ...rutgers!pur-ee!... | +--------------------------------------------------------------------+ ---------------------------------------------------------------------- Date: Fri, 9 Oct 92 18:26:33 EST From: malb@boojum.ee.uts.edu.au (malcolm butler) Subject: Fujitsu disk drive problem To: suns-at-home@orchestra.ecn.purdue.edu (Suns-at-home List) Greetings, Firstly, thanks to all those who responded to my post about sun 3/50 memory expansion. I inquired locally about the availability of memory boards and found that (a) they were not very available and (b) they were rather on the expensive side. Your mileage may vary (especially in other parts of the world). So I decided not to get a 3/50, I got a 3/60 instead. I'm now having problems getting it to talk to my hard disk. The disk is a Fujitsu M2246SA which I already had, and I know it works. So do the computer and the SCSI cable. The disk problems manifest in several ways. Firstly, it doesn't like being daisy-chained with other SCSI disk drives. It upsets all the other drives in the chain to a greater or lesser extent, depending on where it is in the chain. It will work ok with just a tape drive, though. The second (and more major) problem is this: it is possible to copy a miniroot onto it, and boot the miniroot, but it then falls over during the boot sequence (when it is almost complete) with the device driver reporting: sd0: target ready test failed and the boot is aborted. If I boot the miniroot directly from the tape, it finds the drive during the boot sequence, but then when I run 'format' it fails to find it and tells me there is no disk drive present. I tested the drive on a sun4 here at uni., and it worked just fine, except that format(8) did not work properly: it wouldn't format the disk, but it could write a label and partition it. I then created filesystems and mounted it, and it subsequently operated with no problems whatsoever. Take it back to the 3/60, and the same problems re-occur. I spoke to Fujitsu about it and they told me that since it wasn't a "Sun approved" disk drive (i.e. approved by Sun) there was no guarantee that it would work. They did say, though, that there is considerable difference between the SCSI interface on the sun3 & sun4 and that some drives will work on one but not the other. The drive is "unapproved" for both. Any light anyone can shed before I run out and spend more money will be appreciated (and anyone who wants a 150M SCSI drive, make an offer ... ). Thanking you, Malcolm Butler -- Switched Networks Research Centre, malb@ee.uts.edu.au Uni. of Technology, Sydney, Australia +61 2 330 2344 ------------------------------ Date: 05 Oct 92 13:22:10 PDT (Mon) From: pratt@cs.stanford.edu Subject: NFS via serial lines To: Suns-at-Home@ecn.purdue.edu In Suns-at-Home Digest V5 #37, brook@trillium.botany.utexas.edu (Brook Milligan) writes: Has anyone had experience running NFS over serial lines via something like SLIP? Is this impossibly slow? If not, what hardware do you recommend? I'm running at 56Kbd over Pacific Bell's Advanced Digital Network (ADN) service, which they've been offering out here in California for about four years now to both business and residential customers. I've had 9 filesystems from 4 remote machines (total of 3 gigabytes) mounted on my home machine for the past three years. I occasionally edit files remotely, but since a biggish (100Kbyte) file takes half a minute to read (the first time) or write (every time), I tend only to work on small files in that mode, preferring to transfer anything big to my machine first. What you really notice is how much chit-chat Unix requires just for an "ls -l". Lists about 7 files a second at 56Kbd. This is only about 25% faster than if you did the ls -l directly on the remote machine and got the listing back through a 2400 baud connection. On the other hand if you do the ls -l again it goes much faster due to the inodes having been buffered locally. So if you plan to use NFS a lot at home, don't skimp on buffers (read: DRAM). At the slower speeds on voice grade lines you may find packet turnaround causing a nonlinear slowdown of both UDP and TCP on IP (hence NFS), depending on your modem etc. The old Trailblazers, which I used five years ago before ADN came out, were notorious in that regard for NFS, though wonderful for almost all other applications. Data compression and improved protocols should have greatly improved the usability of voice lines today; unfortunately I don't have any experience with them, ADN having spoiled me for anything slower. Vaughan Pratt ------------------------------ Date: Tue, 6 Oct 92 8:02:10 GMT From: David Herron Subject: NFS via serial lines To: Suns-at-Home@ecn.purdue.edu > Has anyone had experience running NFS over serial lines via something > like SLIP? Yes. A little bit. Ages ago in the first release of Ultrix which had SLIP (it was an unsupported driver at that point) I was playing around with it. I had a line set up between two uVaxII's (ages ago) at 9600 baud and no flow control. Most things worked fine through it but the NFS mount I tried behaved VERY poorly. A few months ago we set up a 1/4 T1 line between our two offices (I work at TWG.COM) and one of the first things I played with was the automounter to see if it would mount partitions from our east coast office. It took a few seconds, but mounted alright. I could cd into their CD-ROM drive. (BTW, my system was a Sun 386i and was mounting from a Sun 4/3x0 running SunOS 4.1.x). I could get directory listings just fine, but copying files did not work. The `cp' command just sat there doing nothing, and after boredom set in I ^C'd it and saw only 4kbytes had been copied. My take on both these experiences is that you need to set the rsize and wsize of the mount down to SMALL values. The size will depend on the link speed and how reliable (noise or flow control) it is. I have *not* attempted to tune an NFS mount over a `slow' line as it is not something I need to do. So take this advice with a block of salt, and try it out yourself! David Herron ------------------------------ Date: Mon, 05 Oct 92 14:08:53 EDT From: smb@ulysses.att.com Subject: NFS via serial lines (Suns-at-Home Digest V5 #37) To: Suns-at-Home@ecn.purdue.edu It works, but barely. I mount my home directory at work via a PPP link running at 14.4K, mostly so I can run xcalentool. For most things, it's better to rlogin over the line. (I could have run xcalentool using a remote X server; that's a cure that's worse than the disease, in this case. For xrn, it's the method of choice.) I strongly suggest using PPP rather than SLIP, because of the CRC checksum. Remember that Sun has the UDP checksum off by default, and that it's not that strong a check in any event. --Steve Bellovin ------------------------------ Date: Mon, 5 Oct 92 14:04:26 -0400 From: Bob Sutterfield Subject: Suns-at-Home Digest V5 #37 To: Suns-at-Home@orchestra.ecn.purdue.edu Suns-at-Home Digest Mon, 5 Oct 92 Volume 5 : Issue 37 Date: Mon, 28 Sep 92 11:49:48 -0500 From: brook@trillium.botany.utexas.edu (Brook Milligan) Subject: NFS via serial lines To: suns-at-home@orchestra.ecn.purdue.edu Has anyone had experience running NFS over serial lines via something like SLIP? Is this impossibly slow? If not, what hardware do you recommend? I would like to be able to access a large set of files from a remote location via serial lines, perhaps through the campus terminal server. Am I dreaming? Yes, it's painfully slow, but it works. Install the fastest modems you can get. Today that means V.32bis/V.42/V.42bis with a 38400 DTE. To use NFS over dialup links, increase the timeo timeout parameter in /etc/fstab to as much as 750 (i.e. 75 seconds) to accommodate network delays such as establishing modem connections. You should also set rsize=512 and wsize=512 (or perhaps even a smaller value like 256) to reduce the amount of fragmentation and UDP congestion, and set actimeo=120 to reduce the amount of NFS overhead traffic that crosses the link. Since writes are even more painful than reads, you may want to mount remote filesystems read-only. To help guard against file corruption, you should enable UDP checksum calculations on both the NFS client and the NFS server. On a Sun, do this by saying # echo "udp_cksum/W 1" | adb -k -w /vmunix /dev/mem # echo "udp_cksum?W 1" | adb -k -w /vmunix /dev/mem Packets with bad checksums are discarded by the receiver, and the sender will eventually retransmit the packets that were damaged in transit. Rather than NFS, I prefer to use other means (like rdist) to support apparent remote file access. Some folks say that AFS provides useful performance across SLIP and PPP links, but I haven't had the opportunity to try it. ------------------------------ Date: Mon, 5 Oct 92 17:01:44 EDT From: Arun Welch Subject: Suns-at-Home Digest V5 #37 To: Suns-at-Home@ecn.purdue.edu > > Date: Mon, 28 Sep 92 11:49:48 -0500 > From: brook@trillium.botany.utexas.edu (Brook Milligan) > Subject: NFS via serial lines > To: suns-at-home@orchestra.ecn.purdue.edu > > Has anyone had experience running NFS over serial lines via something > like SLIP? I've done it over PPP. It ain't pretty, but it works. >Is this impossibly slow? > Depends on your definition of "slow" :-). I went back to ftp-ing the files over to the local machine, it's much faster. Ongoing file i/o over a serial line isn't ready yet, IMHO. Then again, I remember the days when a 1200bd modem was considered blindingly fast :-). >If not, what hardware do you recommend? Get the fastest modem you can. Note that you're still going to be limited by the speed of the serial port on the machine itself. ...arun ---------------------------------------------------------------------------- Arun Welch Lisp Hacker, Anzus Consulting welch@anzus.com ------------------------------ Date: Mon, 05 Oct 92 20:12:37 UTC From: unixsys@ssg.com (Rick Emerson) Subject: Suns-at-Home Digest V5 #37 To: delphys@CC.McGill.CA > Date: Mon, 28 Sep 92 11:57:44 -0400 > From: David Holmes > Subject: Sun3/60 (os3.5) and SERIAL > To: Suns-at-Home@orchestra.ecn.purdue.edu > > What magic is required for getting a 3/60 at sunos3.5 to use > high speed modems (i.e. > 9600) ? This seems to be a flow > control problem (as Hal Stern's serial.ps suggests). I highly recommend using Taylor uucp which allows writing the appropriate chat scripts and Device files. Using a 386i and SunOS 4.0.1, I was unable to to talk with a US Robotics modem until I went to the Taylor package. The port comprehends up through 19.2 KB but the rest of the system software was wedged at 2400. Also, make sure you have something like: 1542 crw-rw-rw- 1 uucp wheel 12, 128 Sep 29 23:45 /dev/cua0 Now, if someone can only help me with pcomm V2.0... Rick | Richard B. Emerson | Replies may be sent to: | | System Support Group | unixsys@ssg.com -or- rick@ssg.com | | 940 Delaware Avenue |-------------------------------------------------+ | Lansdale, PA 19446 USA | "If I knew what I was doing, | | Voice: 215.855.1607 | I wouldn't do it." - Me | ------------------------------ End of Suns-at-Home Digest ******************************