dario@techunix.BITNET (Dario Ringach) (10/17/90)
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 -- Dario Ringach Technion, Israel Institute of Technology Dept. of Electrical Engineering, 32000 Haifa, Israel dario@techunix.bitnet | dario@techunix.technion.ac.il
iann@specialix.co.uk (Ian Nandhra) (10/17/90)
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
zenith-steven@cs.yale.edu (Steven Ericsson Zenith) (10/18/90)
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
conor@wren.inmos.co.uk (Conor O'Neill) (10/23/90)
>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".