Sun-Spots-Request@RICE.EDU (Vicky Riffle) (08/11/87)
SUN-SPOTS DIGEST Monday, 10 August 1987 Volume 5 : Issue 30
Today's Topics:
Administrivia
Cartridge tape dump parameters
Re: Why do our Sun 3/160 backups take 3+ hours?
Stream using the block device.
Re: Power supply in Sun-3/160 shuts down without warning
Use of vadvise(VA_ANOM) within Lisp
multiple-machine executables
Problems with yellow pages in SunOS 3.2
SKY floating point board on 2/50?
MTI board on a SUN3?
OLCI coating on high-res monochrome monitor?
slow windows?
info on UNIX TOPS?
Statistics packages for Suns?
Ingres and Suntools?
----------------------------------------------------------------------
Date: 10 Aug 87 15:20:30 CDT
From: phil@Rice.edu (William LeFebvre)
Subject: Administrivia
About a week ago, Vicky injured her right hand to the point where she
cannot easily type. She will be recovering for about three weeks, and has
asked me to step in temporarily as moderator of Sun-Spots in the interim.
I have received several requests from people asking how they can obtain
material from the archives if they do not have direct access to the
ARPANet. We currently have no provision for automatic retrieval (such as
an archive server would provide) except for the anonymous FTP method.
Other than filling requests by hand (which does not sound like a good idea
to me), we have no mechanism for getting source and old digests to
non-Inter/ARPANet sites. It is possible that we could run an archive
server such as the ones used for mod.sources or the mod.recipes archives.
I will check with the powers that be and try to track down source. This
may be the most reasonable course of action.
Finally, please everyone note that the address for submisions is
"sun-spots@Rice.edu". The address "sun-spots-request@Rice.edu" is to be
used solely for administrative requests (additions, deletions, etc.). Any
submissions that get sent to the request address (and there have been a
few) will be heartlessly discarded.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
------------------------------
Date: 28 Jul 87 17:42:27 GMT
From: mkhaw@teknowledge-vaxc.arpa (Michael Khaw)
Subject: Cartridge tape dump parameters
Thanks to everyone who responded to my question about dump parameters for
use with cartridge tapes. Our Sun hardware support engineer recommended
the following parameters for 450 ft. cartridge tape:
/etc/dump 0ucfsb /dev/rst8 3825 1750 /dev/sd0a
The "c" flag sets the density to 1000 bpi and the length to 1700 feet, but
dump(8) says to use "s 3825" for high-density cartridges (I presume 450 ft.)
This is a little higher than you'd get using the length formula given:
(length * tracks) * 0.9 = 450 * 9 * 0.9 = 3645
The point though is that the blocking factor recommended above is much
higher than used by any of my respondents, and it really makes the tape
drive rip.
Here's to faster dumps,
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119,
Palo Alto, CA 94303
------------------------------
Date: 7 Aug 87 03:14:25 GMT
From: elroy!david@seismo.css.gov (David Robinson)
Subject: Re: Why do our Sun 3/160 backups take 3+ hours?
> From: yetti!gen1!tyler (Tyler IVANCO)
> Subject: Re: Why do our Sun 3/160 backups take 3+ hours?
>
> I believe your problem is common to all systems using streamer tape
> drives. The problem is basically that unix cannot supply the streamer
> drive with data fast enough. I had the same problem and wrote a small
> block program that collects data from a pipe into a say, 1Mbyte buffer,
> then uses a single write call to dump to stdout.
.... Program deleted
Unix can supply data fast enough to stream a tape drive. Two people have
spend a large amount of time trying to get dump to stream tape drives,
Chris Torek and Don Speck. Chris approached the problem by writing a
"mass" driver that is simple enough that it can make a tape stream, Don
spend many hours rewriting dump to use multiple readers and writers. The
result is the 4.3bsd dump program.
I have been using a version of Don's dump for well over a year and I have
no trouble streaming tape drives. Our 1/4" 3/260 starts at the beginning
and streams continuously until the end with only pauses to change
direction. Running in 4 track mode a 450ft tape takes ~3.5 minutes and in
9-trk mode 450ft tape takes ~10 minutes. With a double buffered /etc/rmt
remote dumps work just as fast if the tape server is not being used.
Experiences with other Suns indicate that the 1600 bpi CDC Sun-2 drives
are terminally slow because of the software byte swapping, Sun-3 1/2"
tapes will stream almost continuously also.
It is worth the time to port the 4.3bsd dump if you have it available.
Rumor has it that Sun will include it in the SunOS 4.0 release, if this is
not true call your local Sun Rep and demand it!
David Robinson elroy!david@csvax.caltech.edu ARPA
david@elroy.jpl.nasa.gov (new)
seismo!cit-vax!elroy!david UUCP
Disclaimer: No one listens to me anyway!
------------------------------
Date: 7 Aug 87 14:01:17 GMT
From: dad@ciprico.mn.org (Dan A. Dickey)
Subject: Stream using the block device.
This is in regard to the question about streaming a quarter inch tape and
all the replies.
I've often wondered why Sun doesn't include the block device nodes for the
streamer. This way, you are most likely to always stream the drive....no
problem. I understand that people are used to using the raw device to
send larger records to tape; but this was for the days of nine-track
drives. The larger records were used to cut down on the number of
inter-record gaps, which used up a lot of the tape. The Quarter-inch
drives have NO inter-record gaps, so you can send data however you like,
it always gets written in 512 byte blocks. The gist of this is, USE THE
BLOCK DEVICE FOR QUARTER-INCH DRIVES!
Note that by using the block device you don't need these huge 1 Meg or
more buffers tying up memory...just don't specify any blocking factor to
tar or cpio...it will stream...I've demonstrated this a number of times.
People just go "WOW...that's really neat!" and then forget about it.
BTW, this assumes that you actually can get data off of your disk drives
fast enough for the tape system....this usually isn't a problem though,
not with slow quarter-inch tape (compared to a nine-track system it is
slow).
I'd appreciate it very much if someone could explain to me either:
A) I'm way off base on this... (I think this is unlikely)
or B) Sun chose not to do this...
------------------------------
Date: Mon, 27 Jul 87 23:19:51 +0200
From: mcvax!olsen!lance@seismo.css.gov (Lance Berc)
Subject: Re: Power supply in Sun-3/160 shuts down without warning
(In response to John Gilmore 22 Jun 87)
I haven't had that problem yet with a Sun, but earlier this month
several of our Eagles underwent spontaneous power-down when the outside
temperature was in the 90s. My Fujitsu manual says that the power supply
turns itself off when the transformer overheats (at 139C) or when the
heatsink gets too warm (90C). I don't know what the specifications are
for the Sun power supplies. They're probably proprietary.
The drives don't seem to be permanently damaged, though getting two of
them to turn on often requires several power cycles and lots of
patience. The symptoms are identical to what you described: the PS fans
start blowing but the platter stays idle when the start switch is
actuated (lights are on but nobody's home?).
I'd estimate that the computer room was between 100F and 110F, with very
little air movement in the room besides the equipment's internal fans.
Since then we've removed the skins from the drives and aimed a few room
fans at them. Since then we've installed air conditioning (costlier!).
In the past I've seen 3com ethernet boards go into net-spew mode when
their owners left them (Sun-100s) in direct summer sunlight. This can be
very hard to debug since the packet's source address is randomized.
Lance Berc lance@pescadero.stanford.edu (forwards to:)
mcvax!olsen!lance@seismo.css.gov
------------------------------
Date: Mon, 27 Jul 87 17:42:13 PDT
From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
Subject: Use of vadvise(VA_ANOM) within Lisp
This afternoon, I used an undocumented hack (thanks, Eric!) to persuade
Ibuki Common Lisp (nee Kyoto Common Lisp) to issue a vadvise(VA_ANOM)
call. I arranged for the call to occur at the beginning of some fairly
crunch/disk intensive processing that I've been doing on my Sun 3/52
workstation... typically, it involves a good deal of paging. For what
it's worth, here's what I found...
-------- excerpted... --------
I used si:faslink to install my advise() function in a 2.8-meg image that
we had loaded up. I then ran one of my typical crunching commands under
semi-controlled conditions. Each test consisted of a (si:faslink) of the
advise() function, the printing of a status message, calling advise (or
not...), and then a (dotimes) form that ran the crunch function three
times on the same input. The crunch function consisted of a mixture of
compiled and interpreted code; it generated no printed output during
execution (thus ensuring that the cmdtool process would not be swapped
into memory during execution). The machine was otherwise essentially idle.
The test sequence was repeated twice. Results are as follows:
Without calling vadvise(VA_ANOM):
125.8u 51.7s 4:46 62% 12+76k 82+38io 1610pf+2w (first time)
123.8u 52.9s 4:33 64% 12+76k 90+39io 1427pf+1w (second time)
With a call to vadvise(VA_ANOM)
132.1u 78.1s 6:20 55% 9+67k 88+37io 1747pf+0w (first time)
131.2u 80.9s 6:28 54% 9+67k 88+37io 1803pf+0w (second time)
It appears that calling vadvise(VA_ANOM) has resulted in a significant
increase in page faults (10-20%), a large increase in system time for the
process (more than 50%), and a big increase in elapsed time to complete
the job (40% or so).
My initial conclusion is that during normal operation, Ibuki CL is
accessing memory in a "regular" enough fashion that the standard Unix
memory-statistics heuristic is doing more good than not, and that a
standardized call to vadvise() at the beginning of a CL session would
probably not be a good idea.
It might prove useful to modify the CL garbage-collector to call
vadvise(VA_ANOM) at the beginning of a garbage collection pass, and then
reset to normal behavior via vadvise(VA_NORM) at the end of garbage
collection. I don't really have the resources or knowledge to make such a
decision meaningfully.
--- end of excerpt --
I'd be very interested in hearing from anyone else who has used
vadvise(VA_ANOM) in a LISP environment and gotten beneficial results, or
who can enlighten me as to the UNIX page-swapping heuristics (anyone know
of any good books on that portion of the kernel?)
Uucp: /decwrl|hplabs \
{ seismo|uw-beaver}!teknowledge-vaxc.arpa!dplatt
\ucbvax|sun /
Usnail: Teknowledge Inc., 1850 Embarcadero Road, Palo Alto CA 94303
Voice: (415) 424-0500
------------------------------
Date: Tue, 4 Aug 87 00:56:50 MST
From: "Bill Mitchell" <whm@arizona.edu>
Subject: multiple-machine executables
I find myself frequently inconvenienced by the incompatibilities between
different Sun binaries. Sun-2 binaries will work on a Sun-3, but not
vice-versa and I expect that Sun-4 binaries work iff they're on a Sun-4.
A fairly straightforward solution to this problem seems to be to extend
the executable format so that multiple executables can be contained in a
single file. Thus, if you've got Sun-2s and Sun-3s lying around, it'd be
nice to have an executable that contains both Sun-2 and Sun-3 versions of
the same program. If you run it on a Sun-3, it fishes out the Sun-3 code
and if you run it on a Sun-2, it fishes out the Sun-2 code.
I asked someone at Sun about this and they said that although Sun had
talked about it there were no plans for doing it at the current time. As
the only specific reason for not doing this, he cited the extra disk space
required for such a format. Here, disk space is much cheaper than
programmer time and I'd gladly have binaries that are twice as big if I
didn't have to worry about two different executables.
As far as I've thought about it, it seems that it really wouldn't be hard
to implement this. I might go so far as to say that it would make a good
independent study project for a sharp student.
A possible plan of attack:
Fix the kernel to recognize the multiple format and ignore portions
of the file intended for other machines.
As with the kernel, fix programs that read a.out files to ignore
portions for other machines.
Produce a utility that will take one or more regular executables of
different machine types and produce a multiple-machine executable.
There's also the problem of object files, but since they're also a.out
files, a lot of the stuff for them would just fall out. As far as
production of multiple-machine object files is concerned, just modify the
language front ends to accept a list of machines to compile for and then
do each one in turn, adding each to the object file.
Has anyone else done much thinking about this? Any implementation attempts?
In some ways the current incompatibilities help Sun -- they provides some
motivation to roll out Sun-2s and roll in Sun-3s, but on the other hand, it
lessens (to near-zero for me) the motivation to roll in a Sun-4.
Bill Mitchell
whm@arizona.edu
{allegra,cmcl2,ihnp4,noao}!arizona!whm
------------------------------
Date: Mon, 3 Aug 87 14:49:56 +0200
From: Anund Lie <a_lie%vax.runit.unit.uninett@tor.nta.no>
Subject: Problems with yellow pages in SunOS 3.2
On a couple of occations we've created a user with a name that is a prefix
of another user name. In that case it sometimes happens that the new user
is prohibited from logging on. (It seems as if the wrong entry is
retrieved from the "dbm" file.) It happened with the names "steinar" and
"stein", but I wasn't able to provoke the error with the names "ab", "abc"
... "abcde".
Has this problem occurred to anybody else?
Anund Lie
Division of Computer Science
Norwegian Institute of Technology
N-7034 Trondheim, Norway
------------------------------
Date: Mon, 27 Jul 87 17:29:33 PDT
From: lacasse%rondo@rand-unix.arpa
Subject: SKY floating point board on 2/50?
Has anyone ever done this? I know a fellow who has a 2/50 with extra
memory somehow soldered onto the board. So he doesn't need the one slot
for memory. He has some software that needs the SKY board, and has a SKY
board but not the VME adapter for it. He wants to know if it is possible
to hook this up on his 2/50, and if so, what the proper switch settings
are on both the SKY board and Sun's VME->MULTIBUS adapter.
Thanks!
Mark LaCasse qantel!hplabs!sdcrdcf!randvax!lacasse
c/o The Rand Corporation cbosgd!ihnp4!sdcrdcf!randvax!lacasse
1700 Main Street decvax!randvax!lacasse
Santa Monica, CA 90406
213/393-0411 ext. 7420 lacasse@Rand-Unix
------------------------------
Date: Tue, 28 Jul 87 21:45:38 PST
From: rmr@sdcsvax.ucsd.edu (Robert Rother)
Subject: MTI board on a SUN3?
Does anyone happen to know the dip switch settings for a systech board
and the VME adaptor card that will go into a SUN3? Any help would
be greatly appreciated!
Robert Rother
rmr@sdcsvax.ucsd.edu
------------------------------
Date: 30 Jul 87 14:55:00 MST
From: diegert@sandia-2.arpa
Subject: OLCI coating on high-res monochrome monitor?
A new local sun sales fellow just called to tell me that their latest
price list noted that the OLCI (non-glare) coating was explicitly noted as
"not available" on the high-resolution monochrome monitor (Sun p/n 252A).
I ordered the 252A with assurance from Sun that "everything but the
low-end stuff has the OLCI coating." They quoted and accepted the order
with my assurance that we would not accpet the material if the monitor
came in with polished glass. I could use some help with changing the
order before our September 20 delivery.
1. Is the 252A monitor supplied only with polished glass?
2. Who supplies this monitor to Sun?
3. Why (if this is the case) no option for a coating? Isn't the
B&W monitor bright enough to take a coating?
4. Was ordering the 252A sight unseen a mistake, even if I do
choose resolution and brightness over color?
Thanks!
------------------------------
Date: Tue, 28 Jul 87 10:36:14 PDT
From: weiser.pa@xerox.com
Subject: slow windows?
"...After the user has interacted with those text items, he clicks on a
button and the application is called. the application then creates a
frame, a panel, and a canvas. Clicks on the panel buttons don't happen for
5-10 seconds, unless I run the application directly."
Sounds like a screen locking problem. Are you calling system inside an
explicit fork? You should be, so that your button press code can give
control back to the notifier. You should then use the notifier to tell
you when the fork ends (how to do this is well documented in the Sun
Window Programming Guide--the specific case of waiting for a child is
even used).
Basically, the rule when being called by the notifier is to do a little
something and then return. The notifier needs to get back in control as
soon as feasible. If you have a lot of work to do, fork. If you are
making extra windows directly, that works ok because those windows are
noticed by the notifier and kept track of as part of your window-world.
The calls return right away. Call system locks you inside the button-press
routine with the screen locked, and without telling the notifier what is
happening.
As I have said before, see my SDI game source code for lots of examples
of notifier usage and some useful notifier helper routines.
-mark
------------------------------
Date: 28 Jul 87 16:36:38 GMT
From: iuvax!ndmath!ndcheg!evan@seismo.css.gov (Evan Bauman)
Subject: info on UNIX TOPS?
I saw an ad in MacWorld yesterday from Centram that mentioned the
existence of UNIX Tops. For those who may not know, Tops is networking
software/hardware for the Macintosh computer that usually runs over
appletalk. Now we have some Sun workstations connected over ethernet and
a dozen Macs running MacServe over appletalk. The nets are just screaming
to be connected, especially since the laserwriter is on the appletalk, but
we're a little hesitant to buy a Kinetics box at $2500.
So my question is whether anyone know anything about UNIX Tops;
specifically
1) what hardware is necessary
2) what's the software like
3) how much will it cost
4) can we share the laserwriter between nets
5) will it also support SYSV based machines like
a Convergent Miniframe
Any and all info is appreciated.
Evan Bauman
University of Notre Dame
..!iuvax!ndmath!ndcheg!evan
------------------------------
Date: 29 Jul 87 11:48:23 GMT
From: pulli@seismo.css.gov (Jay Pulli)
Subject: Statistics packages for Suns?
I am looking for a commercial statistics package for a Sun 3. It's
capabilities would be pretty basic (correlation, regression, etc) plus
graphics. I am aware of a package called PSTAT, but it doesn't take
advantage of any of the Sun graphics features. I would appreciate hearing
from anyone with a recommendation or knowledge of such a package. I would
also appreciate email responses, since I don't usually monitor these
newsgroups. Thanks in advance.
Jay J. Pulli
Center for Seismic Studies
Arlington, VA
703/276-7900
pulli@seismo.CSS.GOV
------------------------------
Date: 29 Jul 87 19:28:07 GMT
From: harvard!adelie!munsell!atexrd!sda@seismo.css.gov (Stephen Ayers)
Subject: Ingres and Suntools?
Does anyone have and know of a good interface between Suntools and Ingres?
The Ingres forms would look much better with all the wiss bang features of
suntools (buttons, sliders, menus...)
If not a replacement for shelltool that better emulates the features (line
drawing, text modes, color...) of the DEC VT-2xx series would be nice.
Please e-mail direct, I will post if intresting results.
Thanks!
Steve Ayers, Atex, Inc., A Kodak Company
{{harvard,ll-xn}!adelie,{decvax,allegra,talcott}!encore}!munsell!atexrd!sda
+1 617 276-7384