Acorn User 4/AUCD4.iso/acornuser/1998/apr1998/pd/Avison/!TaskUsage/!Help

Text File | 1998-02-12 | 18KB | 388 lines

                       Help for Task Usage                        Version 1.15
                       ===================                        © Martin Avison
                                                                  Avisoft
  Purpose
  =======

  The purpose of this little application is to display in figures and graphically:

  •    the recent average processor usage for each Task
  •    the recent average processor usage for each Wimp Reason Code
  •    the number of Wimp Polls being processed

  The Reason Code and Poll details can be for all Tasks, or for a specific Task.
  If for a specific task, any Reason Codes masked out by the task are shaded.

  This is all done with as little overhead as possible.

  The idea grew from a theory that some tasks seemed to take more processing power
  than they should, either permanently or intermittently, making the desktop
  sluggish.  The main causes seems to be programmers simple mistakes, or
  programmers being lazy, and ignoring the exhortation in the Programmer's
  Reference manual, page 3-116:

       "You can disable some of the event codes: they are neither checked for
       nor returned, and need not have any handlers provided.  You must do this
       for as many codes as possible, especially the Null_Reason_Code, if your
       task is to run efficiently under the Wimp."

  PLEASE TAKE NOTE!  With the help of TaskUsage we all now have NO excuse!


  How to use TaskUsage
  ====================

  The TaskUsage application is started in the normal way by double-clicking on
  the !TaskUsage icon in a Filer window.  It will install on the Icon Bar a
  TaskUsage icon consisting of a box containing 'CPU'.   However, after a small
  delay to collect initial statistics, the TaskUsage Icon Bar icon will be updated
  each second or two with a graphical representation of the total processor usage.

  The update time will be one second for RISC OS 3.5 and above (ie at least RISC
  PC), and two seconds for the slower machines to avoid a large display overhead.
  This default should be reasonable, but the default can be overridden if
  required  (please see the !Run file for details)

  The Icon will normally show the usage over the last 40 seconds or so.

  If Select is clicked on the TaskUsage icon bar icon, the Task Processor Usage
  window will open.  This window is in a similar format to the Task Manager's
  display of Storage usage, showing the current tasks, and in the same order.
  Against each task is shown the recent average percentage processor usage, as a
  percentage figure and a coloured bar graph.  In addition, the overall Processor
  usage is given, and the totals for Application and for Module tasks.  The
  display will update every second or two, and will adjust itself whenever tasks are
  started or stopped.  The window can be resized in the usual RISC OS way, but if
  Select is clicked on the Icon Bar the window will revert to the initial state,
  showing all Application Tasks, and only the total for the Module Tasks.

  If Adjust is clicked on the TaskUsage icon bar icon, the Task Reason Code
  Usage window will open.  This shows the recent average number of Wimp Polls
  being processed per second, and the processor usage for each Wimp Reason code.
  If a task is clicked on in the Task Processor Usage window, the Task Reason Code
  Usage window will change to show the figures for that task only.  While a
  specific task is being monitored, any Reason Codes which the task has masked out
  because it is not interested in them are shaded.  To revert to monitoring all
  tasks, simply click on any totals line in either window.  Note that the Reason
  Code shading cannot be updated until the task does something, however trivial.
  This is prompted by TaskUsage sending the task a Wimp_HelpRequest message, which
  is usually sufficient.  If all the reasons remain shaded, try opening a menu or
  a window for the task.  Unfortunately, if the Filer is clicked on, you may get
  an error message from the Filer of 'Message token MH not found'.  This will stop
  happening if a menu is opened over any Filer window!  And before you ask, I do
  not know why!

  If Menu is clicked on the TaskUsage icon bar icon (or on either TaskUsage
  window), the usual Info and Quit options are available.  In addition there is
  a Timer option, which just shows details of the Timer being used and the Update
  frequency, and Task and Reason options which will also open the windows.

  Note that full Interactive Help is available on all Menus and Windows, if !Help
  or !BubbleHelp is running.


  Machine Requirements
  ====================

  Any measurement will distort what is being measured, and Task Usage is no
  exception.  However, the overheads have been pared to a minimum to enable it
  to be run easily on any RISC OS machine.

  Note that at least RISC OS 3.00 is required to run TaskUsage.

  The memory requirements are approximately as follows:

  •    The TaskUsage relocatable module           6,192
  •    The TaskUsage module workarea              6,272
  •    The Messages file                          1,848

                          Total Storage          14,312

  The total storage required to run Task Usage is therefore only about 14k, all in
  the Relocatable Module Area, regardless of the machine model and page size.
  Some 5k or so additional storage will also be obtained by the Wimp in the RMA to
  hold window definitions etc. for the Task Usage application.

  Task Usage measures it's own task, which uses on average the following
  processor power on two machines, with both windows open, even with over
  100 tasks running. Note it is even less without the windows open!

  •    RISC PC with StrongArm        less than 1% processor
  •    A4000                         varies between about 10% and 30%

  RmKill TaskUsage can be safely used to remove the module from storage.
  Quitting the TaskUsage application will do this automatically.


  How the Processor Usage is Calculated
  =====================================

  When TaskUsage initialises, it installs the following timing code in RISC OS:

  •    The internal Timer 1 is used to obtain all elapse times.  This requires
  interrupt code, which is only 6 instructions long, but it is called many times a
  second, depending on the 'precision' of the timing clock being used.

  !TaskUsage automatically sets the precision depending on the RISC OS version,
  and whether StrongArm is fitted.  This is so that faster processors can use a
  higher precision timer, but slower processors are not spending too much time
  trying to be over accurate!  The default settings should be reasonable, but the
  default can be overridden if required (please see the !Run file for details)

      Precision     Timers/Sec          Default used
          0            100
          1            200
          2            400              v3.00, v3.10, v3.11
          3            800
          4          1,600              v3.50, v3.70 (ie RISC PC)
          5          3,200
          6          6,400              v3.70 with StrongArm
          7         12,800
          8         25,600

  The higher the precision, the more accurate, but the more overhead!!

  This internal Timer is used in preference to the RISC OS Monotonic Time,
  because that is only available in centiseconds.  A StrongArm machine can poll
  at 20,000 times a second, so using a timer which is only capable of measuring to
  100 times a second is rather inaccurate!   Note however that there can be only
  one user of Timer 1 - if you have another Application which uses Timer 1, then
  if they are both running at the same time, the first one started will NOT work
  properly.  If you need to run both applications, then using a precision of M will
  set TaskUsage to use the Monotonic Time (100 Timers/sec) instead of Timer 1.

  The precision and the timer being used can be displayed by the menu option Timer.

  When TaskUsage initialises, it installs the following monitoring code in RISC OS:

  •    The Wimp Post-Filter code, which is about 12 instructions long, and is
  called every time a program returns from a Wimp Poll.

  •    The Wimp Pre-Filter code, which is about 33 instructions long, and is
  called every time a program calls Wimp Poll.

  •    The Interrupt code, which is called every second (or two), is about 230
  instructions, plus 10 for each of the maximum number of tasks that have run
  concurrently since the computer has been started or Reset.

  Using the times gathered by this monitoring code, the following are calculated:

  •    The elapse time is recorded for each Task, from the time when the
  application is returned to after calling WimpPoll, to the time the application
  calls WimpPoll again.  This is the elapsed time spent in the application Task.
  It will usually comprise Processor time, but if any input or output is involved,
  there may be some time spent waiting for the disc or other device.

  •    In addition, each second the interrupt routine first accumulates the time
  for the Task and Reason Code which it has interrupted.  It then calculates the
  latest average for each Task, and for each Wimp Reason Code.  The average is a
  simple rolling 'average', calculated by taking the last average, adding the
  latest elapsed processor time, and dividing by two.  It is not a true average,
  but it is simple, quick, and gives a reasonable representation of the usage.


  Test Programs Supplied
  ======================

  In the !TaskUsage directory there is a directory called TestProgs.
  This contains four simple programs:

  •    PollAsm      an Assembler WimPoll loop on NullPoll
  •    PollBasic    a BASIC WimPoll loop on NullPoll
  •    PollIdleBa   a BASIC WimPollIdle loop on NullPoll with 1/10 second delay
  •    PollModule   an Assembler WimPoll loop on NullPoll in a Relocatable Module

  Note that all these programs appear to do NOTHING when double clicked on.
  No icons appear!  They simply poll as fast as possible.
  The only way to stop them is to select Quit from the Task Manager display.

  Some test results from monitoring the Polling programs, with little else
  running, on two different machines, are as follows:

  RISC PC600 StrongArm   RISC OS 3.70
  -----------------------------------

  Precision         5
  Timer Used        Timer 1
  Timers/Second     6,400
  Seconds/Update    1

                     CPU Usage/Task                Polls/Second
  Programs          1 Task   2 Tasks             1 Task   2 Tasks

  PollModule           22%      10%              18,500    5,700
  PollAsm              20%       5%              18,400      800
  PollBasic            60%      15%              11,800      590
  PollIdleBa            0%       0%                  10       10

  A4000   RISC OS 3.10
  --------------------

  Precision         2
  Timer Used        Timer 1
  Timers/Second     400
  Seconds/Update    2

                     CPU Usage/Task                Polls/Second
  Programs          1 Task   2 Tasks             1 Task   2 Tasks

  PollModule            8%       4%                 750      200
  PollAsm               8%       4%                 750      180
  PollBasic            45%      15%                 400      130
  PollIdleBa            4%       4%                  10       10


  Observations from using TaskUsage
  =================================

  •    If RISC OS is not operating in multi-tasking mode, for example when F12 is
  used for a command line, or when a program is run which does not call Wimp Poll,
  then the figures collected will be (very) distorted, but will soon recover when
  multi-tasking is resumed.

  •    The time spent in applications either before the first call to WimpPoll,
  or after the return from the last WimpPoll, are not included in the times shown
  by TaskUsage, as they are not then multi-tasking.

  •    The time spent by RISC OS itself when not actually running tasks is not
  included in the times shown by TaskUsage.

  •    Any interrupt code is included in the application which happens to be
  running at the time, but this should be small.

  •    The number of Wimp Polls which are being processed per second tends to
  grow, then fall, as the system gets busier, as it can service each task less
  frequently.  Note that a large Null Reason Code time is not necessarily bad: it
  may show that the system has some spare time to do any background tasks
  required.

  •    On a RISC PC 600, an assembler loop round a Wimp_Poll in an Application
  Task can manage over 1,600 polls per second, and uses about 10% of the
  processor, if running on its own.  However, if another is started, the total
  drops to about 500, and each task is getting about half.  The total drop must be
  because of the overheads of running more than one application task, which
  requires memory to be paged in and out.  The system polling capability is then
  divided by the number of tasks running.  Subsequent additional tasks do not
  reduce the total significantly, but each task only gets it's share of Null
  Polls.  This is why misbehaved tasks which use the Null reason code when not
  required soak up such large amounts of processor time, making the system less
  responsive, even though Null codes are processed with the lowest priority.

  •    On a RISC PC 600, an BASIC loop round a Wimp_Poll can manage about 650
  polls per second, and uses about 55% of the processor, if running on its own.
  However, if another is started, the total drops to about 350, and each task is
  getting about half.  The drop of the total is less than with the assembler Poll,
  but this is probably because the multi-tasking overheads are partly overshadowed
  by the Basic overheads. Again, each task gets it's share of the Null Polls.

  •    On a StrongArm RISC PC, the assembler Wimp_Poll loop can reach 19,000
  polls per second, and the Basic loop can reach 1,550.

  Some observations on a few specific applications is as follows:

  •    !PCpro, version 2.03, supplier Aleph 1:  This uses 90%+ if the PC window
  is open, and has the input focus. This falls to 60% if it does not have the input
  focus, and 0% if frozen. If in full screen mode, it is obviously 100%.

  •    !Usage, dated 30/1/92, supplier Acorn:  This sometimes uses up to 30%,
  although it does not report the high usage!

  •    !OmniDesk, version 1.10, supplier Acorn User: Exhibits large amounts of
  Null Poll processor time.  It appears that the author planned to use PollIdle
  to poll once a second, as all the code it present apart from passing the time to
  Wimp_PollIdle.  This applies to IconFlags, SWIIndex, and WindFlags.

  •    !Larger, version 2.14, supplier Warm Silence Software: seems to use
  WimpPollIdle with a zero time in some cases (eg when a window had been dragged)
  until a mouse click is done on the !Larger backdrop.  Then the time is set to 25
  centiseconds, and the usage drops considerably.

  •    !FireworkzPro, version 1.30/06, supplier Colton Software: uses large amounts
  of Null Poll processor time, even when just loaded on the Icon Bar.

  •    !EasyFontPro, version 4.13a, supplier Fabis Computing: uses large amounts
  of Null Poll processor time, even when just loaded on the Icon Bar.

  These observations may not be typical - or even accurate!
  No criticism of the software is expessed or implied.


  Acknowledgements
  ================

  To Ran Mokady, for the initial inspiration for this !TaskUsage application.
  I obtained his !Usage application, version 1.00, dated 24th May 1990, from
  The Datafile.  However, it tended to lose storage, and it had a relatively high
  processor overhead.  As there was no contact information for Ran, I decided to
  try and improve on it.

  To Dominic Symes, for Zap, a wonderful editor.



  Conditions of Use
  =================

  Please note that all the software and documentation supplied with TaskUsage is
  copyright, and may only be copied for personal backup purposes.

  Although TaskUsage is believed to be free of any bugs, Avisoft cannot accept
  any responsibility for any loss or corruption of data which might result from
  using TaskUsage.  Normal testing and data backup should be performed!


  Problems and Suggestions
  ========================

  If any bugs or problems are found, or if you have any suggestions for
  improvements, please send me full details including version information,
  preferably on eMail, so that I can recreate the problem and try to correct it.


  History
  =======

  v0.??  15/ 5/96  All v0 were development versions, never released.
         It started as a BASIC program with a small Relocatable Module, and was
         gradually changed to a full Relocatable Module Wimp Task, using
         BASIC assembler.  This was to reduce storage requirements, and to eliminate
         the memory switching overhead when TaskUsage became active.

  v1.00   9/03/97  Allowed Monotonic Time from parm
  v1.01   9/03/97  Added Timer display dialog box
  v1.02  11/03/97  Fixed time data precisions
  v1.03  20/04/97  Allowed parm to vary PollIdle and Display time
  v1.04  09/05/97  Displayed PollTime in Timer dialog box
  v1.05  25/05/97  Corrected initialisation mask and LastTimer problems
  v1.06  20/08/97  Reduce Wimp Title to avoid old RISC OS problem
  v1.07   9/09/97  Made menu persistent if adjust pressed
  v1.10  14/12/97  First version released
  v1.11   1/ 2/98  Catered for Nested Window Manager
  v1.12   7/ 2/98  Tidied up Templates and Template handling
  v1.13   9/ 2/98  Optimised FNgettime and parameter setup
  v1.14  10/ 2/98  Reduced stack size
  v1.15  11/ 2/98  Reduced Reason time list

  Contact Information
  ===================

  eMail:      [e-mail]

  SnailMail:  Martin Avison,
              Avisoft,
              16  Well Close,
              Leigh,
              TONBRIDGE,
              Kent      TN11  8RQ

  Phone:      [phone]



    *******************************************************
    **  If this help has flashed past too fast to read,  **
    **  then please load !Edit and try again!            **
    *******************************************************