Bug 19153

Hmm, I just found another version of iostat, hidden at
ftp://ftp.uk.linux.org/pub/linux/sct/fs/profiling

It seems to be totally different?

BUT, it seems to work correctly and offers the following beautiful statistic:
"average request service time".
example:
         hda          hda1          hda2          hda3          hda4         
hda5          cpu
k/s t/s serv  k/s t/s serv  k/s t/s serv  k/s t/s serv  k/s t/s serv  k/s t/s
serv   us  sy  id
13624 107 36.6    0   0  0.0    0   0  0.0    0   0  0.0    0   0  0.0    0   0 
0.0    2  21  76
14590 116 37.0    0   0  0.0   16   0  0.0    0   0  0.0    0   0  0.0    0   0 
0.0    3  19  78

nifty, eh? That's 14Mb/sec and ~100 requests per second at ~40ms service time
each.
It's generated by "dd" from /dev/hda to /dev/null with 1024Mb blocksize.

Ideally, I'd like to see an iostat which:
a) Works
b) Offers the above "average service time in ms" statistic
c) Offers the %iowait statistic
d) Ideally would offer the average queue depth statistic
e) Offers the standard "kb/sec" and "req/sec" statistics

Unfortunately, that would seem to require a combination of the two different
iostat
programs.

OK!! These are indeed two different "iostat" programs.
Unfortunately, it seems that RH7.0 ships with the wrong one.
Playing with the one I mention above at ftp.uk.linux.org, it _does_ seem to
satisfy all the requirements I list above!

Stephen - can you point me to where the iostat.c file came from? I'd like to fix
a few bugs/uglies, and I'd like to base my work on the most recent version!

I'd suggest that this might warrant an update once the proper iostat.c has
been prettified.

I've already fixed a couple of the iostat/systat versions out there for the
cleaned-up sard output, and I'll do the necessary for this one once I'm back in
the UK next week.

Can I volunteer to review the fixed packages?

iostat  from sysstat-3.3.3-2 from the RHL7.1 beta2 displays no IO activity for
the following command:
dd if=/dev/sda5 of=/dev/null bs=72k, and in fact iostat freezes and no longer
updates the display.

The problem is now two fold
1) The 2.4 kernel hasn't been patched with the enhance i/o statistics patch from
2.2 yet
- This needs doing, or you've screwed people relying on RH7.0 advanced
statistics
2) The default iostat program does not expose the cool enhanced statistics
available.
- The alternative iostat I quote above is better in this regard.

the new iostat is not broken anymore, but it doesn't do as much as the iostat
you reference.  However, it is maintained and works well in other ways.

I have forwarded on the iostat.c file you referenced to the maintainer of the
version we are currently shipping so that he may merge the two.

I just spotted something very interesting on
comp.os.linux.announce. It's a new iostat version.
In the author's own words:
---
There are two interesting things coming with sysstat-3.3.5:
1) The iostat command has been greatly improved and now takes full
advantage of Stephen Tweedie's kernel patch to display extended I/O
statistics.
---

However, also note (also from the author):
---
Please note that version 3.3.5 is a development release. The latest
stable version is still 3.2.4.
---
ftp://metalab.unc.edu/pub/Linux/system/status/
80kB  sysstat-3.3.5.tar.gz

we are up to this version in rawhide, and it appears very stable.  I've been
cooperating with the author.

Nice one. Wolverine has this version, it seems.
.
One nitpick: the %util value is scaled incorrectly - it ranges from 0% to 1000%,
i.e. a factor of 10 out.
I'm not re-opening the bug for such a minor point, but it would be nice to
get it fixed.

The ticks output in current sard patches is biased to output 1000 ticks per
second: in other words, it is no longer dependent on "HZ".  This means that the
same parser will work correctly for both Intel and for architectures such as
Alpha where HZ=1000.

A guy pointed me that avg wait times and service times as displayed
by 'iostat -x' were wrong. On his RedHat system running 'iostat -x 10',
he gets values of about 200-400 ms and higher. It seems to be too high
by an order of magnitude, since the SCSI/Fc controller in his Compaq
and IBM machines are musch faster, there was I/O load contention, etc.

He sent me a very small patch (below) to fix this but that I am unable
to integrate in sysstat because I lack knowledge on the way kernel and
sct's patch work.
Could you tell me if this patch is acceptable and if I can apply it to sysstat?

--- sysstat-4.0.3-orig/iostat.c Fri Feb 11 14:15:19 2002
+++ sysstat-4.0.3/iostat.c      Thu Feb 14 11:30:05 2002
@@ -372,7 +372,8 @@
               tput   = nr_ios * HZ / itv;
               util   = ((double) current.ticks) / itv;
               svctm  = tput ? util / tput : 0.0;
-              await  = nr_ios ? (current.rd_ticks + current.wr_ticks) / nr_ios
* 1000.0 / HZ : 0.0;
+              /* kernel gives ticks already in milliseconds for all platforms
-> no need for further scaling */
+              await  = nr_ios ? (current.rd_ticks + current.wr_ticks) / nr_ios
: 0.0;
               arqsz  = nr_ios ? (current.rd_sectors + current.wr_sectors) /
nr_ios : 0.0;
 
               printf("/dev/%-5s", disk_hdr_stats[disk_index].name);
@@ -387,7 +388,8 @@
                      arqsz,
                      ((double) current.aveq) / itv,
                      await,
-                     svctm * 1000.0,
+                     /* again: ticks in milliseconds */
+                     svctm * 100.0,
                      /* NB: the ticks output in current sard patches is biased
to output 1000 ticks per second */
                      util * 10.0);
            }

Problem concerns every platforms with recent RedHat and sysstat installed.
Thx a lot for your help.