Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!att!cbnewsh!dwc
From: dwc@cbnewsh.ATT.COM (Malaclypse the Elder)
Newsgroups: comp.unix.wizards
Subject: Re: sadp on i386
Keywords: sadp i386
Message-ID: <7348@cbnewsh.ATT.COM>
Date: 14 Jan 90 01:22:55 GMT
References: <1583@aber-cs.UUCP>
Organization: The Legion of Dynamic Discord
Lines: 55

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