> 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