On Sun, 23 Mar 2008, Dag Wieers wrote:
Sam, could you please retry the version from subversion ?
We made some changes to the scheduling code which triggered this bug on a
stopped terminal. The problem is that on 2 different positions in time it
returns exctly the same number of ticks, which normally should not happen.
This means that either the cpu did not do anything in between (like when you
hibernate or suspend your system) or the 2 positions in time are very close
to each other (which is again weird since we have at least 1 second
intervals).
I noticed that also on VMware, where time and cpu ticks can be variable (they
synchronise time each minute and gradually correct time, which means that
when dstat thinks it is 1 second later, in fact it only is a fw milliseconds
later, alas the problem...)
I can imagine that a variable cpu speed can impact this problem as well.
But now it is fixed and dstat will show when it is loosing ticks and how
many. This is easy to trigger by stopping your terminal (ctrl-s) for about 15
seconds or by suspending your computer with dstat running.
I am interested to hear how it works for you.
BTW Thanks for reporting this bug !
Since the dstat 0.6.8 release this code was released. So again, I think
this bug should be closed and reopened if some new information appears.
Andrew, can you close this one as well ?
Thanks !
--
-- dag wieers, [EMAIL PROTECTED], http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
