From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Xref: utzoo comp.lang.ada:5511 comp.realtime:1334
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!sol.ctr.columbia.edu!src.honeywell.com!klemmer!vestal
From: vestal@SRC.Honeywell.COM (Steve Vestal)
Newsgroups: comp.lang.ada,comp.realtime
Subject: Re: Wanted: Performance Analysis Tools on PCs Info
Message-ID: <1991May23.194626.10076@src.honeywell.com>
Date: 23 May 91 19:46:26 GMT
References: <1193@aviary.Stars.Reston.Unisys.COM> <1991May23.063331.13782@telesoft.com>
Sender: news@src.honeywell.com (News interface)
Organization: Honeywell Systems & Research Center
In-Reply-To: rlk@telesoft.com's message of 23 May 91 06:33:31 GMT
Nntp-Posting-Host: klemmer.src.honeywell.com
List-Id: <comp.lang.ada>


In article <1991May23.063331.13782@telesoft.com> rlk@telesoft.com (Bob Kitzberger @sation) writes:

Bob> Your next highest priority task should probably be the lowest frequency
Bob> task (if you are following Rate Monotonic Scheduling).  At each period
Bob> boundary, it can check the value of the global variables being updated
Bob> by the slack task.  If you know how quickly the slack task increases
Bob> these global counters when the system load is nil (nominal case), then you 
Bob> can calculate the amount of time spent in the slack task over the
Bob> measurement period.  100% minus the time spent in the slack task is your
Bob> system load.  Determination of the maximum rate at which the slack task can
Bob> update global counters is pretty straightforward, and only needs to be done
Bob> once.

I've done something similar to this, it works reasonably well.  I got fairly
close agreement between the measured utilizations etc. and analytically
predicted values (inputs to the analytic model were obtained via a "standard"
benchmark suite to measure various scheduling overheads).  There's a Tri-Ada
'90 paper about this.

Steve Vestal
Mail: Honeywell S&RC MN65-2100, 3660 Technology Drive, Minneapolis MN 55418 
Phone: (612) 782-7049                    Internet: vestal@src.honeywell.com