howell@MITRE.arpa (10/28/86)
Acknowledging in advance that the answer in large part depends on the applications being run (which I'm NOT telling you, just to make this more of a challenge...): At what point does adding memory to a Sun3/75 reach the point of sharply diminishing returns? We have fast disks on our file servers (Eagles), and four meg on our 3/75's. It seems pretty clear that swapping is sharply reduced in going from two meg to four; is there much gained by going to eight, or even sixteen? What about servers? Is there much to be gained by beefing up server memory to eight or sixteen meg? Thanks in advance, Chuck Howell howell@mitre.arpa
ehrhart@sri-spam.arpa (Tim Ehrhart) (10/28/86)
>Chuck Howell <howell@mitre.arpa> writes: >At what point does adding memory to a Sun3/75 reach the point of >sharply diminishing returns? We have fast disks on our file servers >(Eagles), and four meg on our 3/75's. It seems pretty clear that swapping >is sharply reduced in going from two meg to four; is there much gained >by going to eight, or even sixteen? What about servers? Is there >much to be gained by beefing up server memory to eight or sixteen meg? My personal experience with Sun-2's running 2.x or 3.x or Sun-3's running 3.x on various file server configuration have shown me that they (file servers) are not memory bound. Our file servers usually don't even have Sun consoles on them so they never run suntools. That makes a tremendous difference to file server performance. For the rest, a file server typically runs a much smaller subset of programs (i.e. nfs stuff, network daemons) than a normal client (i.e. editors, graphix, databases, AI development). We also discourage "logging-in" to the file server to minimize character based I/O interrupt handling. Why not ? Everything is accessible over NFS. Don't have much experience with 8MB Sun-3/75 as diskless clients. Just got one, but I recommend throwing memory at clients instead for file servers. Take a good look at your file server using vmstat and you'll be suprised. Here's how we configure 'em: Hardware OS MB # clients Disks Sun-2/170 2.3 2 ~12-17 451, 2 Eagles (~760 MB) Sun-3/180 3.0 4 ~10-12 451, 2 Super Eagles (~1.1 GB) Tim Ehrhart, SRI International, Menlo Park, CA 94025
obrien%pluto@RAND-UNIX.arpa (10/29/86)
Judging from our experience here, I would say that you gain quite a bit in speed by going from 4 to 8 Meg on a 3/75. We find that a "normal" Suntools environment, for us, (consisting of about 6 or 7 windows) causes the 3/75 to page madly just running the Sun utilities, let alone any substantial application code. Going from 4 to 8 Meg seems to let us keep a real working set in physical memory. I would not recommend less than 8 Meg for any workstation. If the file server is also used as a workstation the same applies. However, we do not see much performance degradation in a 4 Meg server over an 8 Meg server, so long as no one logs in. I personally am less certain of this result, however, since we haven't actually tried to measure it. The performance improvement in 8 Meg over 4 Meg in a workstation, however, is immediate and dramatic. This is, of course, for systems running 3.0. The way Sun software grows (and grows and grows and...), all bets are off with the next major release.
dm%bfly-vax.bbn-unix.arpa@BRL.ARPA (11/01/86)
4 megs seems to suffice on a SUN workstation if you use the X window system instead of Suntools. Not as snazzy a user interface, but a definite improvement in performance.
roy@phri.UUCP (Roy Smith) (11/01/86)
In article <4975@brl-smoke.ARPA> obrien%pluto@RAND-UNIX.arpa writes: > We find that a "normal" Suntools environment, for us, (consisting of > about 6 or 7 windows) causes the 3/75 to page madly just running the Sun > utilities, let alone any substantial application code. [...] I would not > recommend less than 8 Meg for any workstation. [and in a follow-up article, he clams the same is true for a 3/50, since 4 Meg is all you can ever put on that machine] We've got 12 3/50's here and I havn't seen the memory thrashing described above. My .suntools sets up 3 perfmeters (local, and keeping an eye on our 2 file servers), a clocktool (w/ second hand), an rlogin to our vax, a console, a mailtool, and 3 shelltools (2 iconic). Typically I've got an emacs running in one window with some sort of big troff or make in another. With the clock and perfmeters waking up every second or two, that keeps the machine pretty busy. I don't notice any wild paging going on, and almost never any swapping. I suppose it all depends on what kind of jobs you're running. Add to that mix some horrible lisp thing and a 1k x 1k matrix multiply and I would imagine you'll see some vm activity pretty fast. When we started negotiating the purchase of our systems, the 3/50 hadn't been announced yet and we were looking at the 3/75. Since we had been running as many as a dozen users on our 4 Meg vax without problems, I couldn't believe you would want 4 Meg in a personal workstation and decided to save some money by buying the 3/75-2 (i.e. 2 Meg). (To this day, some part of me is still living in the days when we ran 24 users on a 96k 11/45 with a 20k v6 kernel; now we run 1 Meg 4.2 kernels.) I was rather annoyed when our salesman tried very hard to talk us out of it, and surprised (and even more annoyed) when he claimed that they didn't even make the 3/75-2's in their catalog. Talking further with some high-level technical people at Sun convinced me they were right. "So, if you won't sell me a 2 Meg system, why do you have them in your catalog at all?", I asked. The answer basicly turned out that in order to meet bidding requirements on certain sales, they needed to be able to present a system with a lower price tag than the 3/75-4. It was around that time that I was getting fed up with Sun (I don't think the Sequent people realize just how close they came to making a sale then) but the announcement of the 3/50 sold me. Now we have our 4 Meg systems, and we're happy. And I *still* think 2 Meg would have been plenty! 1/2 :-) -- Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
jdb@mordor.ARPA (John Bruner) (11/04/86)
I've come up with the following formula to compute minimum memory size for a Sun release: minimum_memory_size = 1 << (19+sun_release_number); Thus, my Sun 3/75 comfortably runs Sun release 3.1 with 4Mb. This includes Suntools (or X -- I've used both), several simultaneous shells, rlogins, etc. Our Sun 2's run release 2.0 happily with 2Mb. My workload is shells, rlogins, editors, compilers, etc. (People here who run large computations require more memory. Some users are complaining that 16Mb on a 3/180 isn't enough.) -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
stern@princeton.UUCP (11/06/86)
I can't resist:
We're in the process of putting 1 Gbyte (yes, 1 Gbyte) of RAM on
a Sun-3/180. If it pages, we'll let ya'll know.
--Hal Stern
The Massive Memory Machine Project
Princeton University
{ihnp4, allegra, seismo}!princeton!stern