Sun-Spots-Request@Rice.edu (William LeFebvre) (09/03/88)
SUN-SPOTS DIGEST Friday, 2 September 1988 Volume 6 : Issue 215
Today's Topics:
Re: NFS write performance
Re: ownership problem
Re: RS-232 problem
a WORM for the 3/160
Non-Sun SCSI disks & Sun4/110
sa -m not working on clients: The obvious solution
Please ignore query about trouble running standalone copy
sunOS 4.0 tapes spelling botch
mounting nfs clients?
40 MIPS Sun-4?
Controlling ftp remote access?
tty as console with logins on 19" monitor?
Connecting to MicroVAX?
Need info on Mercury and Sky Array Processors
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Thu, 1 Sep 88 13:33:38 PDT
From: sxn@sun.com (Stephen X. Nahm)
Subject: Re: NFS write performance
Reference: v6n211
>NFS servers do "write-through-to-disk" on EVERY client write operation.
True, however it's not as though every *byte* is written through
synchronously. The client's biod (block I/O daemon) groups the writes
into blocks, so usually the writes are done in 8K chunks.
The NFS protocol revision draft includes a new procedure, WRITECACHE. To
quote the draft: "Clients can the use WRITECACHE operation to group
consecutive WRITE operations without incurring the overhead of flushing
each chunk of data through to disk on the server."
The NFS protocol revision draft has been circulated among the NFS vendor
community. The revision improves NFS's heterogeneity (there are several
additions that were prompted by the requirements of Macintosh and VMS
implementations of NFS) and fixes other areas in the protocol (such as the
new WRITECACHE procedure). The revision describes version 3 of the NFS
protocol (version 2 is the current (and only) version of NFS). The RPC
versioning mechanism will allow implementors to support *both* version 2
and version 3 of the NFS protocol.
Steve Nahm
Portable ONC/NFS
------------------------------
Date: Thu, 1 Sep 88 13:39:17 EDT
From: jc@athena.lle.rochester.edu (Carolyn Wasikowski)
Subject: Re: ownership problem
Rudolf Baumann <@relay.cs.net:ruba@biophys.uucp> writes:
>I have a silly problem on a 3/260 running SunOS3.4. Everytime when I
>open a window I get the the message:
> /dev/ttyp?: Not owner
>Piping a text through a filter in vi gives me the the funny message:
> Where are you?
I had this same problem when I put "biff y" in my .cshrc. Moving the
command to my .login solved the problem. I believe it has something to do
with the fact that biff changes ownership on your login tty.
- JC
jc@lle.rochester.edu
{seismo|allegra}!rochester!ur-laser!jc
------------------------------
Date: 1 Sep 88 18:26:03 GMT
From: jeff@tc.fluke.com (Jeff Stearns)
Subject: Re: RS-232 problem
Charles Sandel (sandel@mcc.com) writes:
> I am having a problem getting my Sun-3/260 to read the output from a Heath
> "Most Accurate Clock"... The Sun just sees a bunch of nulls...
> The output voltage from the clock seems "reasonable" (around 4 volts -
> anything over 3 is kosher for RS-232).
I installed a Heath clock years ago and use it dozens of times per day.
It's been connected to a Sun-2/170 through a Systech MTI-1600 serial
interface and directly to ttya. Have faith - it can be made to work.
You should first know that recent revisions of the clock EPROMS botched
the clock's UART settings at 9600 baud, so you may wish to avoid this
speed.
More importantly, note that the clock's RS-232 output does NOT conform to
the letter or spirit of the RS-232 specs. The clock's circuitry is
designed around a dirty trick that's sure to entrap anybody who installs
the clock into a well-grounded system.
What's wanted in an RS-232 circuit is a signal that swings between -3V and
+3V at the recipient. The Heathkit clock has an output voltage swing
between 0.3V and 4.8V. By itself, this won't work. This is where the
sleazy trick comes into play.
We want that voltage to go negative, but Heathkit didn't want to invest
the circuitry in a negative voltage supply to drive it. Thus they tied
the clock's +5V supply to pin 7 of the RS232 connector (GND), causing the
entire chassis of the clock to float at -5V. (It's an old trick.)
Now the output voltage measured at pin 2 of the RS-232 connector will
appear to swing between -4.7V and -0.2V, and it works in most cases.
The sleaze overcomes you if you ground the clock or its antenna
connection. You've now established a path from the clock's +5V supply
through pin 7 of your RS232 connector into system ground. This disables
the clock's RS-232 output circuitry and the receiver sees a continuous
stream of NULLS.
The proper solution is to install a true negative voltage supply within
the clock; this can be done with an IC, a diode, and two capacitors. It
shouldn't cost more than $10 total. If you built the clock, this
shouldn't be much of a challenge.
By the way, I have an RPC-based time server that connects this clock to a
network; let me know if you'd like a copy.
Jeff Stearns jeff@tc.fluke.COM
John Fluke Mfg. Co, Inc. (206) 356-5064
PS - Calling all users of the Vitalink transLAN IV Ethernet bridge!
Pen pals wanted - please drop me a note.
------------------------------
Date: Thu, 1 Sep 88 14:32:11 EDT
From: Bennett Todd <bent!bet@mcnc.org>
Subject: a WORM for the 3/160
We use the Delta Microsystems' packaging of the Maxtor 5-1/4" 400M/side
WORM drive. It looks like a cross between a disk and a tape drive; it is
randomnly addressable, but has mandatory blocking, and of course the WORM
semantics. These (write-once semantics) prevent building a filesystem on
the drive; to use a UNIX filesystem on it you must build the filesystem on
disk (with frag size=2K) and dd it onto the WORM, where you can then mount
it read-only. This is really the pits, since the way UNIX accesses files
in a filesystem requires enough seeks and reads that it is about 50x
slower than it should be on the WORM. Delta Microsystems provides a
facility for maintaining a flat directory structure with contiguous files;
it is much better suited to the performance characteristics of the drive.
It uses a cute hack in their device driver, whereby the disk partitions
(which show up in /dev/r?sod[0-9][a-h]) can be mapped via an IOCTL to any
contiguous range of sectors on the disk; a utility is provided which
manages the directory structure and allows you to map partitions onto
files. This is O.K. up to a point, but it is rather cumbersome, and the
resulting interface still requires that I/O be performed in 2K blocked
increments aligned at 2K boundaries, which much software doesn't do. So, I
wrote a library containing laser_open(), laser_close(), laser_read(),
laser_write(), and laser_lseek(). This library works with LASER_FILE
structures, and is conceptually modelled after stdio. It does (tremendous
amounts of) buffering, and conceals the underlying mapping process. Next I
took /lib/libc.a, and used ar to pull out open.o, close.o, read.o,
write.o, and lseek.o. I wrote a little object module abuser (that uses
a.out.h) which upcases the second letter in the entry point name,
producing object modules in which the entry points are named oPen(),
cLose(), rEad(), wRite(), and lSeek(). Since I don't hang out with folks
who use names like that, I am not too worried about name collisions. So,
now I wrote myself a set of little routines which I called open(),
close(), read(), write(), and lseek(). open() checks the name handed to
it, and if it begins with a magic prefix ("/laser/" by default,
overridable via the environment variable LASER_PREFIX) it dispatches to
laser_open() (which calls oPen() internally), otherwise to oPen(). If it
was a laser request, the returned LASER_FILE pointer is stored in a table
subscripted by the file descriptor, and the file descriptor is returned.
The other routines (read(), write(), lseek(), and close()) all check in
this table to see which way to dispatch. Also, the open() routine
registered a cleanup procedure with the on_exit facility. I rebuilt libc.a
with these object modules, and called the result libaser.a, which I
install in /usr/lib. Now all I gotta do is link programs with "-laser" and
voila, the files on the WORM appear to be in a directory called /laser (or
wherever you want them settable via LASER_PREFIX). While it is a sorta
rude hack, it works fine on our (binary-only) installation, it wasn't too
difficult to write and debug, and it delivers performance within a very
small fraction of the theoretical performance of the drives.
-Bennett
bet@orion.mc.duke.edu
+1 919 684 2711 ext 355
------------------------------
Date: Thu, 1 Sep 88 15:30:04 MDT
From: roberts%studguppy@lanl.gov (Doug Roberts @ Los Alamos National Laboratory)
Subject: Non-Sun SCSI disks & Sun4/110
>From the Read Me First sheet of the documenation that came with my Sun
4/110:
SCSI Disk Use
The Small Computer Systems Interface (SCSI) connector on the Sun 4100 CPU
board installed in your 4/110 system may not adhere completely to the SCSI
specification. Pin 26 on the SCSI connector may be grounded. _Do NOT ust
non-Sun SCSI disk drives with any Sun4/110 or any 4100 CPU based system.
Use of a SCSI drive not purchased from Sun may result in the damage or
destruction of the disk drive/s._
Now, did it just strike _me_ this way, or is this really a particularly
sleazy attempt by Sun to prevent users from adding third party disks to
their "open" systems?
--Doug
Douglas Roberts
Los Alamos National Laboratory
(505)667-4569
dzzr@lanl.gov
------------------------------
Date: Thu, 1 Sep 88 11:34:56 PDT
From: Jonathan Eisenhamer <jon@mira.astro.ucla.edu>
Subject: sa -m not working on clients: The obvious solution
Reference: v6n208
In Digest v6n208, I asked:
>Basically all that is needed it the result of /usr/etc/sa -m.
>This works fine on the 3/260 server and 3/160 client, but on all three of
>our 3/50's, it fails with segmentation violation...
The answer is provided by Rich Kaul (kaul@icarus.eng.ohio-state.edu):
>It has to do with sa not using the yp interface to get info from the password
>database....
According to this, however, it should not have worked on the 3/160 as I
stated above. Re-checking, it does not work on the 3/160 unless the
suggested actions are taken.
Jonathan Eisenhamer
------------------------------
Date: Thu, 1 Sep 88 14:48:18 EDT
From: mike@shogun.cc.umich.edu (Michael Nowak)
Subject: Please ignore query about trouble running standalone copy
Please ignore my plea for help. I figured out what I was doing wrong.
Sorry to bother you all.
------------------------------
Date: Thu, 1 Sep 88 14:54:21 EDT
From: cml@diplodocus.cis.ohio-state.edu (Christopher Lott)
Subject: sunOS 4.0 tapes spelling botch
Hi,
Does anyone else have SunOS 4.0 distribution tapes that say:
"....Systems, Inc and The Reagents of the University of Ca...." ?
^
Just thought I'd ask.
I wonder what it feels like to be a reagent <grin>.
cml
-=-
cml@tut.cis.ohio-state.edu Computer Science Department, OSU 614-292-6542
or: ...!{att,pyramid,killer}!osu-cis!cml <standard disclaimers>
------------------------------
Date: 1 Sep 88 10:42:54 GMT
From: uhccux!lee@aloha1.eng.hawaii.edu (Calvin G.Y. Lee)
Subject: mounting nfs clients?
We are having problems mounting a client workstation, a Sun 3/60, to a
server, a MicroVax II. The MicroVax II disk can not be mounted on the Sun
3/60.
The MicroVax II is running ULTRIX 2.0 and portmap, nfsd, biod, and mountd
are running. Also the /etc/exports file is setup.
rpcinfo -p was operated on the MicroVax II and error, "no remote programs
registered," occurred.
>From the Sun 3/60, running Sun OS 3.5, the mount command was tried and
error, "server not responding: RPC: Program not registered," occurred.
Lastly, it may be worthy to note that the Sun 3/60 disk can be monted on
the MicroVax II.
Please e-mail any suggestions to lee@aloha1.eng.hawaii.edu.
Thanks for your help.
Calvin
------------------------------
Date: Thu, 1 Sep 88 17:33:26 PDT
From: Rich Fanning <island!aruba!rich@sun.com>
Subject: 40 MIPS Sun-4?
I came across two interesting articles today, both alluding to a 40 MIPS
SPARC chip. While this is not a complete surprise (plans for an ECL SPARC
have been known), more details are given.
The September 1988 issue of The SunTimes, p. 9, refers to the Sun-4/222,
running a BIT ECL SPARC running at 66.66 MHz (!). Unix Today!, August 22,
1988, p. 47, says the chip will be available for sampling at the end of
'88. Does this mean we'll get an official Sun announcement next spring?
There are also references to 15 and 20 MIPS parts from Fujitsu, Cypress,
and LSI, but the ECL chip really caught my attention.
------------------------------
Date: 31 Aug 88 19:01:52 GMT
From: Jeffrey A. Sullivan <idis!cisunx!jasst3@psuvax1.cs.psu.edu>
Subject: Controlling ftp remote access?
Can someone tell me what files I have to edit so that users other than
root are able to ftpo to my sun386i? As it is, valid users are denied
access, and only the root can log in to ftp.
Jeffrey Sullivan | University of Pittsburgh
jas@cadre.dsl.pittsburgh.edu | Intelligent Systems Studies Program
jasper@PittVMS.BITNET, jasst3@cisunx.UUCP | Graduate Student
[[ Check the manual page for the FTP daemon: ftpd(8). It completely
describes the authentication algorithm. --wnl ]]
------------------------------
Date: Thu 1 Sep 88 11:48:16-PDT
From: Matthew Self <SELF@pluto.arc.nasa.gov>
Subject: tty as console with logins on 19" monitor?
Is it possible to have a tty be the console device while at the same time
being able to log in on the Sun monitor and run suntools, etc? We
purchased a monitor for our 3/280 file server with the intention of using
it as a workstation also, but cannot allow L1-A from that keyboard to
bring our whole system down. We would also like to use an old vt100 as a
console device locked securely in the machine room, where console messages
won't be lost since no one will normally log in from there. It does not
appear to be possible to do this since the /dev/console device is
indirected to /dev/ttya and there is no remaining device to run a getty on
for the monitor. Why isn't there a /dev/ttya *and* a /dev/monitor with
/dev/console indirecting to one or the other? There seems to be a basic
confusion about the meaning of the word "console". Does it mean the 19"
monitor, or does it mean the device to which system messages are logged?
If anyone has made this work, please let me how and I will sumarize the
solutions....
Matthew Self
NASA Ames Research Center
self@pluto.arc.nasa.gov
------------------------------
Date: Thu, 1 Sep 88 12:59:22 MDT
From: Dick Wiley <wiley%unm-la@lanl.gov>
Subject: Connecting to MicroVAX?
The company I work for has a Sun 4/110 and a MicroVAX II. We would like
to set up an Ethernet connection (thick-wire) between them. The MicroVAX
is currently running VMS 4.7 (soon to be 5.0), and we have a DEQNA board
for it. I would be interested in hearing of any problems anyone has
encountered making this kind of connection.
Please respond by mail. I will send a summary if it seems desirable.
Thanks,
Dick Wiley
------------------------------
Date: Thu, 1 Sep 88 16:52:17 MDT
From: colley%sunspot.UUCP@noao.edu (Steve Colley)
Subject: Need info on Mercury and Sky Array Processors
We are in the process of replacing our fleet with a network of Sun 4s.
Several venerable FPS120B array processors have served us faithfully but
will be put in drydock. We are looking at the Sky VORTEX-vpa and the
Mercury MC3200 "application accelerators" as replacements. Any comments,
testimonials, etc. from users of these boards would be appreciated.
Support for the Sun 4 line is pending (it seems) but comments concerning
their use in older tubs would be great. Also, any other products we should
be considering?
Stephen Colley, National Solar Observatory/Sacramento Peak
P.O.Box 62, Sunspot, NM 88349 USA, (505)434-1390 FTS 571-0232
UUCP: {arizona,decvax,ncar}!noao!sunspot!colley
Internet: scolley@noao.edu
------------------------------
End of SUN-Spots Digest
***********************