avri@asherah.clearpoint.com (Avri Doria) (01/01/91)
I am looking for information which will help me choose between the Sun 4/4[7,9]0 and Sparc II as NFS servers. I want a 470, but I have someone telling me a Sparc II will work just a well. Is this true? Questions I am trying to answer are: How many NFS users can each support. Our configuration is as follows: each workstation, (both Sun and other) will have local boot, swap and utilities. All sources, however, will reside in the server. How many software developers can be served. How many diskless stations can be served by each? Is ther a reasonable metric which can be used to determine the ratio of diskless to nfs only workstations which can be served? Can a fully loaded server (i.e. maximum client population as defined above) still be used as a compute server (i.e. cross compilation). As a mail and news server? Has anybody done any benchmarks on this. And if so. how can I get a hold of descriptions and results? By the Way: There used to be (3 years ago, the last time I had sun equipment) a great phases of the moon tool. I could not find this in the archive. Was I blind? Is it there under another name? Does someone know where I can FTP one from? Again, thanks avri@asherah.clearpoint.com
tilman@ames.arc.nasa.gov (Tilman Spokert) (01/02/91)
In article <988@brchh104.bnr.ca> avri@asherah.clearpoint.com (Avri Doria) writes: >I am looking for information which will help me choose between the Sun >4/4[7,9]0 and Sparc II as NFS servers. I want a 470, but I have someone ... >Can a fully loaded server (i.e. maximum client population as defined >above) still be used as a compute server (i.e. cross compilation). As a >mail and news server? Don't do this. What gets easily overlooked is the fact that NFS is a set of user-level processes. So just one compile job would compete with NFS requests for system resources, like CPU, memory, IO, bringing down the overall server performance for the rest of the world! One more difference between a 470 and a SS II: The 470 uses ECC memory, so in theory is more reliable. On the other hand, I have rarely seen a SS-I reboot because of a memory parity problem (except if a SIMM was really bad, and had to be replaced). Tilman Sporkert, apple!netcom!tilman or tilman@netcom.uucp - I don't need a Nintendo. I got a SparcStation... -
deraadt@cpsc.ucalgary.ca (deraadt) (01/03/91)
In article <1002@brchh104.bnr.ca> netcom!tilman (Tilman Spokert): In article <988@brchh104.bnr.ca> avri@asherah.clearpoint.com (Avri Doria): >I am looking for information which will help me choose between the Sun >4/4[7,9]0 and Sparc II as NFS servers. I want a 470, but I have someone ... >Can a fully loaded server (i.e. maximum client population as defined >above) still be used as a compute server (i.e. cross compilation). As a >mail and news server? Don't do this. What gets easily overlooked is the fact that NFS is a set of user-level processes. So just one compile job would compete with NFS requests for system resources, like CPU, memory, IO, bringing down the overall server performance for the rest of the world! I'd agree, but for different (more technical?) reasons. My memory says the 4/4x0 has many more contexts in the MMU and caches. A Sun MMU is really just a big funny static ram. So, on every context switch, they would have to reload it for the new process. Same with the cache. To avoid this, they put multiple contexts in their MMU and change a little 3-6 bit value to pick which context. Then they roundrobin (or in some other way) timeslice the contexts in the MMU and cache. On a Sparcstation II, I think you get 16 contexts. On a sun4/4x0, I think thats 32? Anyways, I'm pretty sure the 4/4x0 has more. The result is that the mmu configs and caches have to be flushed less often, and as a result more work gets done. In general, as soon as you have as many simultaneously running processes as the number of contexts, you are going to see performance degradation. Now a question. Are current generation SCSI disks competitive in performance with SMD disks? Theo de Raadt deraadt@cpsc.ucalgary.ca
datri@convex.com (Anthony A. Datri) (01/03/91)
>Don't do this. What gets easily overlooked is the fact that NFS is a set >of user-level processes. The last I knew, nfsd just did a kernel call that doesn't return. The nfsd is really just there for accounting.