Conference koolit::vms_curriculum

You finally got the chapter numbers to say something other than "1"!

5-3, 4th bullet --
   Let's not list 'describe VAXcluster concepts' as an objective, it is a
   necessary evil because many either 1) don't know or 2) don't understand
   the details of VAXclusters.

5-4a, "materials:" --
   60 minutes??  Probably closer to 2 hours, especially if we expand the 
   lock section.

5-4 --
   add VAXcluster Quorum issues of May 1992 as well as Aug 1986 and May 1988
   that you listed on the previous page.  The May 1992 issue is EXCELLENT
   reading -- should be mandatory for all Cluster instructors (and students?)!

   also, lots of "<reference>" things throughout the chapter...

5-5 --
    Lots of other keywords needed here:  MSCP, MSCP server, SCS/SCA, etc.

5-7a, "This'll" --
    Nit -- I don't think this is a standard contraction.  No big deal for
    those of us that have English/American-English as a first language, but...

5-7 --
   5th bullet -- Considering the changes expected in VMS/OpenVMS and Alpha/VAX
   clusters, using "VMS" instead of VAX will be more accurate - today and 
   tomorrow

   I usually add Distributed Job Controller /Queue Manager as a last bullet.

5-8a --
   1st bullet, 7th dash -- "...or Q-bus, or BI-bus, or XMI-bus, or..."

   2nd bullet, where is DSSI mentioned?
  
   3rd bullet, although VAXcluster=2 is standard today, VAXcluster=1 will
     result in the same if the system detects Cluster HW, specifically CI
     the adapter. 

5-8 --
   I suggested long ago to drop this diagram.  It is needed in the VAXcluster
   course, but not here.  Besides, although it has been updated since I have
   last seen it, it is still out-of-date:

     Bottom left box ("UDA box"), where is KDM, RQDX3?

     Missing a box for DSSI controllers like KFMSA, KFQSA, SHAC, etc.

     Does the DECnet class driver always use SCS?  Diagram implies this.

   This is not a VAXcluster architecture course.  Performance managers don't
   need this detail.  Put it in an appendix if you really want to keep this.

5-9a, reference to VAX Notes conferences --
   Bravo!!  This is the type of instructor references that are really useful.
   Someplace I can go to do research and ask questions if I don't understand.
   We need more of this type of info!

5-9, 7th bullet --
   need reference to DSSI, especially KFQSA since it is the slowest.

   need to add a last bullet for "I/O channels" meaning controllers, HSCs,
   DSSI's, etc.

5-10a, add text --
   "Monitor Cluster should normally be the first command you use to begin
   the process of determining a performance bottleneck in a VAXcluster that
   can be attributed to an imbalance of resource usage.  There are other
   good commands, but this can provide a easy to understand 'display' of the 
   heaviest used systems in a cluster."  or something like this.

5-11a, add text --
   "In a large VAXcluster (many nodes), Monitor Cluster can take quite a while
    to start up because we must have an active DECnet link to each machine in
    the cluster.  Some system managers actually place an ACL against Monitor
    to keep non-priv'ed users from running monitor cluster."  or something
    similar.

5-11 --
   Last bullets don't mention how to read the lock data.

5-12, diagram --
   Major nit -- MONITOR CLUSTER only shows SIX lines per display, not seven
   as shown.  This is also wrong in every book that uses this same display
   (such as SysNet, VAXcluster Mgr., etc.)  Somebody edited the display and
   added BEAR to the bottom of each section (except the disks!).

5-13a, 2nd statement, "You might..."
   this is an understatement...and belongs on page 5-11a

5-13, new configuration --
   As stated somewhere in the SysNet reviews...please try and keep constant
   configurations throughout a course, but especially a chapter.  Students
   learn better if configurations are as constant as possible.  Notice the
   disk/node configuration changes on each page from 5-12 through 5-15, and
   twice on page 5-15!  Using different nodes from the Barnum-and-Bailey
   cluster we could see all these features and keep a consistent HW display.

   Mixing Allocation class and node-name prefixed device names will lead to 
   excessive discussions.

   Drop the DAD devices...useful, but not needed -- complicates diagrams.

5-17, 2nd bullet, 4th dash --
   "Not cluster accessible" -- supposedly already covered in the I/O module.
   "Dedicated to an application" -- Hey!  This is EXACTLY what to look for!
   
5-18a, last line --
   add DECps to this list of products.  It actually lets you pick 'n' number
   of hot files.

5-18, 2nd bullet --
   All of these should have been mentioned in the I/O module.  The Page
   Files and the DECnet directory need to be addressed here because in
   a cluster there can be a DECnet directory for each node!  Also, page
   files are 'expected' on the system disk, we need to make sure they
   get moved off the system disk onto other, properly balanced, disks in 
   the cluster.  All else is standard I/O tuning that should occur outside
   of the cluster environment -- here for review.
    
       3rd bullet --
   Drop device names, just say "Use fast disks.  Favor multiple, medium-speed
   disks over single faster disks."  Or something like this.  RA82 isn't 'fast'
   today, and disk arrays are the up and coming thing!

5-19a, last line -- 
   MSCP_BUFFER stuck on the end of the line!  Is it supposed to be a bullet?

5-19, "MSCP_CREDITS"
   No reference to MSCP_CREDITS?  This is often needed on a LAVC or MI cluster
   that has a lot of satellites.  The boot server runs out of MSCP_CREDITS and
   satellites can sometime spend a lot of time in RWSCS as a result of this.
   VPA has a nice little write-up on this.

5-20a --
   Mention what should be looked at on the MSCP display.  Personally, this
   is one of my least favorite displays.  AUTOGEN takes pretty good care of
   this.

5-21a, first line --
   This is mentioned backwards!  These are not the 'recommended devices', these
   are merely possible upgrade paths to get systems off of DEQNAs, DEUNAs and
   DEBNTs.  List these as the one to AVOID.  DEMNA and DEMNI are much better
   that those listed and the DESVA doesn't upgrade anything.

5-21, 2nd bullet, 1st dash --
   "but cannot be distinguished..." -- sure it can.  SPM has a PC collector
   that can isolate modules used, modes used, etc.  VPA can't help much 
   here and I don't know about DECps.

       3rd bullet, add "-- Fastest disks"

       last line -- may be news to some instructors.  See May 1992 Quorum for
   some of the details.

5-22a --
   2nd line, "(RA81 and RA60)" needs to say "RA81 and RA60 attached to Bailey
   and Barnum" since Horse and Bear have RA81s as well.

   Last line, need a reference other than 5.4 Tech Update seminar, something
   I can point my customers to!  Quorum might be possible, Release Notes
   probably better.

5-22, diagram --

   Upgrade this diagram to use DSSI bus between Horse and Bear like the 
   VAXcluster course uses.  This is more relevant today than dual-ported
   disks.


More later...

$       

    Chapter 5 has been posted for review:
    
    SUPER::$1$DUA6:[ES$REVIEW.VMS_PERFORMANCE_V55]VMS_PERF_5_CLUSTERS.PS
    
    

  Continuing...

5-23 --
     There is a piece of Sales literature called "VAXserver Performance
     Advisory -- Choosing a Local Area VAXcluster Disk Server" which has
     updated tables.  Mine is dated July 1990, maybe someone has a more
     current copy.

5-24, 4th line --
     This short line on CI ports seems out of place on this page.

5-25, 6th bullet --
     reference to LTLOAD needs to be updated to the LAT$.... stuff.

5-26a, 1st paragraph, 2nd sentence --
     EXACTLY!  So let's take out 5-26!  Rather useless display, save it for
     the VAXcluster Mgt class.

       2nd paragraph from bottom --
     Not true.  2-3 9000s can saturate the CI.  Not tough.  (Not likely)

5-28a --
     V5.2 and V5.4 are mentioned.  V5.5 has a LOT of stuff with locks.  See
     May 92 Quorum.

5-29, ACP_REBLDSYSD --
     Need to mention that the system disk rebuild is controlled by SYSGEN
     parameter, not MOUNT.

5-30a, last line --
     Please reference VMS material, *not* courses that the students (and the
     instructor) may not have access to!

5-30, 1st bullet --
     add "...dependent on model of VAX hardware."  Some CPU's cannot have
     multiple CIs.  6000 and 9000 can have many.  

      6th bullet --
     Weird.  Subtitle of the page is "Multiple CI Ports" and the 6th bullet,
     under "Other Goals and Benefits" read -- "Support multiple CI pathways."
     Kinda like saying "the reason we have two cars is so we can drive 2 cars."

5-31 -- kill it.  5-30 covered all the average system manager needs to know.
     this is configuration stuff that needs to be in the VAXcluster Mgt 
     class, not here.  Nothing related to performance that a system manager
     needs to do.

     1st bullet doesn't need "(VC)", its never used again.
 
     4th bullet needs to be rewritten in English.

5-32a --
     Add May 92 Quorum as Reference

5-32 -- lock mgt stuff belongs immediately after state transition.  Last
     bullet on page 5-28 is a natural lead-in to this discussion.  Put the
     CI-port sharing stuff someplace else other than where it is.

5-33 --
     Last line leaves it hanging.  Something needs to 'wrap it up' like:
     "Therefore, database applications may be among the heaviest users of
      locks (possibly causing lengthy state transitions)."  Or some other
      'conclusion'.

5-34 --
     This discussion is OK, but we don't tell the system manager how to
     'tune' it.  Tinkering with DEADLOCK_WAIT has been somewhat successful
     for me.  Raising it when Deadlock Search rate was higher that deadlock 
     find rate often save me a marginal amount of CPU time.  Overall, I'd
     be happy to drop this page.

5-35 -- 
     This stuff should follow 5-32.  What are Locks?  How do they work?
     What are Resources?  How do we gain access to them?  Then the granularity
     stuff.

More later....

$

Wrapping up chapter 5...

5-26, diagram --
    This diagram is misleading.  The arrows leaving the Namespace going towards
    the Resource leads you to believe that the Lock Manager accessed the
    resource for the process.  This is not true.  The lock manager merely 
    grants permission, the processes then have to issue the appropriate
    call to the device SEPARATE from the ENQ request.  A send arrow leaving 
    the Process A and B bubbles going around the Namespace an Lock Manager
    and  pointing to the Resource would be more accurate!

5-37 -- 
     The cross-reference table that was removed really helped explain the
     text in the comment field of this display.  Try figuring it out without
     a picture if you are just learning about locks.

5-38 -- 
     Like Dead-locks, this is an issue that system managers don't have much
     to work with or to influence.  I'd suggest dropping it.  It is a very
     valid topic, but more suited for programmers.

5-40, 4th bullet --
     The Lock ID Table is stored in CONTIGUOUS non-paged pool.  This is an
     issue when the table must be expanded.  It requires that a LARGER space
     of non-paged pool be allocated and the Lock ID Table copied to it.  This
     can lead to the classic "Quota Exceeded" error if insufficient Non-paged
     Pool is available.  The Lock ID Table can't be copied and the process
     will give a "Quota Exceeded" error.  Very common with certain applications
     like VAX Notes and ALL-IN-1.

5-42a --
     Need a reference.  Maybe in the Release Notes??

5-43a --
     Good comments, but belongs back near DEAD_LOCK discussion.  We need a tip
     as to what to say about page 5-43.  

5-43 --
     I find this page rather useless.  Any suggestions as what to say?  This
     is a terrible way to end the chapter!  Put this in an appendix or remove
     it so I can finish with the regular locking topic.


$

  Only one real issue with chapter 5, the diagram on 5-21 really needs
  updating or move it to an appendix or instructor's page.
  
  $