Re: Enough grunt for v4r5? (and "Interactive Tax")

Matthias,

your post generated a lot of comment re the "interactive tax" and cfint on
"server models".
I know you were just asking about a s/w upgrade but I thought I should
respond to some of the generalities thrown around about interactive cpw's.

Whilst I don't like the "interactive tax" either, I think some of the
arguments re interactive CPW's are excessive and don't tell the full
picture. If you are looking at/needing an upgrade you should just consider
the cost from a business sense only and be more detailed in determining
your "real" interactive cpw requirements.

I can best illustrate some points by reference to our upgrade about two
years ago.

We had a model 600 (a non-server model) with CPW of 33 (i.e. 33/33)
Our interactive performance was generally good OK (occasionally worse when
batch heavy)
CPU utilisation was always over 70% and often in the high 90s
We were expecting big increases in future business volumes (100 to 200
users)

We updated to model 720 (server model) with CPW of 35/240 and doubled mem
to .75GB
This upgrade was relatively cheap (about US$30K at the time)

Our interactive performance was much faster (and consistent), our batch was
upto 15x faster
Our CPU utilisation averages <10% and still does with volumes up approx 3X
from before

So, if our interactive CPW stayed approx the same how come we got such a
big boost?

1. Recommendation for non-server interactive CPW is to position at 70%
(because of the perf/utiliz curve)
this means our original 33cpw should really be seen as 23 cpw. (even then,
queuing theory indicates a response time range of 1:3.33 (i.e. 1 + 70/30) .

2. How much of this is interactive? Our system is fairly normal, but we
estimated interactive utilisation was probably about 50% (there is a lot of
other batch activity other than batch application streams).
Therefore our real CPW requirement was 50% of 70% of 33 = 11.5cpw with
response time varying by 3:1approx

3. The model 720 cfint behaviour (compared to earlier server models) is
such that we get 35 cpws plus can still get the remainder for batch. Also,
the governor doesn't cut in until you are almost at the limit point
(previous implentation created the "curve" before the limit). However, _and
this is key_, the interactive RUNS at full cpw speed i.e. 240 (it is just
limited to 35 cpw in total i/a THRUPUT terms).   So it runs about 7x
faster, and because this m/c is 7 times faster than the 600 (240/33) our
total  average utilisation should be about 1/7. i.e. 70/7 = 10%. Which it
was. This also means (again with queuing theory) that our interactive
response is almost flat all the way to the max 35 cpws 1:1.17 (1 +
35/(240-35)).

So, 35 cpws actually represented a 3x interactive capability (35/11.5), 7x
response performance (240/35) and a more consistent response time (1:3.33
to 1:1.17 assuming we used all the i/a cpw)

This is not to forget batch. This just flew naturally. Batch times upto 15x
were often experienced (it was often greater than 7x because the 600 was
often running a fair way up the performance curve).

(p.s. I know some of the improvement was due to the memory increase too,
but we also increased our transactions significantly)

You all may come up with different figures in your situation, but paying
the "interactive tax" may not be as "expensive" as you think. Some users
refusing to upgrade because of the "unfairness" of the "interactive tax"
may be cutting off their nose to spite their face :-) -> :)

_______________________________________________________________

Regards,        Rod Orr



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---