fred@bradley.bradley.edu (Fred Jaggi) (05/01/91)
i'm trying to do performance graphs of some 6386 machines running UNIX
System V R 3.2.2, but sar -d doesn't show me anything. this seems to
be the case for all the machines with ESDI drives (SCSI and IDE seem
to work just fine). is there any fix available for this?
fred
--
Frederick Jaggi fred@bradley.bradley.edu Bradley University
"All lies, no sleep, dusty pleasures"bill@unixland.uucp (Bill Heiser) (05/02/91)
In article <1991May1.153257.18685@bradley.bradley.edu> fred@bradley.bradley.edu (Fred Jaggi) writes: >i'm trying to do performance graphs of some 6386 machines running UNIX >System V R 3.2.2, but sar -d doesn't show me anything. this seems to >be the case for all the machines with ESDI drives (SCSI and IDE seem >to work just fine). is there any fix available for this? I have three SCSI disks and one SCSI tape on my system. sar -d gives me a column of time-stamps and nothing else. -- bill@unixland.uucp The Think_Tank BBS & Public Access Unix ...!uunet!think!unixland!bill ..!{uunet,bloom-beacon,esegue}!world!unixland!bill 508-655-3848 (2400) 508-651-8723 (9600-HST) 508-651-8733 (9600-PEP-V32)
randy@chinet.chi.il.us (Randy Suess) (05/02/91)
In article <1991May1.153257.18685@bradley.bradley.edu> fred@bradley.bradley.edu (Fred Jaggi) writes:
]i'm trying to do performance graphs of some 6386 machines running UNIX
]System V R 3.2.2, but sar -d doesn't show me anything. this seems to
]be the case for all the machines with ESDI drives (SCSI and IDE seem
]to work just fine). is there any fix available for this?
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.
-randy
--
Randy Suess
randy@chinet.chi.il.usurban@cbnewsl.att.com (john.urban) (05/03/91)
In article <1991May02.135710.7757@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes: >In article <1991May1.153257.18685@bradley.bradley.edu> fred@bradley.bradley.edu (Fred Jaggi) writes: >]i'm trying to do performance graphs of some 6386 machines running UNIX >]System V R 3.2.2, but sar -d doesn't show me anything. this seems to >]be the case for all the machines with ESDI drives (SCSI and IDE seem >]to work just fine). is there any fix available for this? > > 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. ^^^^^^^^^^^^^^^^^^^^^^ |||||||||||||||||||||| What's everything else? > > -randy > >-- John Urban att!garage!jbu
randy@chinet.chi.il.us (Randy Suess) (05/04/91)
In article <1991May3.131449.29943@cbnewsl.att.com> urban@cbnewsl.att.com (john.urban) writes: >> sar -d is broke in most (all?) 386 unix's. Seems no-one >> fix it in their 3.2.3 release, but broke everything else. > ^^^^^^^^^^^^^^^^^^^^^^ >What's everything else? Try "sar 2 9999" or any continuous output parameter. Runs for either 8 or 16 iterations then core dumps. AT&T says "oops, use the older version." Also, a number of commands produce erroneous output, consisting of a "." followed by 5-16 numbers where an integer is expected. Also, sag -Ttek has *never* worked. Outputs numbers in the middle of the graph instead of lines and points. Depends on the -s and -e times and how much data there is. -randy -- Randy Suess randy@chinet.chi.il.us
woods@eci386.uucp (Greg A. Woods) (05/04/91)
In article <1991May02.135710.7757@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes: > In article <1991May1.153257.18685@bradley.bradley.edu> fred@bradley.bradley.edu (Fred Jaggi) writes: > ]i'm trying to do performance graphs of some 6386 machines running UNIX > ]System V R 3.2.2, but sar -d doesn't show me anything. this seems to > ]be the case for all the machines with ESDI drives (SCSI and IDE seem > ]to work just fine). is there any fix available for this? > > 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. It's not a matter of converting 3b2 drivers, (though the 3b2 drivers do indeed work correctly) but rather a matter of a very few simple lines of code in the 386 drivers to update the system accounting records. Some people are just plain lazy. Then again, I don't recall any clear documentation in the BCI Guide that tells what needs to be done... It's real easy for char drivers, since the line discipline usually takes care of the accounting, but block drivers, if I understand correctly, must do it on their own. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
dewey@dell.dell.com (Dewey Coffman) (05/05/91)
In article <1991May02.135710.7757@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes: In article <1991May1.153257.18685@bradley.bradley.edu> fred@bradley.bradley.edu (Fred Jaggi) writes: ]i'm trying to do performance graphs of some 6386 machines running UNIX ]System V R 3.2.2, but sar -d doesn't show me anything. this seems to ]be the case for all the machines with ESDI drives (SCSI and IDE seem ]to work just fine). is there any fix available for this? randy> sar -d is broke in most (all?) 386 unix's. Seems no-one randy> is able to convert the 3b2 based routines in sar for disk randy> monitoring to the pc-bused controllers. AT&T tried to randy> fix it in their 3.2.3 release, but broke everything else. randy> -randy This is fixed in V.4 for 386 unix's. dewey -- Dewey Coffman UUCP: dell!sooner!dewey, cs.utexas.edu!dell!sooner!dewey
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (05/08/91)
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
randy@chinet.chi.il.us (Randy Suess) (05/09/91)
In article <3872@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: ]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?) Sorry, I guess I meant "All AT&T based UNIX's" Also, just checked it on my new AT&T sysvr4 v2.1 system and all the bugs I know about including -d are fixed. -- Randy Suess randy@chinet.chi.il.us