Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ncr-sd.UUCP Path: utzoo!watmath!clyde!cbosgd!ncr-sd!stubbs From: stubbs@ncr-sd.UUCP (Jan Stubbs) Newsgroups: net.arch,net.unix-wizards Subject: Re: IOCALL results and problems Message-ID: <380@ncr-sd.UUCP> Date: Thu, 2-Jan-86 15:15:38 EST Article-I.D.: ncr-sd.380 Posted: Thu Jan 2 15:15:38 1986 Date-Received: Fri, 3-Jan-86 02:03:27 EST Reply-To: stubbs@ncr-sd.UUCP (0000-Jan Stubbs) Followup-To: net.arch Distribution: net Organization: NCR Corporation, San Diego Lines: 35 Keywords: IOCALL, Multiuser Xref: watmath net.arch:2371 net.unix-wizards:16283 Summary: Multiuser benchmark In article <1035@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: > There are easier ways to measure the time to do a context >switch. If you want to measure multi-user response, you've GOT to open the >IO can-of-worms, since they WILL be doing IO. How about the following as a multiuser benchmark? iocall& dhrystone& iocall& dhrystone& etc..... Putting the above in a shell file and getting stop watch times on a dedicated system gives a reasonable approximation of a real system workload. If you want physical IO in there as well, add a few cc hello.c&. If you want to simulate user think time, add a sleep between programs. Vary the mix of these programs to simulate your prospective use of the machine. If you really want to get fancy, have one shell file for each simulated user and measure response time degradation as you add simulated users. IOCALL and thecc invocations would have to be modified to use unique file names or they will write on top of each other. We have done this with some success, the problem is getting any two performance people to agree on what is an appropriate mix. The AIM benchmarks from AIM Technology (Santa Clara, CA.) attempt to do this sort of thing but more comprehensively, for a price and they provide results for many machines as well. The above opinions are those of the author only. Jan Stubbs Jan Stubbs