Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!slxsys!iann
From: iann@specialix.co.uk (Ian Nandhra)
Newsgroups: comp.sys.transputer
Subject: Re: Monitoring CPU Load?
Message-ID: <1990Oct17.110318.9927@specialix.co.uk>
Date: 17 Oct 90 11:03:18 GMT
References: <9801@discus.technion.ac.il>
Organization: Specialix International, London
Lines: 55

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