Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.benchmarks
Subject: Re: How do maxed out users compare to users with think times
Message-ID: <4046@sixhub.UUCP>
Date: 13 Jun 91 02:29:30 GMT
References: <676640053.AA19240@flaccid>
Reply-To: davidsen@sixhub.UUCP (bill davidsen)
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 61

In article <676640053.AA19240@flaccid> tonys@pyra.co.uk (Tony Shaughnessy) writes:

| How do I calculate how many real life users these 100 maxed out users simulate?

  Answer 1, you probably can't make any nice transformation, you have to
add delay times to the input stream and feed it with another system
through multiple serial or socket connections. Anything else will simply
be a guess, pick a number from 1.5 to ten and you'll be right sometime.
See below.

| In real life, the load on the system will be 
| some function of think time (smaller think times - larger load) and 
| the response time (larger response time could be either the cause or 
| the effect of larger load, or both). However, with my maxed out users, the
| load is independent of the response time as a cause, although larger response
| times will be an effect of a larger load. This assumes that load is defined
| as percentage of CPU utilisation. Maybe I should be looking at other
| definitions of load? See below.

  You have two times, not one. One is think time, used to decide what to
type. The other is type time, varies with the typist *and* the
information. The average user types his/her password and userid faster
than anything else they enter.

  Now, the think time (time 1) depends on what's being asked (obvious)
and system response (ah-ha!). That is, when response time gets worse
than about 200ms attention slips a hair. If your load shows that
response is above 1 sec, add 1-2 sec to think time, and after 10-15 sec
the mind drops completely out of gear. Thus, as your load increases all
of a sudden your productivity totally goes to hell.

  This isn't my opinion, IBM did a very serious study of this issue back
in the late 70's, and since neither humans nor seconds have changed much
I bet it's still valid (and no I can't find it any more, we used it for
sizing for a while).

  The plot of operator response vs system response is a step function,
with the last step looking somewhat like a pie falling off a table.

| I am going to go away and think hard about this one. My mind is in turmoil.

Justly so! Doing a good simulation requires the key fake routine to know
how long it is between the last ENTER and the next time the system is
ready for input. Then the time1 factor is adjusted to be realistic.

The important thing here is that you have realized there is a problem.
I have spent hours trying to get management to admit that poor response
hurts productivity by far more than the dialation factor in response.
However, the other side of the coin is that when response is already
bad, you don't lose as much if it gets worse, since everyone is running
in full context switch mode anyway.

  Now you can either simulate it, or estimate it, but at least you know
you're faking it if you estimate, and your estimates are going to be
pessimistic and more accurate.

-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me