pcg@aber-cs.UUCP (Piercarlo Grandi) (01/13/90)
In article <7088@cbnewsh.ATT.COM> dwc@cbnewsh.ATT.COM (Malaclypse the Elder) writes:
i guess the problem is that as disk controllers got more
intelligent, much of the statistics that were collected
by the kernel couldn't be directly measured. the result
is the implementers chose not to provide any measurements.
No. Most discs out there use very simple controllers, and even
SCSI controllers could be profiled easily by using block
numbers.
The real reasons why sadp is not supported are, in order of
importance:
1) most system administrators would not use it, because
they are lazy or not competent enough.
2) adding statiistics collection to a driver is an
extra job to do; if the customer does not ask for it,
it will be omitted.
3) In some cases statistics collection requires a table
whose size is combinatorial in the number of drives.
Point #3 is easy to obviate if statistics collection can be
disabled at system generation time. Points #1 and #3 are the
really important ones.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukdwc@cbnewsh.ATT.COM (Malaclypse the Elder) (01/14/90)
In article <1583@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes: > In article <7088@cbnewsh.ATT.COM> dwc@cbnewsh.ATT.COM (Malaclypse the Elder) writes: > > i guess the problem is that as disk controllers got more > intelligent, much of the statistics that were collected > by the kernel couldn't be directly measured. the result > is the implementers chose not to provide any measurements. > > No. Most discs out there use very simple controllers, and even > SCSI controllers could be profiled easily by using block > numbers. > > The real reasons why sadp is not supported are, in order of > importance: > > 1) most system administrators would not use it, because > they are lazy or not competent enough. > > 2) adding statiistics collection to a driver is an > extra job to do; if the customer does not ask for it, > it will be omitted. > > 3) In some cases statistics collection requires a table > whose size is combinatorial in the number of drives. > > Point #3 is easy to obviate if statistics collection can be > disabled at system generation time. Points #1 and #3 are the > really important ones. i'm not one to insist on what the "real" reasons are, but i'm sure that the diligence or competence of system administrators is not what goes through the mind of a driver writer. in fact, assuming that system administrators are the only people who will this data is a mistake. i do believe that it has to do with the difficulty of keeping the statistics in the driver. to understand the statement from my original posting, you have to understand how such things as average service time was computed 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 in terms of overhead. and every driver would have to have its own method of keeping track of its I/Os. that is why i asked about whether controllers now provide that info. there should be a well defined interface to get performance data in the same way that there is a well defined interface to get disk data. it would make things alot easier. danny chen att!hocus!dwc
steve@nuchat.UUCP (Steve Nuchia) (01/15/90)
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
chris@mimsy.umd.edu (Chris Torek) (01/15/90)
In article <18431@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: > 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. Beyond `some sort of statistics on some sort of controller', I have no idea what this is all about. However, note that the algorithm (not quoted in entirety above) assumes that the request counter will drop to zero. This is a very strong probability, but is not assured; in particular, it will lead to bizarre `continuous controller activity' benchmarks. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris