> From: Eric Thomas <ERIC@FRECP11>
> However you should note that:
>
> - VM spool is not driven by a single virtual machine, but by CP.
This appears to be a language misunderstanding. Let me rephrase
what I was trying to say: I ran a controlled test during test
time. Only RSCS was running. Therefore, for my case, you could
consider the spool to be driven only by the RSCS machine, i.e.
only RSCS supplied load to the spool. I know that in fact, there
is other software between, but for the level of performance
analysis we were talking about, this isn't relevant.
Of course this test environment was a simplification of the usual
situation, but, as I pointed out, the situation only gets worse
under load, so this is, in some way, the best that VM/RSCS can do.
> Spool I/O are, however, synchronous,
It's worth pointing out that this is only true in non-XA VM.
> and RSCS will therefore be 'held' until the spool I/O is complete.
> I've always said that RSCS ought to do its own private spooling.
The idea of RSCS doing it's own spooling may have merit on other
grounds (I'm not convinced, but I'll listen - private mail,
please), but it cannot be justified on the performance issue
alone. The performance problem is in CP. It should be fixed in
CP. Then it will be fixed for all users and all DVMs. Other
solutions are kludges.
> - Throughput is much better under MVS mainly because of
> the XA architecture, which (for example) allows a CCW to be
> processed by some subchannel and the next one by another
> subchannel, if the first one happens to be busy. This is
> another explanation of why I/O can degrade considerably under
> S/370 when the I/O subsystem is heavily loaded.
This, while true, has almost nothing to do with the situation at
hand. My benchmark system was non-XA (although I didn't point
this out in the posting) and uncontaminated by other work.
The major performance differences between the MVS and the VM
systems came from the application level (JES double buffering,
trackcelling, etc), and not from the dispatching of I/O into the
I/O subsystem of each system.
You are correct that the entire I/O subsystem degrades much more
gracefully under XA than non-XA. However, I wasn't even
considering that issue, because it is a second order effect.
> - The RSCSV1 DMTVMC line driver is MUCH more efficient than
> DMTNJI/NJE.
These comments are basically correct and contain no surprises (at
least for those of us who have studied the situation). There are
some tuning things that can be done, but they help only a little
bit. It does appear to be a surprise to the designers. It makes
me wonder what the designers had in mind when they eliminated the
VMC protocol from R2.
> Eric
Michael
|