Sun-Spots-Request@RICE.EDU (William LeFebvre) (12/10/87)
SUN-SPOTS DIGEST Wednesday, 9 December 1987 Volume 5 : Issue 68
Today's Topics:
Re: Modifying buffer allocation
Re: Network Software Bug
Dumping part of the screen
Cheap disk for Sun SCSI
RPCSRC 3.9 is now available
Review of Ciprico Rimfire 3200 disk controller (long)
Driver Wanted for OSI WORM
----------------------------------------------------------------------
Date: Mon, 30 Nov 87 21:55:36 CST
From: stan@shell.UUCP (Stan Hanks)
Subject: Re: Modifying buffer allocation
Jan Wielemaker asks in SunSpots v5n64 if it is possible to modify the
buffer allocation code to take advantage of the fact that a server doing
nothing else but providing file service has a whole bunch of memory laying
around that could be put to good use as Unix disk buffer.
There *ARE* variables in the kernel which determine the number of buffers
that are allocated. By default, they are set to allocate about 10% of
physical memory. If you adb your kernel and change the value of these
variables (called "nbuf" and "bufpages"), you can change that percentage.
(if you require further elucidation on how to adb your kernel, you
shouldn't be doing it anyway 8=))
Unfortunately, there is no way to take good advantage of this knowledge.
I decided to see just how much memory I could allocate to the buffer pool
by doubling these values. I was basicly able to double them once, and
found that after that the system became amazingly unstable. It either
wouldn't boot, or would crash shortly after booting.
It is not amazingly clear what is going on here. And, of course, Sun does
not support these actions. But having twice as many buffers yields better
performance, as one would expect. Anyway, if anyone has any ideas or can
better my efforts, I'd appreciate hearing about it.
Stan Hanks
Shell Development Company, Bellaire Research Center (713) 663-2385
...!{sun,psuvax,soma,rice,ut-sally,ihnp4}!shell!stan stan@rice.{edu,arpa}
I don't hold my employer responsible for what I say; why should you?
------------------------------
Date: Tue, 1 Dec 87 21:12:13 EST
From: Jon Rochlis <jon@athena.mit.edu>
Subject: Re: Network Software Bug
while (1) {
if (read(sock, obuf, BUFSIZ) > 0)
write(1, obuf, strlen(obuf));
else
break;
You're not checking the return value from read (the number of bytes read).
What makes you think you'll always get nicely null terminated strings back
from read? You're probably seeing stack garbage from the initgroups.
-- Jon
------------------------------
Date: Tue, 1 Dec 87 11:57:04 GMT
From: Richard Tobin <richard%aiva.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Subject: Dumping part of the screen
Here's a program to dump a rectangular region of the screen, selected with
the mouse. It writes a rasterfile to its standard output. Click down to
select the top left corner, release to select the bottom right. The
"suggested widths" it prints out are ones that will map each pixel to a
whole number of pixels at 300 pixels/inch.
Richard Tobin, JANET: R.Tobin@uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
[[ Whether or not to include this program was a close call. The program
is ~3200 bytes in length. But I have a sizable backlog, so I'm trying to
make every issue count. The program is in the archives as
"sun-source/dumpregion.c". It can be retrieved via anonymous FTP from the
host "titan.rice.edu" or via the archive server. For more information
about the archive server, send a mail message containing the word "help"
to the address "archive-server@rice.edu". -wnl ]]
------------------------------
Date: Mon, 30 Nov 87 19:05:19 EST
From: berger@datacube.com (Bob Berger)
Subject: Cheap disk for Sun SCSI
We have been investigating low cost SCSI disks for the Sun SCSI bus. We
have pretty much settled on the CDC Wren IV (94171-300) 300 Mb SCSI. This
is a 5 1/4" disk with built in SCSI adapter. Below is a little report
including a mini installation guide for connecting the drive to a Sun.
We have a new CDC Wren IV, which, other than bad documentation, has been
completely satisfactory. It's quiet (relative to the other drives in our
howling Sun 3/160), fast (I suspect the biggest bottleneck is the Sun SCSI
interface and device driver -- of which I hear a new version is in the
works), and cheap (<$2k for us).
This is what I used to make the CDC Wren IV (94171-300) 300 Mb SCSI
winchester disk drive (5 1/4" full height) work:
The OEM manual that came with it was fairly complete on the matter of
jumpers and cabling.
The only really tricky part about the drive is that the OEM manual does
not specify how many cylinders or how many data sectors per track there
are. The marketing glossy claims 1365, but I believe this is wrong. I do
believe it when it says that there are 9 data surfaces.
Since the glossy claims the same bpi density as the wren III (19058), I
expect about the same number of sectors per track as it, about 35 (I used
34 for the Wren III, but I'm not sure that's optimal). Using the Sun
standalone diag utility, I found there are 586764 user-accessible 512-byte
data sectors on the drive (the Wren III reserves 2 cylinders for internal
use), which factors into (9 heads)(36 sectors/track)(1811 cylinders).
Since 1811 is prime, I concluded there are 1811 cylinders, giving 293 Mb,
about right for the drive. So I ended up using this geometry:
1809 cylinders, 2 alternate; 9 heads; 36 sectors/track; interleave 1.
If anybody finds a hole in my logic, or confirms this with CDC (they
haven't returned my call), please let me know.
The rest of this is for our internal use, and for the benefit of
people without a manual.
[[ It is also too big for a digest. It is stored in the archives as
"sun-spots/WrenIV.info". --wnl ]]
David Anderson
!mirror!datacube!dca
dca@eddie.mit.edu
------------------------------
Date: Wed, 2 Dec 87 18:54:07 PST
From: sxn@sun.com (Stephen X. Nahm)
Subject: RPCSRC 3.9 is now available
RPCSRC 3.9 11/30/87
This distribution contains Sun Microsystem's implementation of the
RPC and XDR protocols and is compatible with 4.2BSD and 4.3BSD. Also
included is complete documentation, utilities, RPC service
specification files, and demonstration services in the format used by
the RPC protocol compiler (rpcgen).
If you wish to report bugs found in this release, send mail to:
Portable NFS
Sun Microsystems, Inc
MS 12-33
2550 Garcia Avenue
Mountain View, CA 94043
or send Email to nfsnet@sun.com (the Internet) or sun!nfsnet (Usenet).
Sun will be selling this package on 1/4" cartridge and 1/2" magtape for
a $100 processing fee, however it won't be available until either late
December or next month. An announcement will be posted to comp.newprod
when we're ready to take orders.
[[ Editor's note:
The package is freely redistributable and has been placed in the Sun-Spots
archives for retrieval by all those inclined to do so. It is stored in 15
separate shar files, none over 64K, and totals about 800K. All the files
are in the public FTP directory "sun-source". Here is a list of the file
names and sizes:
58200 rpcsrc.rpc.01 26077 rpcsrc.rpc.09
60519 rpcsrc.rpc.02 59556 rpcsrc.man.10
55959 rpcsrc.rpc.03 63406 rpcsrc.doc.11
54690 rpcsrc.rpc.04 61521 rpcsrc.doc.12
61434 rpcsrc.rpc.05 49991 rpcsrc.doc.13
45917 rpcsrc.rpc.06 35462 rpcsrc.doc.14
54480 rpcsrc.rpc.07 42049 rpcsrc.doc.15
54624 rpcsrc.rpc.08
--wnl ]]
WHAT'S NEW IN THIS RELEASE
The previous release was RPCSRC 3.2. As with all previous releases,
this release is based directly on files from Sun Microsystem's
implementation.
New Documentation
1) New manual pages are provided for the XDR and RPC library
routines.
2) Revised versions are provided of the "RPC Programmer's Manual,"
the "XDR Protocol Specification," and the "RPC Protocol
Specification."
3) Three new manuals are provided: "RPCGEN Programmer's Manual,"
"XDR Technical Notes," and the "NFS Protocol Specification."
New Demonstration Services
4) The demo directory contains two services used as examples in the
"RPCGEN Programmer's Manual": msg and dir.
5) A "sort service" is also provided in RPCL format (.x). This
service is identical to the "toy" service in RPCSRC 3.2, however
it is now built with RPCGEN.
New Functionality
6) rpcgen has been extensively improved. It now provides client
stubs in addition to server stubs. New conventions are used for
naming procedures to make it easier to convert a non-RPC service
into an RPC-based service. The RPC Language (RPCL) has been
changed slightly (particularly with the specification of variable
length arrays). Constants can be defined, and rpcgen now uses
the C Pre-Processor. See the "RPCGEN Programmer's manual" for
details.
7) rpcinfo can now send broadcast calls to services.
Service Definitions
8) Service definition files (in RPCGEN format) are now included
for certain RPC services. THESE SERVICE DEFINITIONS ARE FOR
INFORMATION ONLY. No guarantee is made of their accuracy or
suitability for any particular purpose.
9) The Remote Status (rstat) service is supplied. This service is
used by perfmeter on Sun workstations to display the server's
load average, cpu utilization and other information. This service
is compatible with 4.2BSD and 4.3BSD only. No client is supplied.
(see rpcsvc/rstat.x)
Steve Nahm
for the Portable NFS Team
------------------------------
Date: 28 Nov 87 01:42:32 GMT
From: hedrick@aramis.rutgers.edu (Charles Hedrick)
Subject: Review of Ciprico Rimfire 3200 disk controller (long)
A couple of weeks ago, we installed a Rimfire 3200 on a Sun 3/280 that has
a single Eagle XP disk drive. It previously had a Sun disk controller,
which is the Xylogics 451 with a Sun Multibus/VME converter. Our sole
motivation was to see whether changing to a more modern controller would
give us better disk I/O throughput. The machine in question is used as a
timesharing system by computer science researchers. It was quite clear
that it was I/O bound. We often have as many as 20 users on the system,
however admittedly most of them are reading mail and editing. I am
generally pleased with the result of the experiment, however others
considering changing controllers may find it useful to know what is
involved in doing so.
Ciprico supplies a Sun installation kit, which includes software,
documentation, and ROM's. There are separate kits for the 160/180 and the
260/280. They differ because the 200 series ROM's are somewhat different.
Last time I talked to them, there was no support for the Sun 4 yet (but I
trust it will be coming shortly). Their ROM's are needed if the disk on
which /vmunix is stored is on a Ciprico controller, since then the boot
code has to be able to talk to the new controller. The ROM's were
apparently prepared by Sun under contract to Ciprico. Software includes a
new boot (again, needed because the booting process has to understand
their controller), a device driver that goes into the kernel, and an
online utility for formatting the disk and doing various other tasks. It
is possible to install the device driver even if you don't have Sun
source.
Installation took three attempts, each of which was at least 8 hours. The
holdups were minor things. The first two attempts were halted because we
had gotten the wiring wrong on cables. The new board designed to fit
directly into a Sun (3220?) should help this, since if it is properly
designed, you should be able to use standard Sun cables. At any rate,
unless you have people who like to fiddle with hardware, I'd get the board
from someone who is able to supply a whole subsystem, i.e. all the cables
and other fittings you might need. But even if you do that, the first
time you install a new piece of hardware, you have to assume that things
are going to go wrong. So allow plenty of time, and assume it is going to
take a couple of attempts.
Once the hardware was working, things were fairly smooth. Our most
serious problem was caused by the fact that we reversed the order of two
steps in their checklist. (We wrote the disk label, and then formatted
the drive. Of course formatting overwrites the label.) However we were
also delayed somewhat by the fact that the formatting utility didn't work.
Fortunately, the folks at Ciprico were around, and they UUCP'ed us a new
version. Presumably this means that any future customers will get one
that works. Note that you have to reformat any disk to be used with this
controller. Their improvements depend upon a slightly different format.
There is no standalone formatter. So to format a disk, you need a system
with at least two disk drives, one of which you boot on and run software
from, and the other which you are formatting. In our case this meant
moving the disk to another system, since the system we were using had only
one disk. Formatting is very fast. Formatting and 5 passes of
verification take about an hour. Once the drive is formatted, things use
normal Unix utilities: newfs, restore the file system, write boot blocks,
etc. Installing a new release of SunOS could get interesting though,
since the minifs that is normally used to bootstrap the setup program
presumably doesn't support the Ciprico controller. And stand/copy, which
one uses to get the minifs onto the disk, isn't going to support it
either. I guess we're going to have to use a machine with a Xylogics
controller to help us bootstrap into the new release, or produce versions
of stand/copy and the minifs kernel that include support for this
controller.
The online utility, rfutil, is sort of cute. It is used to create or
change the label, including partitions, to format and verify, and to look
at and change various other parameters in the controller. You can see the
hit ratio of their onboard disk cache, as well as various other
statistics. You can also set policy parameters controlling such things as
whether the cache is used for reading and writing, whether readahead is
done and how far, etc. These can be set separately for raw I/O, normal
I/O in units of 4KB, and other normal I/O. The defaults are reasonable as
far as caching policy, but they disable the board's ability to reorder
commands. Most Unix device drivers use a standard kernel subroutine to
put commands into an optimal order. (The idea is that if several programs
are reading from the disk at different places, you want to do the commands
in an order that will minimize head motion.) The Ciprico device driver
does *not* do this reordering, because the controller itself can do it. I
agree that doing it in the controller is better. However by default they
disable reordering in the controller. I asked Ciprico about this, and
they said they were concerned about database software, which might depend
upon updates being done in a specified order. I understand this concern,
but since all other Unix device drivers reorder, it seems to me that no
database software should be based on such assumptions. Thus we recommend
using cache control values of 331, 131, and 31 respectively for I/O groups
1, 2, and 3. These are set by the "d" command in rfutil. We have a shell
script that allows us to say "rfset 331 131 31" in rc.local. Ciprico says
that you have to change the device driver to change the default values,
which requires source. Of course source is cheap from them, so that's no
big deal. Indeed I think I'd recommend that everyone get their source
package.
I judge the results based on the output from vmstat. I'd normally use
iostat also, but their device driver doesn't maintain all the data that
iostat needs, so it ignores Rimfire disks. I think I see why they didn't
do it. Response time is hard to measure when half of the device driver
functionality has been moved into the controller. We normally see a
maximum of about 35-40 transfers per second. This holds across all of our
Sun's, including 3/180's, 3/280's, and 4/280's, and applies to Eagles and
Eagle XP's. (This is the number listed in vmstat about 2/3 of the way
over, under the name of the disk drive.) After we first brought the
system up, we had a flurry of I/O, as it got lots of backed-up news and
mail, and because we make it a practice to do a full dump immediately
after doing a full restore (for reasons described in the man page). We
saw I/O rates as high as 120/sec. This was a bit abnormal, but 80 to 100
was common. During this period, rfutil showed a cache hit ratio of around
80%. This turns out to have been unusually favorable. The good numbers
seem to have resulted mostly from the dump, since dump does lots of fast
sequential reading, and the cache helps that the most. During normal
operation we see I/O rates peak at 60 to 80 with cache hit ratios of 30 to
40%. My overall evaluation is that for normal usage, effective bandwidth
has about doubled. However during certain kinds of usage (lots of
swapping, backups, etc) we see higher numbers. Of course other things
show less improvement. E.g. a single "find" speeds up by at most a
factor of 1.4. (This one is hard to be sure about because I don't have
any directly comparable configuration.)
A few oddities remain. It's not at all clear that any of these are
Ciprico's fault. Indeed I would normally not have posted this review
until after they are all resolved, but I don't know how long that is going
to take:
- we are seeing a number of non-ECC data errors. This presumably
is a header read problem. They are recoverable, but it
is still unusual to see this many errors. We suspect that
it is due to a small number of bad spots that need to be
mapped out (which rfutil can do). We haven't taken care
of it because their device driver doesn't normally print
soft errors, so we don't know where the spots are. They
told us what bits to flip in the source to get the error
messages on the console, but we have been spending our time
pursuing more serious problems and haven't yet looked into this.
- we get a drive fault when the CPU is powered on with the disk
already up. Powering the disk down and up clears it.
We think this is problem in the drive or terminator,
and not the controller, but we didn't get it before.
- as I mentioned in a previous message to Sun-Spots, shortly
after changing to this controller, we started to get system
crashes whenever a certain user runs Lisp. I have now looked
at those dumps more carefully, and I don't see any way it
could be due to the disk controller. The page tables that
are being corrupted have never been swapped or otherwise
touched by the disk. I am now treating this as a kernel bug.
Indeed it is possible that I have a fix, though we won't
know until about a week has gone by without a crash.
In general, I am pleased with the controller. The performance improvement
has been noticable. Ciprico has been very helpful with any questions or
problems we have had. They have been one of the better vendors I have
dealt with. However this message points out that using a non-Sun
controller is not something you want to do if you treat your system as an
off the shelf black box, and expect Sun to deal with all problems. (As a
compromise, I believe Ciprico does a lot of their business with groups
that put their controller together with a disk to form a complete disk
subsystem. These vendors then install and support the complete
subsystem.)
------------------------------
Date: Wed, 2 Dec 87 08:27:56 est
From: Edward Morgan <ehm@space.mit.edu>
Subject: Driver Wanted for OSI WORM
I have an OSI optical disk drive (LM1200). I am looking for anyone who has
written a SCSI driver for a Sun-3 for such a beast. Any leads, tips,
pointers, or rumors would be greatly appreciated.
Ed Morgan
ehm@space.mit.edu
------------------------------
End of SUN-Spots Digest
***********************