Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!comp.vuw.ac.nz!dsiramd!ray From: ray@dsiramd.dsir.govt.nz (Ray Brownrigg) Newsgroups: comp.arch Subject: Re: Multiuser benchmarks (long summary) Message-ID: <381@dsiramd.dsir.govt.nz> Date: 6 Jul 89 03:15:45 GMT References: <377@dsiramd.dsir.govt.nz> Reply-To: ray@dsiramd.dsir.govt.nz (Ray Brownrigg) Organization: DSIR Applied Mathematics Division, Wellington, NZ Lines: 120 Summary of responses to my posting regarding multi-user benchmarks, and the feasibility of replacing some of the services offered by a VMS-based MicroVAX II with (say) a SPARCstation 1 running (say) 6 simultaneous users at peak load. I have retained the authors words, just edited out repeated or less important information. ------ From: chris@yarra.oz MUSBUS is a UNIX benchmark - no way to run it under VMS. Same is with AIM to my knowledge but I have no practical experience with it. ... AIM 2 has several fundamental flaws ... AIM 3 is much better. ... MUSBUS is in public domain and you can easily obtain the source code to run it yourself. You can also easily customise it in the sense of changing your job mix to reflect your real expected load. ... The benchmark is also a good tool for shaking and checking quality of UNIX ports. You just increase and increase load and wait when it breaks. Some architectures and UNIX ports are known to break supprisingly easy above 64 simulated users. By the way to really test a machine you should run the benchmark way past the saturation ankle on CPU utilization and elapsed time degradation curves. I suggest that you run it up to the number of simulated users yielding elapsed time degradation value of at least 2.5. ... Many a hardare vendor will only publish results on the linear section of the curves which is pretty much useless for the purpose of assessing where the machine saturates and how severely. Chris Jankowski chris@yarra.oz chris@yarra.oz.au Pyramid Technology Australia - Melbourne ------ From: khb@Sun.COM Personally I think MUSBUS and AIM are nice but misguided. ... No one in their right mind buys a DS3100 or a SS-1 as a multiuser machine. Neither has the IO bandwidth, or any of the other goodies that dominate in real multiuser designs. But then I think of the Convex C120 as an adequate single user machine. ... The old mainframes had 1MIPS of CPU power, but could handle 100 users. The fact that there were dozens of minicomputer class machines (PP's, channel controllers, etc) made this "magic possible". A workstation is designed (primarily) to handle a single person quite well. DS3100 and SS-1 rely on SCSI IO. SS-1 has a buss, so it is theorectically possible to have more suitable IO for a server, but it seems unlikely that an IPI device will be made available:> The better solution is to buy a machine designed to be a server. VMS is more efficient about sharing resources than unix. ... ... Single user machines are optimized to handle a few context switches quite fast. Serious multiuser machines face 100's or 1000's of context switches a second ... hence different MMU designs are called for (among other considerations, like IO). ... Keith H. Bierman Marketing Technical Specialist ! kbierman@sun.com ------ From: rnovak@mips.com ... AIM and Neal Nelson are proprietary benchmarks. You typically have to pay large fees to see results from these benchmarks (or whisper in your salesman's ear). MUSBUS is probably the best, but I haven't had a chance to run that on the M/120 yet. ... Keep your ear to the ground about SPEC. Robert E. Novak MIPS Computer Systems, Inc. ------ From: mash@mips.com ... If you look at MIPS Magazine over the last few months, here is some (albeit not great) data on mulit-user performance. ALso, UNIX Review magazine's Tested Mettle reports include multi-user, and so do Digital Reviews. Note that the SS1 is 12 Dhrystone-mips, not VUPS. It's more like 9 VUPS. In the past, execution of kernel code is not something that Sun-4s have excelled at, due to a) use of virtually-tagged caches that needto be flushed more often than you'd like. b) register windows not matching the way the kernel works, and (minor) c) cost of saving large register file. john mashey mash@mips.com ------ As a rejoinder, and perhaps to elicit further comment, we are proposing to provide the RISC workstation as a *supplementary* service to the MVII, primarily for heavy CPU users (the MVII is charged for on a CPU-second basis). Given that in the first instance access to the workstation will be through ASCII terminals (perhaps some TEK4014 emulators) over ethernet (a TCP/IP capable terminal server), I suggest that the total cpu load may be not too much more than a single intensive user can apply using multiple active windows. If this is the case then the problem boils down to one of context switching - a single user cannot be typing into several windows at any one time. Analyzing the situation though, 6 users all typing together would result in a peak in the order of 50 (?) context switches per second, surely within the capability of a 12-16 (integer) MIPS processor? -- Ray Brownrigg domain: ray@dsiramd.dsir.govt.nz Applied Maths Div, DSIR ACSnet: ray@dsiramd.nz[@munnari] PO Box 1335 System: OLIVETTI/AT&T 3B2/400B+, System V R3.0 Wellington, New Zealand "unx -rules -OK"