Xref: utzoo comp.unix.sysv386:7889 comp.sys.att:12249
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.unix.sysv386,comp.sys.att
Subject: Re: sar -d and ESDI drives
Keywords: sar
Message-ID: <3872@sixhub.UUCP>
Date: 7 May 91 23:46:05 GMT
References: <1991May1.153257.18685@bradley.bradley.edu> <1991May02.135710.7757@chinet.chi.il.us>
Reply-To: davidsen@sixhub.UUCP (bill davidsen)
Followup-To: comp.unix.sysv386
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 24

In article <1991May02.135710.7757@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes:

| 	sar -d is broke in most (all?) 386 unix's.  Seems no-one
| 	is able to convert the 3b2 based routines in sar for disk
| 	monitoring to the pc-bused controllers.  AT&T tried to
| 	fix it in their 3.2.3 release, but broke everything else.

  Maybe. It was broken in ODT1.0 and seems fixed in the new (1.1?)
version which came out recently. However I noted that every once in a
while it printed a blank line. I tried it on (Dell) V.4, and that seems
to work, but every once in a while prints "nan" in a field. I suggest as
a possibility that some values may be overflowing, trapping, and not
getting printed or counted in the average. The blank lines went away
when I started three copies of find looking through all 700MB for a file
which wasn't there. Then I got reasonable results, as I did when I just
said "sar -d" with no args.

  Guess I'll say it's not broken on all versions, although it still
seems a trifle bent on a lightly loaded system.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me