Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!wuarchive!swbatl!texbell!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.unix.wizards
Subject: Re: sadp on i386
Keywords: sadp i386
Message-ID: <18431@nuchat.UUCP>
Date: 14 Jan 90 17:55:51 GMT
References: <1583@aber-cs.UUCP> <7348@cbnewsh.ATT.COM>
Reply-To: steve@nuchat.UUCP (Steve Nuchia)
Organization: Houston Public Access
Lines: 32

In article <7348@cbnewsh.ATT.COM> dwc@cbnewsh.ATT.COM (Malaclypse the Elder) writes:
>in the original implementation.  since the driver could be sure
>that the I/O was completed in the order that the requests were
>submitted, it could use a simple queue to keep track of service
>times.  now that the controller can take a number of requests and
>schedule them in what it considers a good order, the driver would
>have to tag each request and timestamp it and then look at the time
>when that job finished.  its not difficult but its also not trivial

Interesting problem.  Howver, you can assume that the controller
is doing *something* as long as it has active requests, so all you
have to do is:

	maintain a count of outstanding requests, and a counter
	of requests serviced in a "session".

	A session begins when a requests is given to an idle
	controller -- set the request counter to 1 and the
	serviced counter to 0, and note the time.

	when a request is completed, decrement the request
	counter and increment the serviced counter.

	when the request counter drops to zero, divide the elapsed
	time by the serviced counter to get the average service time
	for the session.  Merge the average into your running average
	using the serviced counter as a weighting factor.
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"If the conjecture `You would rather I had not disturbed you
 by sending you this.' is correct, you may add it to the list of
 uncomfortable truths."   - Edsgar Dijkstra