🚀 go-pugleaf

dario@techunix.BITNET (Dario Ringach) writes:


>Is there any way to monitor the percent of usage of a
>Transputer by running an OCCCAM process in PAR-rallel
>with an application?  Thanks. -Dario


A monitoring process could be written to examine the process
queue[s] and to determine how many processes are waiting to run
(and being prevented from doing so by this monitoring process).
If the front and end process queue pointers are equal, the
monitoring process is the only "active" process and is executing
in idle CPU time. Otherwise it is preventing other processes from
running and is actively slowing the system down. By keeping a
count of :-

    t.idle    Number of times process is scheduled during CPU idle
              time.

    t.active  Number of times process is scheduled when other
              processes are waiting (ie CPU "busy").

a [crude] estimate of CPU loading in a given refernce time period
can be determined.

Note :-

    1. That the monitoring process takes up CPU time so
       calculations should make allowances for this and the
       re/descheduling times.

    2. Also the counts can become rather large!

    3. It should be run on the required process queue (ie high or
       low).

A means of de/activating this process must be contrived for
control purposes.

I have not tried this but it should work (in theory, on paper,
not coded yet, etc :-).

Doubtless there is a much, much better way......

Cheers,

Ian.



-- 
Ian Nandhra,     iann@specialix.co.uk     {backbone}!mcsun!ukc!slxsys!iann
I am speaking, but  | If these are your opinions, then we are in agreement!!
not for my employer.| Flames, spelling errors, complaints > /dev/null

In article <1990Oct17.110318.9927@specialix.co.uk>, iann@specialix.co.uk
(Ian Nandhra) writes:
> dario@techunix.BITNET (Dario Ringach) writes:
> >Is there any way to monitor the percent of usage of a
> >Transputer by running an OCCCAM process in PAR-rallel
> >with an application?  Thanks. -Dario
> 
> 
> A monitoring process could be written to examine the process
> queue[s] and to determine how many processes are waiting to run
> (and being prevented from doing so by this monitoring process).
> [...]

Sheesh, that's tougher than it need be. Hossein and I used to just sit
a process on a v.short timer and allow it to maintain a counter.

TIMER t:
WHILE forever
  SEQ
    t ? AFTER zip.nada
    c := c + 1

This process will now effectively provide a count which represents the
idle time on the processor - since it'll keep geting rescheduled if the
processor is idle.

Steven
--
Steven Ericsson Zenith              *            email:
zenith@cs.yale.edu
Fax: (203) 466 2768                 |            voice: (203) 466 2587
   "All see beauty as beauty only because they see ugliness" LaoTzu
Yale University Dept of Computer Science 51 Prospect St New Haven CT
06520 USA

>dario@techunix.BITNET (Dario Ringach) writes:
>
>
>>Is there any way to monitor the percent of usage of a
>>Transputer by running an OCCCAM process in PAR-rallel
>>with an application?  Thanks. -Dario

Here is an example OCCAM process which can be executed at high priority.
It wakes up periodically, and detects whether a low priority process
was executing (and therefore was interrupted).
It updates an 'idle count', which can be communicated to another process.

PROC monitor(CHAN OF BOOL req, CHAN OF INT data)

  VAL delay IS 1000 : -- 1 millisecond at high priority

  INT Wdesc.save :
  PLACE Wdesc.save AT 11 : -- address of saved low priority Wdesc
                           -- (see chapter 10.2 of the Compiler Writer's Guide)

  BOOL running :
  INT idle :
  SEQ
    idle := 0
    running := TRUE
    WHILE running
      TIMER time :
      INT now :
      SEQ
        time ? now
        PRI ALT
          BOOL request :
          req ? request
            IF
              request  -- if request is TRUE, return and reset the idle count
                SEQ
                  data ! idle
                  idle := 0
              TRUE     -- if request is FALSE, shutdown
                running := FALSE
          time ? AFTER now PLUS delay
            IF
              Wdesc.save = ((MOSTNEG INT) + 1) -- '1' means low priority
                idle := idle PLUS 1 -- make sure it can't overflow
              TRUE
                SKIP -- there was a low priority process executing
:

Sending TRUE down 'req' will return the idle count down 'data', and
reset the count. Sending FALSE will terminate the process.

The process would be used somewhat like this:

CHAN OF BOOL req  :
CHAN OF INT  data :
PRI PAR
  monitor(req, data)
  INT idle :
  SEQ
    ...  your program here
    req ! TRUE
    data ? idle
    ...  display the idle count, or whatever
    req ! FALSE


Note that the 'granularity' of the idle count can be adjusted by changing
the delay. While waiting on the timer queue, no CPU time is used, so the
only overhead is the cost of the loop every millisecond.
Note too that this process does not take other high priority processes
into account.

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".