duncan@comp.vuw.ac.nz (Duncan McEwan) (04/15/88)
Our department will shortly be buying a small number of (20 or so) diskless workstations for staff and graduate student use. The options currently appear to be a mixture of Sun 3/50's and 3/60's, or HP 9000 series 300 model 318's (I think similar in max config to a Sun 3/50 except you *can't* put a local disk on it - they are about 20% cheaper than the 3/50, possibly because of this fact). An alternative might be IBM PS/2's running AIX but we are not sure if they can function in an NFS based diskless environment. The two problems are deciding on the appropriate file servers, and figuring out which workstation(s) to buy. The local Sun agents have suggested that for 20 or so workstations we might be looking at two Sun 3/180's to handle the load. HP's suggestion was similar but based on HP 9000 model 350's. But with these file server machines costing approx $NZ70,000 (approx $US45,000) each we would like to look at other alternatives. One alternative might be a single Sun-4, although I am not sure how much that will cost. Another option is that as part of the same equipment proposal we hope to upgrade our current pyramid 90x (8Mb main memory - no data cache) to a pyramid 9805 or 9810 with probably 16Mb memory). The pyramid's main task would be to support 30-50 undergraduate and graduate student's (not simultaneously). Would it also be able to support the load of acting as a file server for the above number of diskless workstations doing typical (whatever that is) work? If it cannot support the load by itself, what about an upgraded pyramid in conjunction with a single Sun or HP file server? Regarding the choice of workstation. I believe it is possible for Sun workstations to boot over NFS now, rather than using the old "nd" protocol. Would this be possible with a Pyramid acting as a file server, or would we need at least one Sun file server? Can the HP workstations running HP/UX also boot over NFS? Would they be able to boot from a non-HP file server? How well could we expect a mixed environment of diskless Sun's and HP's (and possibly PS/2's) to work? I think that is enough questions for one article. Any help would be appreciated, especially from people who actually have had experience with any of the above combinations. Email reponses - if there is enough demand, I will summarise. Duncan Domain: duncan@comp.vuw.ac.nz Path: ...!uunet!vuwcomp!duncan
rroot@edm.UUCP (uucp) (04/20/88)
From article <13504@comp.vuw.ac.nz>, by duncan@comp.vuw.ac.nz (Duncan McEwan): > Regarding the choice of workstation. I believe it is possible for Sun > workstations to boot over NFS now, rather than using the old "nd" protocol. > Would this be possible with a Pyramid acting as a file server, or would > we need at least one Sun file server? If nothing else you could look at putting one real cheap disk on one of the suns, and then have all the machines look to the Pyramid for the rest of their file server work.. (needless to say, I've never done this) -- ------------- Stephen Samuel {ihnp4,ubc-vision,vax135}!alberta!edm!steve or userzxcv@uqv-mts.bitnet
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (04/21/88)
duncan@comp.vuw.ac.nz writes:
Our department will shortly be buying a small number of (20 or so)
diskless workstations for staff and graduate student use.
The options currently appear to be [Sun3/[56]0's or HP 9000/300's].
The two problems are deciding on the appropriate file servers, and
figuring out which workstation(s) to buy.
Personally, I would recommend the Suns. We're using both here, and my
clear preference is for the Suns. The HPs have enough differences in
them that they cause quite a bit of grief in convincing them to cope
with the heavily BSD-and-NFS environment in which we work. The HPs
are considerably more SysVish than BSDish, with the result that a lot
of things on them are incompatible at some level with our BSD systems,
notably including our Pyramid 98x, on which reside major things like
the department-wide /usr/spool/mail filesystem. Consider the problems
of a SysV mailer, believing in setgid-mail delivery, as opposed to a
BSD mailer, using setuid-root delivery. We found a solution to this,
so that the HPs can mount Tut:/usr/spool/mail like everybody else, but
let's just say that comedy is not pretty.
There is, of course, the 14-char filesystem. Also, HPs do funny
things with a single filesystem which is shared among the server and
clients, with personalizations for each workstation being accomplished
with something HP calls a `CDF,' a Context-Dependent File; a CDF is
actually a directory which contains filenames which are the
workstation names, and in turn those files contain the contents of the
intended filename. If you look at /etc/passwd, it looks different on
each system, but if you cd /etc/passwd+ (the `+' is how you talk about
a CDF in its directory form), you can see machine-name filenames.
It's weird stuff, and if you're mostly a BSD shop as we are, these
sorts of things can be quite a problem.
The local Sun agents have suggested that for 20 or so workstations
we might be looking at two Sun 3/180's to handle the load.
That's close, but they might be trying to sell you too much hardware.
We have 11 Sun3/180's; we put 12-20 clients apiece on them. You'll
find that ND won't serve more than 20 clients (it's a hard limit), so
if you're going to >20 workstations, >1 3/180 is an absolute
necessity. Performance is quite acceptable if you have sufficient
disc controllers. That is, one of our 3/180's is currently serving
two Super Eagles off of a single Xylogics 450 (or is it a 451? can't
remember now) controller. This is also the server with 20 clients -
paging activity can cause real problems. We're anxiously awaiting the
re-installation of the 2nd controller there. On any system with 1
controller per disc, things are really fine and acceptable. The
problem is in paging activity. Buy workstations with LOTS of memory,
to cut down your paging traffic.
HP's
suggestion was similar but based on HP 9000 model 350's.
I can't say much about load on those systems, other than to say that
we have 1 server with 6 clients, and it has certain perf. problems.
It is not clear at this time if it is due to hardware infant mortality
or software problems. We know that we are getting some long packets
on our backbone ethernet (1524 bytes), and that in turn is causing us
trouble with our Proteon gateway boxes that connects our dept with the
rest of the OSU campus network.
Another option is that as part of the same equipment proposal we
hope to upgrade our current pyramid 90x (8Mb main memory - no data
cache) to a pyramid 9805 or 9810 with probably 16Mb memory). The
pyramid's main task would be to support 30-50 undergraduate and
graduate student's (not simultaneously). Would it also be able to
support the load of acting as a file server for the above number of
diskless workstations doing typical (whatever that is) work?
The Pyramid can handle it after upgrade. I wouldn't try it before
upgrading, though, especially without the cache. Our 98x has 32Mb and
serves 30-50 people simultaneously during the heavier part of the work
day. It's currently mid-morning, and we are already getting
substantially loaded; by 2pm or so, there'll be 45 people logged in.
[111] [9:19am] tut:/dino0/karl> uptime
9:19am up 2 days, 23 hrs, 30 users, load average: 4.11, 3.40, 3.05
[112] [9:19am] tut:/dino0/karl>
He's got a fair amount of disc on him, 6 Eagles, which would be 7 if
the 7th were working.
/dev/iop/pdisk00a 19102 16042 1148 93% /
/dev/iop/pdisk02a 19262 170 17164 1% /tmp
/dev/iop/pdisk00c 47950 40946 2208 95% /usr
/dev/iop/pdisk10a 19318 8882 8504 51% /usr/spool
/dev/iop/pdisk00g 290054 256612 4436 98% /u0
/dev/iop/pdisk01h 387318 332188 16398 95% /u1
/dev/iop/pdisk10f 338822 285804 19134 94% /u2
/dev/iop/pdisk11f 338558 310332 28226 92% /u3
/dev/iop/pdisk03i 367646 29154 338492 8% /usr/spool/news
/dev/iop/pdisk03a 19262 4068 15194 21% /usr/lib/news
/dev/iop/pdisk02b 29054 18 26130 0% /ai0/sys
/dev/iop/pdisk02f 338558 260712 43990 86% /ai0
Tut also mounts 14 filesystems from assorted Sun servers and other
Pyramids (we also have 2 98xe's and 2 90x's). Most of those
filesystems are exported to 140 Suns, about half of which are
inhabited by grad students, faculty, and staff, and the remaining half
by undergrads using filesystems resident on systems other than Tut.
Tut slows down in mid-afternoon when his direct timeshare load hits 50
users and the workstation load is similarly high, but he keeps working
and things keep getting accomplished. He's configured with about
110Mb of swap space (3 Eagle `b' partitions and one `a').
Regarding the choice of workstation. I believe it is possible for
Sun workstations to boot over NFS now, rather than using the old
"nd" protocol. Would this be possible with a Pyramid acting as a
file server, or would we need at least one Sun file server?
Pyramid demo'd discless Sun service at the Dallas UniForum in
February. It's not ready for release, apparently (they were using a
hacked SunOS 3.2, from what I was told), but it's Almost There.
Can
the HP workstations running HP/UX also boot over NFS? Would they
be able to boot from a non-HP file server? How well could we
expect a mixed environment of diskless Sun's and HP's (and possibly
PS/2's) to work?
Sorry, don't know, such ideas don't fit in with our plans/goals.
Hope this helps,
--Karl
csg@pyramid.pyramid.com (Carl S. Gutekunst) (04/22/88)
In article <11219@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes.... ...an excellent commentary. >>I believe it is possible for Sun workstations to boot over NFS now, rather >>than using the old "nd" protocol. Would this be possible with a Pyramid >>acting as a file server, or would we need at least one Sun file server? >Pyramid demo'd discless Sun service at the Dallas UniForum in >February. It's not ready for release, apparently (they were using a >hacked SunOS 3.2, from what I was told), but it's Almost There. Pyramid is actually ready. (Honest.) It's Sun that is holding up the show. Diskless NFS is on the laundry list of features in SunOS 4.0. When Sun ships 4.0, you will be able to use a Pyramid as your server, with no Sun server. So far the only companies that have demonstrated diskness NFS are DEC, Pyramid, and (of course) Sun. Maybe Mt. Xinu, too. Should be lots more later. No support is planned for diskless Pyramids. :-) Latest rumors are that SunOS 4.0 will start shipping around June-July-August. So much has changed in this release that Sun is testing it exhaustively. <csg>
sas@pyrps5 (Scott Schoenthal) (04/22/88)
In article <20398@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >Pyramid is actually ready. (Honest.) It's Sun that is holding up the show. Well, yes and no. We (and the other NFS vendors who are working on building support of diskless NFS clients into their products) have been doing integration using a Beta release of the diskless server software from Sun. The final release from Sun to vendors is due Any Day Now. >Diskless NFS is on the laundry list of features in SunOS 4.0. When Sun ships >4.0, you will be able to use a Pyramid as your server, with no Sun server. Well, yes and no. Support for diskless NFS clients will be available in only the most recent version of OSx (indications are that this will be 4.4) at the time when the software is ready. There will be no attempt to support diskless NFS clients in earlier versions of OSx: no retrofitting. >Latest rumors are that SunOS 4.0 will start shipping around June-July-August. >So much has changed in this release that Sun is testing it exhaustively. I would expect the Pyramid product to be available "soon after". sas ---- Scott Schoenthal sas@pyrps5.pyramid.com Pyramid Technology Corp.
ron@topaz.rutgers.edu (Ron Natalie) (04/25/88)
I see no reason why you will not be able to use the SUN4 as a server, but I'm not sure it will get you anything. I'm not sure the I/O bandwidth on a Sun 4 is going to be sufficiently better. BRL runs their SUN network with next to no SUN servers on it. Using some Gould PN systems with Chris Torek's ND code for the root/swap and the Gould provided NFS for everything else works well. Of course, the code had to be throttled back as the Gould Ethernet interfaces will outdrive the poor Suns. -Ron