SUN-Spots Digest, v4n6
Scott Alexander
Sun-Spots-Request at RICE.EDU
Fri Feb 28 10:21:04 AEST 1986
SUN-SPOTS DIGEST Thursday, 27 Feb 1986 Volume 4 : Issue 6
Today's Topics:
Sun multi-user licenses
Re: Xylogics 451 (3)
Re: Dhrystone discrepancies
tip problem
WYSIWYG Editors, Graphics & Spreadsheets
ksh on suns
time on a Sun?
hardware flow control on zs
inetd and nfsd problems
------------------------------------------------------------------------
Date: Wed, 19 Feb 86 07:15:25 est
From: Robert Morris <ram%umass-boston.csnet at CSNET-RELAY.ARPA>
Subject: Sun multi-user licenses
This astonishing price rise for multi-user licenses RAISES, rather
than lowers the price differential of Sun's vs. competition for
multi-user systems. Since Sun was already 20 % higher than similar
unix boxes, e.g. ISI. Conceivably, it even makes an IBM RT high end
system be a rational alternative to a Sun, something I thought would
never happen (do RT's run multi-user with their 4BSD software?) Note
further that for Sun 3's there presently appears to be only Sun's
VME->Multibus adapter + Systech multibus card as a serial line
cability. These seem over-priced at $4000 / 16 users (refurbished 1
board Able DH cards suitable for the VAX are selling for <$400 in the
mail order market, which is cheaper than repairing broken ones). Our
application is 16 terminals and 16 connections to single board
microcomputers. Is Sun going to want a 32 user license to sell us 32
lines?
This seems to be a message that Sun does not really want to be in this
part of the business. All in all it makes it particularly hard for
universities who are trying to incrementally replace their VAXen or
add more 4BSD computing power - such institutions, like my own, face
buying something like $50k / year of hardware over several years,
instead of all at once. Bigger purchases, it is my experience, tend
to induce Sun and others to offer bigger discounts; They are not
interested in "dribble" purchasing such as I describe (this is
especially true of startups, whose near term sales volume has a
tremendous effect on their efforts to raise capital).
DEC, IBM and others after the university time sharing market ought to
be pleased.
-----------------------------
Date: Wed, 19 Feb 86 11:03:22 mst
From: dspo!tomlin at LANL.ARPA (Bob Tomlinson)
Subject: Re: Xylogics 451
> Subject: Xylogics 451?
> Newsgroups: mod.computers.sun
> References: <1986.02.08.17.03.13.390.05518 at iapetus.rice>
>
> I would like to try Xylogic's new disk controller board, the 451,
> in my 2/170....
> ...My questions are, has any
> brave soul tried the 451 on their Sun yet and did it work?
We are using several of those new disks you are referring to on Suns.
We're using the Fujitsu M2333K (333MB in an 8 inch form factor). (The
M2333 is to the M2322 as the Eagle-2 is to the Eagle.) The Xylogics
450 will work with the new disks however it can't keep up and you blow
revs. We used a borrowed 451 (no changes to software) for a couple
weeks. It works exactly as if you had a 450, but fixed the
performance problem associated with too fast a disk and too slow a
controller. We used the 451 on a 2/120 running Sun Unix versions 2.0
& 2.1 (maybe version 1.4 also). We're also using the M2333 on 3/160s.
Another disk we're using is the Hitachi DK815 which gives 525MB in a 9
inch form factor. We're getting either the Hitachi 815 or the Fuji
2333 for just over $5K.
-- bob
-----------------------------
From: hitchens at uo.UTEXAS.EDU
Subject: Fat Eagles and Xy451s
Has anyone out there attached one of the new double-density eagles
to a Sun-3 (or even a Sun-2). It's my understanding that the Xylogics
451 looks the same as the 450 on the multibus (and therefore should
look the same on a multibus->vme adapter). The only effective
difference then, as far as the software is concerned, is that there
are twice as many sectors per track, and that information is recorded
in the disk label. That's my view of the universe, can anybody verify
it against reality?
I asked someone at Sun about this and he didn't really now for
sure. He said he thought there was support for it in the 3.0 diag,
which is what you need to get it formatted and labelled, but otherwise
couldn't help much. He pointed out that Sun doesn't support such a
configuration, but that doesn't concern us much since we do our own
maintenance, and have done quite a few unsupported things to our suns
already.
We're about to aquire about a new gaggle of suns (~25) and would
like to find out if we can plan on using the bigger eagles on our
servers. They make a lot of sense in terms of space/power/money
consumption per unit of storage. Has anyone tried it? The UT
beauracracy makes it very tough exchange something if it doesn't work,
otherwise we'd just buy one and give it a shot. Lead times for
purchasing are also excruciatingly long.
I'd appreciate any experience, opinions or inside info about this.
It's probably best to reply to me directly and I'll summarize to this
list.
Thanks,
Ron Hitchens University of Texas Computer Science
hitchens at uo.UTEXAS.EDU or hitchens at sally.UTEXAS.EDU
...!{seismo,ihnp4,shasta}!ut-sally!hitchens
-----------------------------
From: seismo!allegra!phri!roy at sally.utexas.edu (Roy Smith)
Subject: Re: Dhrystone discrepancies
Ken Mandelberg reported in v4n5 that Dhrystone runs 25% slower
on his 3/50 than it does on his 3/160. From looking at just the clock
speeds, he expected a 10% slowdown.
Based on what the Sun salespeson told me, the 3/160 processor
(also used in the 3/75 and 3/180) both have dedicated video memory in
addition to the basic 4 Meg of user memory. The 3/50 steals its video
memory from the regular 4 Meg array that comes with the machine
(funny, they don't tell you this in the glossies :-)). I suspect the
missing 15% is due to memory contention between the CPU and the video
refresh. If this is indeed the case, I would imagine that speeding up
the clock in the 3/50 won't gain you anything except more wait states.
The same salesperson told me the following:
Q: What's the difference between a computer salesman and
a used car salesman?
A: The used car salesman knows when he's lying.
--
Roy Smith, {allegra,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
-----------------------------
Date: Thu, 27 Feb 86 10:02 EST
From: PACE%FSU.MFENET at LLL-MFE.ARPA
Subject: tip problem
hi;
We are having a problem installing tip,uucp,etc on our
SUN-170. We have followed the instructions in the Hardware
Installation Guide and have gotten to the point where modems will
answer the phone and connect to the system but we can not make the
phones dial out. Has anyone done this and if so have I overlooked
anything that is so obvious that it is not in the manual. Also, were
there any tricky operations that were not adequately presented in the
book.
-don pace
Florida State University Computing Center
P.S. this is for our Center for Music Research.
-----------------------------
From: Christie Harslem <harslem at rand-unix.ARPA>
Date: 19 Feb 86 08:22:54 PST (Wed)
Subject: WYSIWYG Editors, Graphics & Spreadsheets
Besides Interleaf and Alis, can anybody give me some leads on WYSIWYG
editors, MacDraw type graphics and spreadsheets for the Suns? Send
comments to me and I will summarize to the net.
Thanks
-----------------------------
>From harvard!wanginst!ss at sally.utexas.edu Mon Feb 24 17:52:03 1986
Date: Mon, 24 Feb 86 12:48:13 est
Subject: ksh on suns
Hi folks,
Has anyone ported ksh to a sun yet? Seems likely, but I can't recall
hearing about it.
Thanks,
-- Sid Shapiro
-- Wang Institute of Graduate Studies
decvax!wanginst!ss
ss%wanginst.CSNET at Csnet-Relay.ARPA
(617)649-9731
-----------------------------
Date: Tue, 25 Feb 86 17:11:43 PST
From: mayo at renoir.berkeley.edu (Bob N. Mayo @ U.C. Berkeley Computer Science)
Phone: (415) 642-9716
Subject: time on a Sun?
It turns out that Suns do really odd things if the time is set wrong.
For instance, the yellow pages can get screwed up and it may not even
be possible to log in (execpt as root or some other name in the actual
/etc/passwd file).
Also, commands like "ls -l" may hang for a certain amount of time (the
time difference between the fileserver and the local machine).
Does anybody have a program that sets the time correctly? RDATE
doesn't count, since it can only adjust the time +/- 12 hours. How
about something that will at least get the date right, which can then
be followed by rdate?
--Bob
-----------------------------
From: harvard!wjh12!biomed!aoa!mark at sally.utexas.edu
Date: Wed, 26 Feb 86 11:53:15 est
Subject: hardware flow control on zs
I am trying to find out some information on the zs ( serial )
driver on the Sun 2. What I want to do is very simple: I would like
to use a tty port as an I/O port to a device that obeys hardware flow
control.
The device would be the DCE ( modem ) and the Sun's tty port
would be the DTE ( terminal ). If some combination of CTS DSR and CD
were made logically false the DTE ( the Sun ) would shut up and cease
to send; if some combination of DTR and RTS were made false the DCE
would shut up and cease to send. From the Sun's point of view these
telling the DCE to shut up would be conditioned on the zs silo being
full and/or inability of the software to eat characters as fast as
they are coming in.
The goal is that the device is uncontrollably shipping
completely arbitrary bytes at 9600 baud ( but never more than 8K ). I
want to prevent any lost bytes. I am sure this has been discussed
before.
I do not have source, nor do I have a hardware manual for the
zs. What I think I have learned so far from poking around in various
places is:
1) There are an extremely large number of ioctls that may or
may not apply to ttys in <sys/ioctl.h>. Some do obvious
and verifiable things ( TIOCCDTR and TIOCSDTR for
example ), others are obscure. Most do not seem to be
documented in any documentation I have.
2) Poking around the zs includes in /sys/sundev would seem to
indicate that the zs device has a mode in which it uses
hardware flow control ( ZSWR3_AUTO_CD_CTS bit );
3) Looking at the terminal line during both inbound and
outbound transfers shows that only TxD, RxD, and DTR are
active.
My question is, can a tty device be put in a mode which uses hardware
flow control? If so, how? If not, what other alternatives are
available? Please help; this is quite important.
To qualify my question, let me say I am a Sun novice. I have been
around UNIX for quite a while, and I THINK I understand the RS232
so-called standard. Please feel free to flame my ignorance and/or
stupidity.
Thank you in advance. Please mail responses to me. I will summarize
if interest warrants.
Mark Reynolds @ ( Adaptive Optics Associates )
{ wjh12 | mit-vax } ! biomed ! aoa ! mark
{ decvax | linus | ima | ihnp4 } ! bbncca ! aoa ! mark
-----------------------------
Date: Mon, 24 Feb 86 23:31:49 PST
From: argv at sri-spam.ARPA (AAAARRRRGGGGv)
Subject: inetd and nfsd problems
Has anyone had problems with inetd and nfsd on sun 2.2 systems (or
even 2.0)? The scenario: Various file servers ranging from a few
120's a 150, 160 and 170 were all (at one time) running 1.4 The 150
upgraded to 2.0 and was running just fine with about 11-12 clients.
Load on the server hung around 1.5 to 2. Nothing really
extraordinary... next file server to 2.0 -- a 120 with 3-4 clients.
No problem. Finally, a complete 2.2 system was installed on a 120
with two maxtor 1140's, six clients alloted for but only running two.
Fine. Add another client... fine. Upgrade the 2.0 120 to 2.2 and
everything is running like a dream. So, we upgrade the 150 from 2.0
to 2.2 and bring it up. Immediately, the load went sky high to about
10.5 to 12 and nfsd's were eating all the cpu time. In fact, so much
so that it was impossible to login on the console. Clients were
running a little better, but not significantly. /usr/adm/acct fills
up the entire root partition on all clients with inetd messages --
forked inetd's were occuring about 100 or so times per minute! Most
clients had accounting suspended before the boot procedure was
finished. So, killing the inetd completely allowed clients to work
again at a reasonable rate and the server seemed a little happier.
However, in only one-two days, nfsd shows (from ps) a time consumption
of about 1400 minutes and some-odd seconds and all four were taking
from 15 to 25% percent of cpu time per nfsd. We tried killing them
and running nfsd with 8 daemons, but this did nothing. In the
meantime, inetd is going crazy everywhere. Out of desparation, we
downgraded back to 2.0 and ran things again. The problems still exist
but at a lesser rate. It takes about 2 minutes to login as root on
the console and inetd's are still going crazy and nfsd's are as well.
The only difference is that it tapers off during slower times but not
to an acceptable level. At one point, the server crashed when the
load hit over 18.
All the other 2.2 systems showed the same problems when given more
than 4 clients. according to netstat, packets are going out into the
net at about 100/second and we're getting collisions ranging from 1 to
8 percent on both 2.0 and 2.2 systems.
What I don't understand is why the problems persisted when the 2.2
upgrade went back to 2.0. We are now installing 2.0 on a new file
server with 15 or so clients and 2.0 on yet another with 15 as well.
Since we didn't have the problem before the upgrade on the other
servers, hopefully we won't have the problem again. But, before we
can upgrade to 2.2, we need to be sure that this doesn't happen again.
I haven't heard of any other people having this problem to such an
extreme, altho I have heard of people having problems with inetd. In
fact, I use another file server (a 130 -- vme based) with 15 clients
that is running 2.2 without problems. I have examined binaries and
config files, /etc files, fstabs, anything. There is nothing
obviously wrong (unless it's TOO obvious) but there is something there
causing all this.
If anyone has any experience with the same sort of problem, please
mail me --
dan
argv at sri-spam.arpa
-----------------------------
End of SUN-Spots Digest
***********************
More information about the Mod.computers.sun
mailing list