Sun-Spots Digest, v6n46
William LeFebvre
Sun-Spots-Request at RICE.EDU
Thu Apr 7 14:03:32 AEST 1988
SUN-SPOTS DIGEST Wednesday, 6 April 1988 Volume 6 : Issue 46
Today's Topics:
Re: Data Representation Problems and NFS
Sun 4 Survey RESULTS
How much swap space is left?
Sun 4 status?
Problems with 'mailtool'/'textedit'
Info request for addon disks / controllers
installing boot blocks with dd won't work any more?
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are stored on "titan.rice.edu". For volume X, issue Y,
"get sun-spots/vXnY". They are also accessible through the archive
server: mail the word "help" to "archive-server at rice.edu".
----------------------------------------------------------------------
Date: Fri, 25 Mar 88 08:52:16 EST
From: Nathaniel Mishkin <apollo!mishkin at eddie.mit.edu>
Subject: Re: Data Representation Problems and NFS
Andy Halis writes:
We have a set of applications that save data to files in "binary"
form....We wish to share these files in a heterogeneous environment via
NFS...
This is a fairly interesting problem that I think all we creators and
users of generic distributed file systems (GDFS) and lovers of ASCII
(text) files have been blissfully ignoring for too long. Your message
just touches the tip of the iceberg. What about reading some mongo CICS
database on an IBM mainframe. Access it via a GDFS? Not very likely,
unless you want to implement some large piece of the DBMS on your
workstation.
Unless we want "fscanf" on text files to be the sole way of accessing data
I think we really have to start thinking about distributed data in a new
way. The solution is clearly to use RPC. (I might have some opinions
about how well various RPC systems address this problem, but I won't bring
*that* up :-) Data must be passed around in a structured way, and in
general, only the machine on which the data lives can be allowed to
interpret it at the raw byte stream level.
Think of it this way: Unix "open", "close", "read" and "write" (or the
"read a page", "write a page" operations of GDFSs) are dead. Sure they
work sort of OK for reading some source file on your friend's machine, but
in general they're just too low-level of operations to be passing between
machines in a heterogeneous network. Unfortunately, we're all very
comfortable with those operations. The trick for RPC systems in the
future is going to be making it as easy to design and implement (in an
RPC-like way) operations like "my_open", "my_get_next_record",
"my_write_next_record" as it is for people today to use stdio.
-- Nat Mishkin
Apollo Computer Inc.
...!decvax!apollo!mishkin
[[ Object-oriented programming: treat the database as an object and
"send" messages to it to extract the information you want. Only the
object (and thus only the machine/s that "houses" that object) knows how
to access it. --wnl ]]
------------------------------
Date: 25 Mar 88 19:51:52 GMT
From: amdcad!cdr at ames.arc.nasa.gov (Carl Rigney)
Subject: Sun 4 Survey RESULTS
Here's the summary of the replies to my question regarding the Sun 4's
multi-user capacity. Most of the responses were requests for information,
it appears many people have either just gotten Sun 4's or are thinking
about it.
Some minor formatting has been done, and extraneous comments removed, but
otherwise these reports are verbatim. If anyone wants to contact one of
the people listed for further information, send me your name and I'll
forward it.
I'd like to thank the following people:
Graham Ashby geovision!graham at cognos.uucp
Matt Crawford matt at oddjob.uchicago.edu
Glen Dudek sun!harvard.harvard.edu!ksr!dudek
Charles Hedrick hedrick at aramis.rutgers.edu
Kevin Maciunas sun!uunet.UU.NET!munnari!cs.flinders.oz.au!kevin
David Trueman sun!uunet.UU.NET!dalcs!david
Mark ames!Xerox.COM!weiser.pa
________________________________________
We don't have experience with Sun-4's running lots of real users, but I do
have experience with them running lots of pretend users, and they break
down at high loads. I ran the following test:
Create N processes which simply sleep for K milliseconds, wake-up, then go
back to sleep. See for what values of K and N the system dies. (One does
sub-second sleeps with select.)
With N=15, and K=100 on a Sun-4, all is fine. At N=16, things look a
little bad. By N=18 or 19, no work can get done and you are lucky if you
can get the keyboard back to kill of your 18 processes. So 16 is a magic
number. On a Sun-3/260, its 8. These happen to correspond to the number
of contexts in the Sun MMU.
The same test on a Vax/785 shows no such sharp knee, even through N > 30.
________________________________________
We have about 8 to 16 users at a time logged in to this Sun 3/280S-8 and
doing program development, scientific number crunching, macsyma and text
processing. It also runs usenet news and rn, with six full links and
several partials. We also have a sun-4 but it is reserved for a smaller
number of users doing number crunching.
________________________________________
We run 2.11 news and an nntp server on a Sun-4 with no problems. All our
users run 'rn' from Sun-3's, so I don't know how well 'rn' works on the
Sun-4. I have run 20+ users on a Sun-3 at Harvard, but not on a Sun-4, so
I can't speak to that. Running 20+ users on a Sun-3 was about like you
would expect running that many people on a machine roughly twice the speed
of a VAX-11/780. Not bad at all. But not like the Sun-3 on my desk,
either :-).
________________________________________
We are using our Sun4 in a multi-user environment with typically around 6
users actively using it. It does seem to be as fast as one might expect
from the benchmarks (6-8 X a VAX 780). It is severely I/O limited if you
have just one Xylogics controller. We have had nasty intermittent
problems causing system crashes every 6-12 hours, but I *think* that is
cleared up now (cause not explicitly known). The Sun hardware service
people [here] were very attentive about this problem.
We just replaced a DEC-20 with a 3/280 and 2 4/280's. Most of the users
are split between the 3/280 and one 4/280. We have around 25 users on
each. The 4 has no performance problems: load is quite light. The 3 has
problems, but probably because it has only 8 MB of memory (the 4 has
32MB). We consider the 4/280 to be quite a reasonable multiuser system.
Our configuration is 32MB, 2 Super-eagles (on one XY451 controller), a
6250 tape, and 2 Ethernet interfaces. All users access it from a terminal
server over the network.
We haven't used our sun4 much for development, but we were trying to use
it as a news server. We had problems with uucp -- large amounts of data
(news :-) would cause uucp to blow up, dropping the transmission in the
middle and locking the port. This was with sun OS 3.2gamma (we haven't
tried with the real 3.2 yet).
________________________________________
We use Sun-4's time-shared here (and a 3/280 for that matter) and have
done for a year (the 3's...). It all works just fine! We have all our
undergrads on two 4's and a 3, all using terminal servers to access the
machines. We have about 40 users on each machine. We run news and rn on
the '3, haven't tried to port it onto the '4 yet.
________________________________________
--Carl Rigney
USENET: {ames decwrl gatech ihnp4 pyramid sun ucbvax}!amdcad!cdr
cdr at amdcad.AMD.COM
USMAIL: MS 167; 901 Thompson Place; Sunnyvale, CA 94303
PHONE: 408-749-2453
These are not the official views of Advanced Micro Devices, Inc.
------------------------------
Date: Fri, 25 Mar 88 11:31:51 MST
From: jpm%green at lanl.gov (Pat McGee)
Subject: How much swap space is left?
I need to find out how much swap space is left at a given time. I'm
trying to run lots of windows, and some large programs, and would like to
know before I start how many windows I need to close to make things run.
I've taken two approaches so far, neither of which work well.
(1) Add up all the numbers under "SIZ" in ps -agux, and subtract that from
16 meg. The sizes reported by "ps" apparently count shared text pages for
each process, thus double, triple, etc. counting them.
(2) Run a program than calls "sbrk(2)" repeatedly. This gives what I
think is an approximation to the correct answer, however, it actually uses
up the swap space for a short time, so I can't start anything else at the
same time. (Aside: the answer I get always is an integral number of
megabytes plus .97290 megabytes. For some reason, the fractional part
doesn't change. This may be an artifact of the way I call "sbrk".)
Thanks for any help.
Pat McGee, jpm at lanl.gov, MS B272, Los Alamos Natl. Lab., Los Alamos, NM 87545
(505) 667-4196 (FTS 843-4196) (if no answer, message at -7356)
[[ "/etc/pstat -s". Read the manual page pstat(8). Then try to figure
out what all the information that pstat gives you really means!
Seriously, the "max process allocable" figure that pstat displays is, in
my experience, a very reliable measure. It may be a tad optimistic, but
it always seems very close. --wnl ]]
------------------------------
Date: Thu, 24 Mar 88 23:31:11 est
From: byers at utkcs2.cs.utk.edu (Ralph Byers)
Subject: Sun 4 status?
What is the status of the SUN 4? I have heard the following rumors. Do
you know anything about them?
1) The ports on the SUN 4 do not conform to specification. They will
not drive a printer.
2) Sun has not released an operating system for the SUN 4. The SUN 3
operating system is not fully operational on a Sun 4. (A Sun 4
operating system is scheduled to be available next June.)
[[ As I undestand it, SunOS version 4 runs on a Sun 4, but it is still in
beta-test. --wnl ]]
3) A Sun 4 can not be a diskless client of a SUN 3 server, but a SUN 3
can be a diskless client of a Sun 4 server.
Does any one have experience with SUN 4? How reliable is the hardware
and software?
[[ Another message in this digest is a summary of others' experiences with
the Sun 4. --wnl ]]
R.B.
------------------------------
Date: Fri, 25 Mar 88 10:07:05 EST
From: Nathan H. Hillery <nhh at cs.duke.edu>
Subject: Problems with 'mailtool'/'textedit'
I have grown quite accustomed to the 'Suntools' interface and have
customized the environment to help me work more effectively (Think I've
read the sales brochures?:-). One of the most useful things I've done is
enable 'Initial_selection_selected' (within the Menu category of
'defaultsedit'). This allows me to cut-and-paste within/between windows
with quick mouse-key clicks instead of waiting for menus to appear. It
makes working in multiple windows a fluid operation.
I also like many of the features of 'mailtool'.
Unfortunately, 'mailtool' is based on 'textedit' and, try as I might, I
can't modify what the menus look like or establish a default selection.
I really want to be able to 'put' text into a 'mailtool' window with a
single key click (I mean a single click-release, not
click-wait_for_menu_to_appear- pull_down_to_selection-release). I have
spent a fair amount of time looking for a way to modify 'textedit' menu
behavior, but have been unsuccessful. At this point I would accept any
help (even if it makes me look stupid:-).
I also have a couple of comments about my experiences with
'mailtool'/'textedit' vs. 'shelltool'. First, I have been able to modify
the behavior of menus associated with 'shelltool's. I also have defined
sub-menus to my liking. I wouldn't mind being able to change the menus
that appear ~within~ windows (i.e. in 'shelltool', the three line menu;
"Stuff\nEnable Page Mode\nPut, then Get"), but since the initial selection
is the one I use 99% of the time, I can live without that capability.
With 'textedit', I see very little programmability. Also, 'mailtool'
appears not to allow one to cut-and-paste within a window (say the
"respond" window), a serious shortcoming from my point-of-view.
Unfortunately, 'textedit' has certain features that I would like to have
(scroll bars, in particular). My impression is that 'shelltool' preceded
'textedit' in development. If that is true, and 'textedit' lacks the
programmability I think it does, then Sun software development is going in
the wrong direction (to please my tastes, anyway).
Nate.
Nathan H. Hillery PHONE: (919) 684-5721
Dept. of Computer Science CSNET: nhh at duke
Duke University UUCP: decvax!duke!nhh
Durham NC 27706-2591 USA ARPA: nhh at cs.duke.edu
[[ Shelltool does predate mailtool and textedit: it was one of the first
tools to appear in suntools, back with SunOS version 2 as I recall.
Technically, it has been subsumed by commandtool. Commandtool has the
same text interface as textedit and mailtool. There are ways to do easy
cutting and pasting in one of these new-style text subwindows by using the
left function keys. These should be documented in one of the beginner's
guides, like the one for SunView (these aren't part of the standard
manual set---they're separately bound softback manuals). Although I don't
necessarily like the editing interface (it isn't programmable like emacs
is), I do like the fact that Sun is trying to standardize it across all
tools. --wnl ]]
------------------------------
Date: Fri, 25 Mar 88 16:02:27 GMT
From: psykes at scotland.bbn.com
Subject: Info request for addon disks / controllers
I'm wanting to add more disk space to a 3/280 ( soon to be upgraded to a
4/280 though) I'd like to know what experiences people have had with
different third party controllers and disks. ie:
1) Is it sensible/practical to use any other controller
than the Xylogics 451 that Sun use? I haven't got access to
sources so will I have to patch ?( Bad experience years ago
on a PDP makes me wary of "compatible controllers")
2) I'm looking at the Fujitsui 1 Gbyte disk, any known problems?
3) Does diag really work on any SMD disk, or just those that Sun use?
Thanks in advance
Pete Sykes BBN Laboratories Scotland, UK
psykes at scotland.bbn.com
------------------------------
Date: Thu, 24 Mar 88 19:30:54 EST
From: Rayan Zachariassen <rayan at ai.toronto.edu>
Subject: installing boot blocks with dd won't work any more?
I was reading through the release notes for Sys4-3.2, and buried in a
small errata & addenda section is a note that essentially says: The boot
block won't know about the filesystem any more, but will only know about
disk blocks. Therefore if one moves /boot or installs a new one, one must
do an installboot *again* in order to be able to boot (the boot block code
loads /boot). I surmise from this that installboot is no longer a shell
script, but a program that patches the boot block code before it installs
it. The reason given for doing this is to "save space in the boot block",
by not including the filesystem-cognisant code.
My reaction to this was disbelief. This is an *extremely* important
change, buried in a 4-line paragraph people won't pay attention to, and
with a very lame excuse given for the change. If saving space was the
reason, and I was in a position to do so, I'd have vetoed this change.
Some of the effects that come to mind are:
- one can no longer use dd or any other simple copy program to install boot
blocks (right now, I think even 'cat' will work).
- as a consequence, one cannot just copy a boot block from an old backup root
partition to the real root, or from a remote machine (over the net) to
the raw disk.
- one becomes dependent on yet another program (installboot) for critical
maintenance.
- it is not clear if the patched info in the boot block depends on the
disk geometry or not; if it does, one can't copy root partitions between
different kinds of disks. It would make more sense if it was geometry-
independent, for otherwise how would the miniroot be portable (unless
if the boot block in it knows about the filesystem).
I can think of ulterior motives for this change, but would prefer not to
believe that is the case.
This change is an obstacle in the way of crash/disaster-recovery,
bootstrapping (without the help of a miniroot), and possibly the ability
to use 3rd-party disks/controllers. I wish Sun would explain themselves
better. Sysadmins I've pointed this out to here all had the same reaction
as I: their jaw dropped... (a pavlovian response of sorts ;-).
rayan
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list