Conference koolit::vms_curriculum

    I am starting to work on chapter 3.  My first question is why is this
    section on ASSESSING RAW MACHINE SPEED included in the chapter.
    
    Could it be moved to the end of this chapter or better yet how about
    removing it?  It needs to be updated if it is retained.  
    
    Emmalee

    I think a brief description and comparison of VUPs, MIPS and SPECmarks
    will be beneficial but it can go in an Appendix.  Most students I get
    seem confused by the different terms, so we shouldn't remove this
    completely.  
    
    A cross section of CPUs and SPECmark ratings might be useful, but it
    can never be uptodate.  I use the Relative Performance Chart in the 
    latest copy of CPU Upgrade to field the inevitable "How powerful is 
    my VAX ?" questions.
    
    As you're starting on Chapter 3, can I suggest the section on Vector
    Processing gets binned? Or, at least, put it in an Appendix!
    
    

Emmalee,

About the part op accessing raw machine speed the next.

Delete the tabel about the VAX types and their relative speed.

Extend a little bit more about how performance is measured.

explain the next:

MIPS,
FLOP,
VUPS,
SPECmarks.
etc. etc.

explain that there are routine to measure such things.
e.g. Benchmarks --> Drystones  etc.
If possible include an example of such a routine.
(I have seen one in the performance notes conference) 

I always spend about 5-10 minutes on these two pages, not more.
If you leave it out, ok, but I will still add this kind of info myself,
because i think it is a nice introduction to CPU's

Put the vector pages in an appendix.

Extend a bit more on the processor states:
- What do the mean, 
- What can the possible course of the state
- Is it the application or a process or system limit that will generate it.
 
Regards,

Piet Hompus
Educational services.
Nieuwegein
Holland.

Thanks for the comments on chapter 3.  I will leave the Accessing Raw Machine
Speed discussion in the chapter.  How about having it at the end?

The table I will put in an appendix.  We are going to have a hard time keeping
it updated.


I am waiting from word from Bill and Andy about the vector processing stuff. 

Next chapters to get worked will be 1 and 4.  Get your comments in quick.

emmalee

Re: .2

>    As you're starting on Chapter 3, can I suggest the section on Vector
>    Processing gets binned? Or, at least, put it in an Appendix!
>    

Rationale?

Other views?

Andy

    
    
    Leave it where it is, please.  
    
        GJD

    Re .6 and .2
    
    The reason I suggest that the Vector Processing pages are removed, or
    at least taken out of the main stream, is that (as far as I am aware)
    not one customer in the UK has VP capability on a VAX.  Also none of my 
    students has ever showed any interest in the topic. 
    
    
    Geoff

>    
>    
>    Leave it where it is, please.  
>    


Leave what where it is?  I believe we were discussing two topics:

	vector processing
	assessing raw machine power

Now starting chapter 4.  Comments please!

emmalee

    
    
    Sorry!  I suggest leaving the vector processing as it is.
    
    GJD

    CHAPTER 3 has been posted for review.
    
    SUPER::$1$DU6:[ES$REVIEW.VMS_PERFORMANCE_V55]VMS_PERF_C_CPU.PS
    
    Comments must be received by May 22 in order to be considered for the
    pilot edition of the course.
    
    Please post your review comments to this note.
    
    At the present time vector processing is in the chapter, assessing raw
    machine speed in the appendix.  Either can be easily changed.
    
    The table 1-2 has two question marks.  These will be completed before
    the course is delivered.
    
    One figure as noted on the instructor page has not been updated.  I
    believe the instructions are adequate to follow the discussion.
    
    

    Can you open up the protection on the file, please Emmalee?

    (The file should be VMS_PERF_3_CPU.PS ?)
                                 ^

    	Thanks,

    	Geoff

  You'll need to give us more than 3 days to review this chapter.  The file
  protection has not been fixed and we can't get a copy of this module.

  As for the Assessing part, it's been in there for a long time, at least
  6-7 years.  When there were only 5-6 CPUs it was easy to maintain and 
  rather brief.  I worked with Hallyburton and Claborn from the VMS
  performance group about 3-4 years ago to get it updated to show the
  ranges in the late 8000/early 6000 days.  Since then the CPUs just show
  up too quickly.  I'd suggest keeping the table in the appendix since it
  has the old CPUs and supplement it with the VAX sales literature (which 
  only lists currently selling CPUs).

  Yes, something on MIPS, VUPS, SPECS, MFLOPS, etc. needs to be introduced
  early since it sets the 'tone' for understanding that CPUs can only go so
  fast and that a very valid (although expensive) option is to upgrade to 
  the next CPU size.

  As for VECTORS, most of the stuff in there is Programmer stuff, my
  customers listen to the info, but only once or twice have any of them
  owned a Vector.  Yes, tell us what it is, how it can improve performance,
  but put the gory stuff elsewhere -- an overview in the lecture and
  details in an appendix.  

  $

Protection has been fixed.  Sorry about that.

Yes you are right it should be:

	VMS_perf_3_cpu.ps

Page 1-7   "The scheduler decides how log a program is to occupy the CPU"

	This statement is not really true... strictly spoken the scheduler
	only selects the NEXT process to execute...

	... all other actions, like quantum-end-processing, turning procs
	into wait-states, etc... are NOT done by the scheduler. These
	are in the responsibilty of RSE (Report-System-Events), the HW- and
	SW-clock interrupt service routines, etc...

	... in most cases it will the scheduler taking the procs OUT of
	execution, but the DECISION to do so is made by other routines.

1-19a.	"A process prio is NOT decremented under certain circumstances"

	Really ??? Which circumstances ???  Never heard... also couldn't 
	find an explanation for this statement in the IDSM.

	Or do you mean "... is not boosted if the process is already in the
	real-time-range or would get into the real-time range after the
	boost has been applied..."

1-34	"RMS record locking is done in Kernel mode"

	- correct !  more correct: ALL LOCK MANAGER ACTIVITY is taking
	  place in Kernel mode on a single node cluster. If more than
	  one node participates in the cluster parts of LOCK manager
	  activity also run on the interrupt stack...

1-35	"EXECutive Mode"

	one more point:  Most of Rdb's processing  runs in EXEC mode.

1-39
	" Use CPU limit if desired"

	I have never ever seen anybody really using it.  I know it is there -
	somebody coould use it...  but:  It aborts your job - and this is
	NOT something you would want ...  what is really missing in the 
	VMS scheduling algorythms:  A switch, which allows you to give 
	only a certain PERCENTAGE of the available CPU-time...

1-47	"CPU Sharing... last bullet:
	
	Typo:  "for processes normal processes"...

I agree with .-*, that the table for relative CPU-speed should go into the
appendix,,,  but being update first... ! VAX-4000/200/300/400/500/600 and 
VAX-6000/500/600  ARE the most important VMS systems we are selling today !

Any chance of collecting data on a industry-standard benchmark, like SPECmarks
at least for all types of NEW CPU's we have ???

Best regards,
	
	Hermann

Here are my thoughts and comments on the CPU module.

A couple of points overlap with those from Hermann (in .-1), but I've left them
in anyway.

Page 3:		replace "control of the CPU" with "use of the CPU"

		Objectives: 3rd bullet: "Interrup" should be "Interrupt"

Page 4: 	Remove section headed "TIME"

Page 5:		access mode: 2nd line: add "s" to "location"

		compute-bound process:
		delete "A process which does little I/O."  [A normal
		interactive process spending most of its time in LEF fits
		this description!]

		replace it with:
		"A process that spends a considerable amount of time using
		  the CPU."  [This matches your I/O-bound description lower
		down the page.]
	
		context switch: end of 4th line:  
		"the loads" should be "then loads".

		dormant process: "computeable" should be "computable".
		delete "a number of seconds".
		"DORMANWAIT" should be "DORMANTWAIT".

		mutex: "give" should be "given".

Page 7:		delete the 2nd bullet line [see Hermann's comments in .-1]

		Time Slice: 3rd line from bottom: replace the line with:
		"It is preempted by a software or hardware interrupt"
		[A process is preempted, not the CPU]

Page 9:		add "until quantum end," between "execute" and "unless"

Page 10:	3rd bullet: "log in" should be "login".
		4th bullet: replace "to which it is submitted" with
			            "which creates it."
		5th bullet: "32" should be "31" [ 2 occurences]

Page 11:	2nd bullet: "Computable" shouldn't be in Italics.

Page 12:	I've always thought of COM as an Involuntary wait state.
		Add it to the list ??

		Process Behavior: "Process are" should be "Processes are".
		last line: add ":" after "Example".

Page 14:	3rd bullet: delete "flag or".

Page 17:	Mark those 6 RWxxx states that are not used.
		[Page 284 of the IDS]
		[I don't have access to source listings at the moment, can 
		someone else check the SNAPSHOT and MAX entries? Or perhaps
		they should be removed from the table?]


Page 18:	2nd bullet: 4th "-":  delete this line!  Both the PIXSCAN
		algorithm and owning a MUTEX can take a process's current
		priority way above base + 6.

		5th "-":  change "priority" to "base priority".

Page 19a: [Re Hermann's comment in .-1 : The only circumstance I can think of
is if the current priority is at the process's base value.]

Page 19:	1st bullet:  change "priority" to "current priority".

		7th line:  delete "of ".

Page 20:	Any possibilty of bringing all the displays uptodate?
		It might seem trivial, but it's the sort of thing that students
		tend to notice and comment on. "It shows how long ago this book 
		was updated!" is a fairly frequent comment, on various courses.
		Let's make them all 1992 and VMS 5.5 !

Page 23:	Quantum-end routine: 4th "-":  add "of current process"
		between "priority" and "to".
		5th "-": change to "Decrements current priority of selected
		process by one toward base"

		2nd line from bottom of page: "never" should be "rarely"
		["never" is a very long time!]

Page 25:	insert ". " before "This section ".

Page 26: 	Update display?
Page 27:    	Update display?
Page 28: 	Update display?
Page 29: 	Update display?

Page 31:	2nd bullet: remove "Hardware"

Page 32:	Remove "Hardware" from the heading.
		Remove "HW" from the top of the IPL column.
                IPLs are split between Hardware and Software ranges, so the
		diagram should have a line drawn at the 15/16 boundary like 
		on the SW priority column. [Ref IDS pages 41 and 56.]
		
Page 36: 	Update display?
Page 37: 	Update display?

Page 38:	"," needed after "however"

PAge 39:	2nd bullet: 2nd "-":  empty line?

		6th "-":  Wasn't "VIA" replaced by "DECtp" 3-4 years ago?

		2nd line from bottom of page: [re Hermann's comments in .-1:
		I always strongly suggest to students they should use /CPUMAX
		on development batch queues. Programs under development have
		been known to loop occasionally!]

Page 40:	5th bullet: end of 1st line: "increase" should be "decrease"
		[ie: reducing response time gives a faster response]

Page 41-46:	Move to an appendix [see earlier replies in this note]

Page 47:	delete the 6th bullet line. Even without the typo, it's not
		right.

Page 49:	3rd line: "Useage" should be "Usage"
		4th bullet:  "times" should be "time"
			     "the ear" should be "each"    [ear???]

Page 50:	Overview: 3rd line: how about "comparing the speed of different
		machines" instead of "machine speed"   ?

		last line: "Machin" needs an "e"

Page 52:	Update this table and add descriptions of VUPs, SPECmarks, etc.
		[see previous replies to this note]



Phew!!  

Hope all this helps you Emmalee!


Regards,

Geoff

  Doesn't seem to be any major 'shuffling' in this chapter so far (I've
  only  reached page 23 so far) but that is fine as I found the old CPU
  module relatively easy to teach from and reasonably organized until the
  end.  I'll try not to duplicate entries by Geoff and others, I agree (or
  at worst don't disagree) with their change.

(lots of "<REFERENCE>(mumble-mumble)" thingies I figure you will find on your 
 own so I didn't list them.)

1-4 --
    60 minutes???  Nope.  I take at the very least 2 hours to teach this
    module, normally closer to 3-4 hours.

1-5 --
    The Glossary is nice, but belongs at the BACK of the chapter.  It makes
    no sense putting it up front because I am NOT going to discuss these
    words before lecturing the chapter.  This means that I have to make my
    students skip over 4 to 5 pages of 'text' before we get to something we
    can get started on for lecture.  And then upon finishing the chapter I
    am not going to have them flip back to the beginning of the chapter to
    review the terms we discussed.  Look at an average college text book or
    some non-computer seminar materials, they might have an outline or a
    mini-table-of-contents at the beginning of the chapter, but the glossary
    is always at the end!  Just as a crazy guess, I bet this is because of
    the SPI/TBI course that will be based on this material?!  Fine, put the 
    glossary up front for them...in lecture lab we put the INSTRUCTOR up front
    so we don't need this stuff 'in the way'.  (thanks for letting me vent!  
    Not picking on the writer, just the bureaucracy.)

1-7, 5th bullet --
    "...by dividing each second of processor time..."  On VMS a 'second' is
    not a normal scheduling increment of time for processes.  It is quite
    possible for a QUANTUM to exceed 1 second, so QUANTUM doesn't divide
    seconds, rather it divides available CPU time.  Try "...by dividing
    processor time...".  The word SHORTER has no meaning, use SMALL.  Also,
    "...sections or time...", "or" should be "of".

1-9a, 1st paragraph, last line --
    "The answer is no" is not actually correct.  There is a way to force an
    image (not a process) to have CPU affinity, not well documented.  (Nit)

1-10a, 2nd bullet --
    In fact the process IS interrupted by Quantum end, although it is not 
    AFFECTED by it.  Quantum End processing must still run, although the only
    thing it does is reset the Quantum timer, it does 'interrupt', it doesn't
    affect or influence the process.

    mid-way -- "You cannot change the base priority...".  True at the SUBMIT
    command, but once the job runs you can raise and lower priority as normal.

    7th bullet --
    Sounds definitive that batch should be at 3.  In fact it runs quite
    effectively anywhere from 0 to 3 on time-share systems.  There were some
    concerns with very low priority processes getting locked out but PIXSCAN
    and other features handle the oddity issues relatively well.  I suggest
    the sentence above the bullets ends like: "...favor the interactive 
    process, such as:"

1-10, 8th bullet --
    Isn't there a boost of 6 at process create time!  I know what you are
    thinking, but the book isn't saying what we are thinking.

1-15 --
    OK, so what?!  what is the benefit of this table to a system manager?
    Are we going to show them how to find this info SDA?  To what end?  This
    info is interesting but neither improves my management skill nor my ability
    to tune the system any better.  Move the bulk of this to the instructor's
    page or an appendix if you really want to keep it.  A short list of example
    mutexes on 1-14 would be sufficient, but I can't think of what the benefit
    would be for a System Manager student to know the Global name of a Mutex.
    Great stuff for an architecture or internals class, but I'm not thrilled
    with it here.

1-16, 3rd bullet --
    Eh?  Unclear, what is "also" implying?  I expect a bulleted item to be a
    'subtopic' of the main header of the page.  The header say "System Resource
    Miscellaneous Waits" and the bullet says "Also in MWAIT state" -- sorry,
    just doesn't make sense.

1-17 --
    Do we need a full listing here?  If so, we need definitions and possible
    solutions for these.  Let's reduce the listing to some of the more common
    ones (AST, MBX, MPE, MPB, SCS) and actually tell the students what causes
    them, what to look for, how to fix -- on the student page!  Put a reference
    to the current IDS page(s) on the instructor's page for the full listing.
    Showing them data structures and not giving them something to do or fix is
    a disservice for a Performance student.

1-18, 2nd bullet --
    A few more 'normal' rules.  
     Because of dash #3 ...
     - You get the whole boost or nothing at all (base priority is 14, terminal
       I/O completes and priority is still 14)
    (of course PIXSCAN does weird things, but we can talk about it later)     

1-19, bullets 1 & 2 --
    This is misleading.  It sounds like were are getting a double decrement if
    we are the only active process on the system -- one at scheduling and one
    at quantum end.  Quantum end calls scheduler and if the same process is
    selected it is decremented, otherwise quantum end does not decrement the
    process priority.

1-20a --
    Note: Older processors don't number their CPUs sequentially.  My 8350 has
    its CPU numbers based on the card positions in the cabinet.  My CPUs are
    numbered 3 & 7, not 0 & 1.
 
1-21a, reviewers note --
    Going from set 12 to set 13 SHOULD be a (P).  Back in V5.2 the scheduler
    was changed to require a minimum of 3 priorities higher before a pre-empt
    could be done with time-share processes (never changed for real-time).  
    Although this improved performance on some systems it damaged it on others.
    In V5.3 they changed the 'hard-coded' scheduler change to a SYSGEN 
    parameter (PRIORITY_OFFSET) to allow system managers to select the style of
    scheduling they wanted.  If PRIORITY_OFFSET is set to 3, then the proposed
    change in the diagram would be correct.

1-22a, "13." --
    See previous note.

1-22, "13" --
    See previous note.
  

>1-5 --
>    The Glossary is nice, but belongs at the BACK of the chapter.

    We started to add chapter glossaries with the new User curriculum (VMS
    for Programmers, Sys/Net I, VMS for Operators, and VMS Skills for
    Users), and you can expect them in the next rev of Sys/Net II and III. 
    
    I don't believe anyone has suggested putting the glossary at the end of
    the chapter until now (though I could be wrong). We can certainly
    entertain the idea, but there's now ample precedent for putting them
    at the beginning, and for consistency we want to keep doing so.
    
    					Val

    I have found the addition of glossaries to be a definite plus.  As to
    my  personal style in lecture, I start a new topic by introducing the
    new terminology.  Some will call this an introduction or overview, but
    I am actually  defining the terminology.  Putting glossaries in the
    back, in my opinion, work best in a "text book".  In a "lecture guide"
    I would prefer to keep them in the front.
     
    Arnold Tarling
    

  
  And the rest of this module...
  
1-23, 2nd bullet, 5th dash --
    "Decrements priority by one toward base OF NEWLY SELECTED PROCESS"

1-24, 6th bullet --
    Did anyone notice that AUTOGEN sets PIXSCAN to be MAXPROCESSCNT/11,
    a rather weird number.  Why?  If MAXPROCESSCNT is 250 the PIXSCAN
    is 22!  Theoretically 22 processes could get boosted in 1 second!  And
    if they each got a QUANTUM, then my lowly process wouldn't get any
    CPU for 4+ seconds, after which I might get a PIXSCAN, etc.  Seems
    strange, anyone know why the formula is MAXPROCESSCNT/11?

1-25 --
    Is there supposed to be a picture here?  Maybe a SHOW PROC/TOPCPU?
    The way the bullet is phrased leads me to believe that something is
    supposed to be shown there.  Maybe change USING to USE?

1-32 --
    How about putting a few other 'items' on the IPL side, like the Clock,
    Fork Processing, etc.  It looks kinda bare.

1-34, Interrupt stack time --
    The old rule of thumb used to be 20%, where did we get 15%?

1-35a, 4th paragraph --
    SPM has a report that show what percentage of time each process on the
    system spent in each mode -- one of my favorite displays!  See the current
    version of this lecture guide, near the back of the SPM section, for a
    sample display.

1-39, 2nd bullet --
    (nit) We should be using SET ACL/OBJECT=FILE /ACL=... instead of SET FILE.

1-40, 5th bullet --
    The word "response" throws us a curve here.  If a process is interacting
    with the users on a heavily CPU loaded system, then REDUCING the QUANTUM
    value with improve 'responsiveness' but may actually degrade pure system
    performance.  INCREASING the QUANTUM on a heavily CPU intensive (minimal
    human interaction) may actually reduce elapsed/CPU time for the processes.

    Remember the rule about squeaky wheels?  If we make the humans unhappy,
    they tell us and everyone else the system runs poor, but a batch job 
    doesn't usually complain -- tune to satisfy the people is the safest rule.

1-41 - 1-46 --
    Put all of this in an appendix.

    1-42 -- Eliminate the VECTOR APPLICATIONS section or move it to the
        instructors page, its not what a system manager needs to see.

    1-43 -- Drop this page or move to page 1-42a, nothing to lecture on, just
        stuff for the instructor to talk about if needed.

    1-44, last line --
        May need to increase BYTLM as well!  If default BYTLM is 8192 and 
        VECTOR gets 16*512 (8192), there is nothing left for other things.

1-45a, 2nd half of page --
    looks like an exact copy of the student's page--not useful to me!

1-45, 6th bullet, change it to "Capability of Vector", or something like 
    that (drop the "=").  The example below has the correct syntax.

1-46, diagram --
    alignment problem with right margin
 
1-50 --
    We need an intro to Specmarks, VUPS, MIPS, etc. earlier in the chapter.
    It has made a very good intro to the module previously, I'd be glad to
    "talk you through" my first few minutes of the current chapter over
    the phone to get the feel of how that intro (and VUP table) is used.

1-52 --
    I don't have time to work up the speed 'ranges' like I did last time.
    I'd suggest at least getting the published 'VUP' rating for the
    current machines on this page.  Also, make sure this page (or the
    instructor's page) references the current sales literature that
    publishes VUPS/SPEC data.

$

    Re: Glossaries
    
    To my knowledge there is no constraint on whether the glossary should
    go at the back or the front - it's not anything to do with TBIs (as far
    as I know - but then again what do I know???)
    
    
    So far I see 2 opinions - one to leave it where it is, one to move it.
    
    In the absence of other opinions - inertia rules, OK?
    
    Get your votes in now!!!!!!!
    
    Andy

  Only real problem I found with chapter 3 was the ugly diagram on page
  3-44.  We should be able to fix things like this -- just looks bad
  when a customer asks "Why are the lines are indented funny?"
  
  $