dougm@umrisca.isc.umr.edu (Doug Meyer) (10/12/89)
I am posting this for a friend. Please respond to the address given below.
We are considering setting up a small lab of SUN Sparcstations and were
wondering if anyone else had had experiences (good or bad) with a similar
setup. Here is what we are considering:
1.) ~10 Sparcstations, each with 8M of memory and a single 104M local disk
for paging and temp space.
2.) An additional Sparcstation with ~2G of SCSI disk space to act as a
file server for 1.).
We would also appreciate knowing, from those that have similar installations,
what type of high capacity disks are being used. The SUN rep here is
understandibly trying to sell us their drives, but we are seriously
considering going to a third-party for them.
Thanks,
Ralph Wilkerson (ralphw@gator.cs.umr.edu)
Department of Computer Science
University of Missouri - Rollapoffen@sj.ate.slb.com (Russ Poffenberger) (10/23/89)
In article <2276@brazos.Rice.edu> dougm@umrisca.isc.umr.edu (Doug Meyer) writes: |X-Sun-Spots-Digest: Volume 8, Issue 166, message 25 of 26 | |I am posting this for a friend. Please respond to the address given below. | |We are considering setting up a small lab of SUN Sparcstations and were |wondering if anyone else had had experiences (good or bad) with a similar |setup. Here is what we are considering: | | 1.) ~10 Sparcstations, each with 8M of memory and a single 104M local disk | for paging and temp space. | 2.) An additional Sparcstation with ~2G of SCSI disk space to act as a | file server for 1.). | |We would also appreciate knowing, from those that have similar installations, |what type of high capacity disks are being used. The SUN rep here is |understandibly trying to sell us their drives, but we are seriously |considering going to a third-party for them. We have three SS-1's in house, and 2 SS-370's in house. I would definitely recommend the 370 as the server for your SS-1's. I have a Xylogics 753 in the 370 with a CDC sabre connected to it. It works great. I am kind of partial to the CDC's, I am sure you will get other opinions. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110
greg@duke.cs.unlv.edu (Greg Wohletz) (11/09/89)
|We are considering setting up a small lab of SUN Sparcstations and were |wondering if anyone else had had experiences (good or bad) with a similar |setup. Here is what we are considering: | | 1.) ~10 Sparcstations, each with 8M of memory and a single 104M local disk | for paging and temp space. | 2.) An additional Sparcstation with ~2G of SCSI disk space to act as a | file server for 1.). We have 25 sparactations here, each has 8 meg and a load 104M disk. Our experiance has been that 8M of memory is not sufficient. With about 3 windows open, and a C compile going the machine will page heavily. We are planning on uping most of ours to at least 12Meg. --Greg
wyle@relay.eu.net (Mitchell Wyle) (11/13/89)
In article <2910@brazos.Rice.edu> greg@duke.cs.unlv.edu (Greg Wohletz) writes: >X-Sun-Spots-Digest: Volume 8, Issue 192, message 2 of 14 >|We are considering setting up a small lab of SUN Sparcstations and were >|wondering if anyone else had had experiences (good or bad) with a similar >|setup. Here is what we are considering: >| 1.) ~10 Sparcstations, each with 8M of memory and a single 104M local disk >| for paging and temp space. >| 2.) An additional Sparcstation with ~2G of SCSI disk space to act as a >| file server for 1.). Unless you plan to stay at a 4.0.x release of SunOS, Sunview, and have fewer than 3 windows open, you should *definitely* get more than 8 Mb per ss-1. You mentioned nothing about the applications you want to run. Lots of large compiles? Oracle? Get more memory. Wait til January to get your memory, though. There is a production line in Japan about to open which will double the world's current 1Mb simms output. >We have 25 sparactations here, each has 8 meg and a load 104M disk. Our >experiance has been that 8M of memory is not sufficient. With about 3 >windows open, and a C compile going the machine will page heavily. We are >planning on uping most of ours to at least 12Meg. It seems to me that 12 is a bad compromise. Either you limp along with 8 or you go whole-hog for 16. The German Sun Users' group electronic mailing list had a discussion about xview News/X and memory; 12M wasn't quite enough. The consensus was that future SunOS releases are going to want 16M in a compiling environment and at least 12 MIPS. It sort of reminds me of the IBM Mega-line-of-code operating systems which eat 1 MIPS to figure out what to do with one key stroke...
pbg@cs.brown.edu (11/14/89)
I disagree about memory requirements. We have 150 sparcstations all at 12mb, and find it generally sufficient for our current software load. The environment I run in is SunOS 4.0.3, X/NeWS, gnuemacs, 4 xterm windows, and a perfmon program. I have no paging to disk in this environment. Our SPE/Lisp users certainly can and do use 16mb, but given that memory prices are dropping again (at least from 3rd parties, if not from sun) it makes sense to buy only as much memory as you currently need, not as much as some future operating system will need. Also, at the last SUG conference Sun said that 4.1 should have performance and memory improvements, but we've heard that before :-). --Peter Peter Baer Galvin (401) 863-7623 Systems Manager, Brown Univ. Comp. Sci. pbg@cs.brown.edu Box 1910 (115 Waterman Street) uunet!brunix!pbg Providence, RI 02912 pbg@browncs.bitnet
chris@com2serv.c2s.mn.org (Chris Johnson) (11/16/89)
>It seems to me that 12 is a bad compromise. Either you limp along with 8 >or you go whole-hog for 16. The German Sun Users' group electronic >mailing list had a discussion about xview News/X and memory; 12M wasn't >quite enough. The consensus was that future SunOS releases are going to >want 16M in a compiling environment and at least 12 MIPS. Did this (and similar articles) strike anyone like it hit me? I started using Sun workstations with a 2/120. I could run compiles with 4 or 5 windows open, plus 2 more processes off the asynch. comm. ports, and it only had 2 (two) Mb of memory. Sure, it had to do more than a little swapping, but it did work. More and more, I get the feeling that either system developers (1and not just the OS groups at Sun) are getting very spoiled by the ability to have lots of memory, or they are just becoming incompetent. Yes, yes, I know all about the arguements of cost of memory versus cost of development time, and so forth. And that's not at all what I'm talking about, really. It _IS_ a tradeoff, after all. But it appears that noone is considering it for than about 10 seconds, and from the distorted point of view of "my machine has 32Mb of memory, so certainly 16Mb for a user is not unreasonable". Memory may well be becoming cheaper and cheaper, but there is a huge installed base of machines out there that do _NOT_ handle easy installation of additional, inexpensive memory! Frankly, I think it is completely undefensible for SunOS4.0.3 to require 16Mb in a machine that comes with 8Mb standard to function well. Especially given that SunOS4.0.1 ran in 4Mb, and ran well in 8Mb (albeit in a Sun 4/260), and further that SunOS3.5 ran well in 2Mb. I know there are lots of bright, talented programmers at Sun. In fact, there's quite a few of them who are good friends of mine, who I would call damn good programmers. But apparently there is a lack of them in OS group. I'd be embarassed to admit I had a hand in such a grossly overweight, lumbering operating system! How do you feel about this? Am I over the hill at 32 and 14 years of experience, trying to write efficient, compact code? Or do we have too many young brats, spoiled by megabytes of memory? Having seen Unix source code, and having seen what happens to systems which are enhanced and modified by many people over many years (this fits Unix and SunOS to a "T", folks), I can just imagine the number of new features that were added by people who avoided the difficulty of finding out what was already available and how it worked, and instead, just added lots more data structures and code, instead of reusing or generalizing existing software. Incidentally, this obviously goes for applications software, as well. In fact, this very issue has been editorialized and discussed at length in the IBM PC clone/MS-DOS world. I'm not sure, but I suspect X Windows is a serious pig in this department. Chris Johnson UUCP: chris@c2s.mn.org Com Squared Systems, Inc. ATT: +1 612/452-9522
hedrick@geneva.RUTGERS.EDU (Charles Hedrick) (11/28/89)
There is an implication in this article that SunOS 4.0.3 requires more memory than 4.0.1. I know of no evidence for this. We are in the process of moving from 4.0.1 to 4.0.3c. I have not seen any decrease in performance. Since my desktop machine is 4MB 3/50, I'm pretty sensitive to memory usage. In fact there is some reason to think that 4.0.3 Suntools is better than 4.0 Suntools, though it's hard for me to be sure about that since our staff are all using X. You refer to a German Sun Users' group discussion of XNeWS, but list the conclusion as if referred to SunOS rather than XNeWS. Everyone agrees that XNeWS requires more memory than current window systems. But this is not a problem with SunOS. It's not even sloppy coding in XNeWS. It is an obvious implication of running software that implements two window systems at the same time. XNeWS is by no means compulsory. I plan to use vanilla MIT X on our smaller machines. The X-based applications from XNeWS work fine with the MIT X server, as long as you have the extra fonts. (Those fonts are now available from MIT.) Fortunately, the XNeWS versions of the standard Suntools software are all X-based. Thus I don't think people will lose much if they have access only to X.
montanaro@crdgw1.ge.com (12/06/89)
Charles Hedrick writes:
Everyone agrees that XNeWS requires more memory than current window
systems. But this is not a problem with SunOS. It's not even sloppy
coding in XNeWS. It is an obvious implication of running software that
implements two window systems at the same time.... The X-based
applications from XNeWS work fine with the MIT X server ...
If the XNeWS server is run with X11ONLY set, memory consumption is
drastically reduced. (On my machine it went from 4+ MB to 2+ MB, according
to top.) SunView applications can still be run, but WINDOW_PARENT must be
set explicitly to /dev/win0. There appear to be some problems running
XView applications like filemgr if X11ONLY is set (problems displaying
property sheets, etc.).khb@sun.com (12/08/89)
In article <3269@brazos.Rice.edu> it is written: >X-Sun-Spots-Digest: Volume 8, Issue 206, message 4 of 15 > >>It seems to me that 12 is a bad compromise. Either you limp along with 8 >>or you go whole-hog for 16. The German Sun Users' group electronic >>mailing list had a discussion about xview News/X and memory; 12M wasn't >>quite enough. The consensus was that future SunOS releases are going to >>want 16M in a compiling environment and at least 12 MIPS. > >Did this (and similar articles) strike anyone like it hit me? I started >using Sun workstations with a 2/120. I could run compiles with 4 or 5 >windows open, plus 2 more processes off the asynch. comm. ports, and it >only had 2 (two) Mb of memory. Sure, it had to do more than a little >swapping, but it did work. [stuff deleted about SunOS 4.0.x's use of memory] You are confusing a bunch of issues (which is what most of us do when getting hot and bothered about these topics). The following are all inter-related: 1) users expect _much_ better response times now. If you set up a sun2 and a sun4/60 next to each other, one is surprised at how much slower the sun2 really is. Back when the sun2 was king, that kind of response was good (sunview, etc.) .... one remembers being happy, NOT how many milliseconds a window open took. 2) users expect much more functionality. Scalable fonts ? outline fonts ? etc. 3) users expect/demand much better optimizers. optimization is good for about 30% speedup on a sun3 (less on a sun2, if memory serves). Often good for a 4x speedup on large f77 applications .... this does involve more work for the optimzer, more memory requirements etc. Not enough users employ prof/gprof/tcov to limit the modules which get the -O4 treatment :> 4) The window system is a MUCH bigger issue than the OS. In fact, the debris of sunview are a large part of the bloat. Someday xview will obviate kernal support for sunview. Alas, that day isn't yesterday. :> 5) Some of the TOOLs are the real pigs. Since sun does not _yet_ ship good user-level tools to watch who consumes what memory when, this is hidden. 6) It is not clear to me that the Germans are right. I used to have have an 8mb machine and I was quite happy with its performance. I had to give that up, now I have a slower CPU, but more RAM (and more local disk, and more noise, and a high res monitor). I speak for myself, not my lords and masters of the payroll. Also, I'm not part of the windows nor the OS teams ... so I'm liable to be wronger than usual :>
clh@uunet.uu.net (Chris Hermansen) (12/10/89)
In article <3269@brazos.Rice.edu> chris@com2serv.c2s.mn.org (Chris Johnson) writes: >X-Sun-Spots-Digest: Volume 8, Issue 206, message 4 of 15 > >>It seems to me that 12 is a bad compromise. Either you limp along with 8 >>or you go whole-hog for 16. The German Sun Users' group electronic >>mailing list had a discussion about xview News/X and memory; 12M wasn't >>quite enough. The consensus was that future SunOS releases are going to >>want 16M in a compiling environment and at least 12 MIPS. > >Did this (and similar articles) strike anyone like it hit me? I started Well, I'm still picking myself up off the floor... >using Sun workstations with a 2/120. I could run compiles with 4 or 5 >windows open, plus 2 more processes off the asynch. comm. ports, and it >only had 2 (two) Mb of memory. Sure, it had to do more than a little >swapping, but it did work. ... >More and more, I get the feeling that either system developers (1and not >just the OS groups at Sun) are getting very spoiled by the ability to have >lots of memory, or they are just becoming incompetent. > >Frankly, I think it is completely undefensible for SunOS4.0.3 to require >16Mb in a machine that comes with 8Mb standard to function well. >Especially given that SunOS4.0.1 ran in 4Mb, and ran well in 8Mb (albeit >in a Sun 4/260), and further that SunOS3.5 ran well in 2Mb. I agree 100%. Every so often some crotchety neanderthal comes along and says `How come I need another 4Mb of memory to run the same application mix with the new release of the system', and hordes of salesmen and gurus shrug suavely and say `well, that's just the price of progress, and besides, memory upgrades are so cheap, it's hardly even a cost item'. Bulls**t, I say. WHY is every new release more of a hog than the previous one? Is it because the 4.0.x world is more complicated than the 3.x one? Or is it a bit of carelessness, like the four or five-level deep set of symbolic links that the configuration program generates around the executables exported by an NFS server? Don't try and hand us the argument that something actually needs to be that big. Remember Turbo Pascal? I haven't looked at 5.x, but 3.x, the last version I played with, took up less than 50k, including the editor, compiler, and a run-time monitor. No shared libraries, either. On my Sun 3, tacitus% ls -l /usr/ucb/pc -rwxr-xr-x 1 bin 73728 May 24 1988 /usr/ucb/pc tacitus% ls -l /usr/ucb/vi -rwxr-xr-x 6 root 147456 May 2 1989 /usr/ucb/vi Now guess which compiles faster - Turbo on a 4Mhz 8088, or pc on my 20Mhz 3/60? I haven't bothered (had the nerve?) to try the acid test; ie, which produces the fastest executable, but my money isn't on pc. WHY isn't size and performance a consideration in the UNIX workstation software market? I must admit that XWindows scares me a bit in this regard; I don't see how we can expect much in the way of a gain in performance over SunView, given the whole client/server orientation of the thing. Anyway, Mr. Johnson, if it's any consolation, there's two others in our office that feel the same way you and I do about this whole thing. I guess we don't constitute a groundswell of popular opinion, but maybe someone from Sun is listening. Chris Hermansen Timberline Forest Inventory Consultants Voice: 1 604 733 0731 302 - 958 West 8th Avenue FAX: 1 604 733 0634 Vancouver B.C. CANADA uunet!ubc-cs!van-bc!tacitus!clh V5Z 1E5 Disclaimer: This is the official opinion of the management.