Gecko [ 122.154.134.11 ]

Name	Size	Permission
examples	[ DIR ]	drwxr-xr-x
AUTHORS	28 B	-rw-r--r--
COPYING	17.57 KB	-rw-r--r--
ChangeLog	16.32 KB	-rw-r--r--
README	1.52 KB	-rw-r--r--
TODO	3.9 KB	-rw-r--r--
counter-rollovers.html	14.24 KB	-rw-r--r--
counter-rollovers.txt	2.6 KB	-rw-r--r--
cplugins.html	11.53 KB	-rw-r--r--
cplugins.txt	305 B	-rw-r--r--
dstat-paper.html	53.72 KB	-rw-r--r--
dstat-paper.txt	31.3 KB	-rw-r--r--
dstat.1.html	28.46 KB	-rw-r--r--
dstat.1.txt	9.52 KB	-rw-r--r--
examples.html	11.85 KB	-rw-r--r--
examples.txt	547 B	-rw-r--r--
performance.txt	1.84 KB	-rw-r--r--
screen.html	13.09 KB	-rw-r--r--
screen.txt	1.44 KB	-rw-r--r--

Code Editor : counter-rollovers.txt

All you ever wanted to know about counter-rollovers and dstat
=============================================================

What you need to know about counter rollovers
---------------------------------------------
Unfortunately, dstat is susceptible for counter rollovers, which may give
you bogus performance output. Linux currently implements counters as 32bit
values (not sure on 64bit platforms). This means a counter can go up to
2^32 (= 4294967296 = 4G) values.

Especially for network devices (which are calculated in bytes) this is too
much as it means every 4GB, the counter is reset to 0. On a 1Gbps interface
that is fully used, this happens every 32 seconds. On 2 bonded 10Gbps
interfaces, this happens after 1.6 seconds.

Since /proc is updated every second, this becomes almost impossible to catch.

How does this impact dstat ?
----------------------------
Currently dstat has a problem if you specify delays that are too big. I.e.
using 60 or 120 seconds delay in dstat will make dstat check these counters
only once per minute or every two minutes. In the case the value is reset,
it might be lower than the previous value (which causes negative values) or
worse, the value is actually higher (which will go unnoticed and you get
bogus information and dstat won't know).

This is very problematic, and it's important you are aware of this.

What are the solutions ?
------------------------
The only fix for dstat is to check more often than the specified delay.
Unfortunately, this requires a re-design (or an ugly hack).

There are plans to use 64bit counters on Linux and/or changing the output from
using bytes to kbytes. None of this is sure. (add pointers to threads)

To work-around this problem, you could always use a delay of 1 second, and
re-calculate averages in Excel. This will work fine as long as you also
re-calculate the negative values (by adding 2^32 to them).

If the rollovers happen only sporadically, you can just ignore those values.

What can I do ?
---------------
Since this is Open Source, you are free to fix this and send me the fix. Or
help with a redesign of dstat to overcome this problem. Also look at the
TODO file to see what other changes are expected in a redesign of dstat.

Since I have a lot of other responsibilities and am currently not using dstat
for something where this problem matters much, I will have no time to look at
it closely (unless the fix or the redesign is made fairly simple). It all
depends on how quick I think I can fix/redesign it and how much time I have.

Your help could be to reduce the time it takes for me to fix it :)

NOTE: Please send me improvements to this document.

${this.title}

Code Editor : counter-rollovers.txt