negative response time with gettimeofday
yuanh...@gmail.com
getting.
Surely i'm doing something silly but cannot find it.
code:
struct timeval tvStart,tvEnd;
double linStart = 0,linEnd = 0,lTime = 0;
gettimeofday (&tvStart,NULL);
//do something
gettimeofday (&tvEnd,NULL);
linStart = ((double)tvStart.tv_sec * 1000000 +
(double)tvStart.tv_usec); //unit S
linEnd = ((double)tvEnd.tv_sec * 1000000 +
(double)tvEnd.tv_usec); //unit S
lTime = linEnd-linStart;
if(lTime <= 0)
{
.......
}
But lTime is negative rarely;
Linux version 2.4.21-37.ELsmp (gcc version 3.2.3 20030502 (Red Hat
Linux 3.2.3-53)) #10 SMP Fri Apr 28 00:06:06 CST 2006
Thanks for any help
David Schwartz
> I hope someone can help me with negative time measurements > I am
> getting.
> Surely i'm doing something silly but cannot find it.
>
> code:
> struct timeval tvStart,tvEnd;
> double linStart = 0,linEnd = 0,lTime = 0;
>
> gettimeofday (&tvStart,NULL);
You are using the wrong function. The 'gettimeofday' function gets the
system's best guess at wall time. This *can* go backwards. What you
want is 'clock_gettime(CLOCK_MONOTONIC)' which measures the elaspsed
time from an arbitrary reference time. (Usually the system uptime, but
that's not guaranteed.)
DS
Bin Chen
As I know, the Linux kernel read the system RTC(wall time) and then
maintain the Wall time through OS timer, but why the gettimeofday not
accurate?
>
> DS
David Schwartz
> As I know, the Linux kernel read the system RTC(wall time) and then
> maintain the Wall time through OS timer, but why the gettimeofday not
> accurate?
What makes you think it's not accurate?
DS
Bin Chen
it accurate. Oh, yes, it is wrong.
>
> DS
Jan Panteltje
wrote in <1171249570.4...@p10g2000cwp.googlegroups.com>:
Try the same with long, not duble;
unsigned long lstart_usecs, lcurrent_usecs, ldiff_usecs;
lcurrent_usecs =\
current_timeval -> tv_usec + (1000000 * current_timeval -> tv_sec);
lstart_usecs =\
start_timeval -> tv_usec + (1000000 * start_timeval -> tv_sec);
ldiff_usecs = lcurrent_usecs - lstart_usecs;
David Schwartz
> > What makes you think it's not accurate?
> You said that it can go backwards. If it will go back of the
> time, is
> it accurate. Oh, yes, it is wrong.
The purpose of 'gettimeofday' is to get the system's best guess at
actual wall clock time. This can go backwards.
For example, suppose you check the time on a very accurate clock. It
reads "10:03". About 40 minutes pass and I ask you what time it is.
You say, "my best guess is 10:43". Then you look at the clock again
and see it is 10:31. I ask you what time it is about a minute later
and you say, "my best guess is 10:32".
In both cases you accurately gave me your best estimate of wall clock
time. Nevertheless, the time went backwards.
You can ask for a time that is guaranteed monotonic or you can ask for
the best guess of wall time, but there is no way to get both at the
same time. The function you are using requests the system's best guess
at actual wall clock time, and it can be working perfectly and still
go backwards.
DS
Bin Chen
> On Feb 12, 2:02 am, "Bin Chen" <binary.c...@gmail.com> wrote:
>
> > > What makes you think it's not accurate?
> > You said that it can go backwards. If it will go back of the
> > time, is
> > it accurate. Oh, yes, it is wrong.
>
> The purpose of 'gettimeofday' is to get the system's best guess at
> actual wall clock time. This can go backwards.
>
> For example, suppose you check the time on a very accurate clock. It
> reads "10:03". About 40 minutes pass and I ask you what time it is.
> You say, "my best guess is 10:43". Then you look at the clock again
> and see it is 10:31. I ask you what time it is about a minute later
> and you say, "my best guess is 10:32".
>
> In both cases you accurately gave me your best estimate of wall clock
> time. Nevertheless, the time went backwards.
>
> You can ask for a time that is guaranteed monotonic or you can ask for
> the best guess of wall time, but there is no way to get both at the
> same time. The function you are using requests the system's best guess
> at actual wall clock time, and it can be working perfectly and still
> go backwards.
>
> DS
I have some questions after I dive into the kernel source, as you
said, the kernel just estimate the time when you call the
gettimeofday(). I remember this *guess* is done by accumulating each
jiffy that created by OS timer.
But I don't find the code that kernel read the RTC(wall time) to
calibrate the guessed value. If all the time the kernel is guessing,
there is no reason that it guess backwards.
David Schwartz
> I have some questions after I dive into the kernel source, as you
> said, the kernel just estimate the time when you call the
> gettimeofday(). I remember this *guess* is done by accumulating each
> jiffy that created by OS timer.
Correct.
> But I don't find the code that kernel read the RTC(wall time) to
> calibrate the guessed value.
It tracks wall time itself in most hardware configurations you are
likely to encounter. If the TSC is usable, it will periodically work
out calibration values to convert the TSC to wall time.
> If all the time the kernel is guessing,
> there is no reason that it guess backwards.
If you need/want monotonic time, there are functions for that. But
'gettimeofday' *specifically* gives up monotonicity in exchange for a
better estimate of wall time.
There are plenty of reasons it guesses backwards. The kernel usually
has at least two time sources, one that indicates time boundaries and
one that indicates time passage. If the source of time passage speeds
up a bit, the next boundary may result in the time going a bit
backwards.
For example, suppose someone tells you the time periodically (this is
like the timer interrupt). You also calibrate your own clock (this is
like the TSC). If the TSC speeds up a bit, you might think it's 10:01
when you're told it's 10:00. You'll immediately slow your own clock
down to compensate, but at that instant, your best guess of wall time
will go backwards.
Simply put, having monotonicity (never going backwards) and making the
best possible guess of wall clock time are *conflicting* requirements.
You specifically used the function that trades one for the other.
DS
Bin Chen
> On Feb 12, 4:35 am, "Bin Chen" <binary.c...@gmail.com> wrote:
>
> > I have some questions after I dive into the kernel source, as you
> > said, the kernel just estimate the time when you call the
> > gettimeofday(). I remember this *guess* is done by accumulating each
> > jiffy that created by OS timer.
>
> Correct.
>
> > But I don't find the code that kernel read the RTC(wall time) to
> > calibrate the guessed value.
>
> It tracks wall time itself in most hardware configurations you are
> likely to encounter. If the TSC is usable, it will periodically work
> out calibration values to convert the TSC to wall time.
>
so that the HZ to be generated a little faster or slower? Or it just
generate a periodic timer interrupt that let kernel know a given time
has passed? If the latter, which interrupt will service this?
> > If all the time the kernel is guessing,
> > there is no reason that it guess backwards.
>
> If you need/want monotonic time, there are functions for that. But
> 'gettimeofday' *specifically* gives up monotonicity in exchange for a
> better estimate of wall time.
directly each time the gettimeofday is called.
jasen
> I hope someone can help me with negative time measurements I am
> getting.
> Surely i'm doing something silly but cannot find it.
I saw something similar doing milisecond timestamps in DOS, it was due to, hardware
differences in the timer chip implementation on different PCs,
In other words it sounds like a kernel bug that's only apparent on certain
hardware.
IIRC the microsecond time code on snippets.org worked everywhere
Jasen
David Schwartz
> I don't know why it is a *good* estimation compare to read the RTC
> directly each time the gettimeofday is called.
There are at least three reasons the RTC is not used:
The RTC resolution varies but is seldom better than 1/18th of a
second. In contrast, the TSC or HPET can have nanosecond resolution.
(You are asking for the system's best guess of wall clock time, why
should it return something that is *not* that?)
Second, the RTC is very expensive to read. It takes quite a bit of I/O
to read the RTC and 'gettimeofday' can be very frequently called in
some applications (for example consider a server streaming multimedia
over UDP). In comparison, reading the TSC takes one instruction.
Third, the RTC is notoriously inaccurate and cannot really be
disciplined, largely because of its low resolution. In comparison, the
other time sources are much more stable and have enough resolution to
be disciplined.
I believe most modern computers read the RTC only on startup.
DS
David Schwartz
> I have no idea how it works. It will calibrate the OS timer hardware
> so that the HZ to be generated a little faster or slower? Or it just
> generate a periodic timer interrupt that let kernel know a given time
> has passed? If the latter, which interrupt will service this?
It depends upon the exact timing configuration being used. But let's
take a typical one -- TSC and HPET with no external time reference (no
NTP or the like). In this case, every time the HPET generates an
interrupt, the computer will do the following (oversimplified, sorry):
1) Sanity check against the TSC to make sure we didn't lose any HPET
interrupts. If we did, we have to fix things up.
2) Adjust our base time to the previous base time plus the interval
between HPET interrupts. Save the current TSC value as the base TSC
value.
3) Calculate how many TSC ticks have elapsed and adjust our estimate
of the TSC rate based on that many TSC ticks per HPET interval.
Then when you call 'gettimeofday', it does the following:
1) Get the TSC value and subtract the saved TSC values. This tells it
how many TSC ticks have passed since the last HPET interrupt.
2) Multiply by the TSC rate calculate at the last HPET interrupt to
figure out how much time has passed since the last HPET interrupt.
3) Add that to the base time of the last HPET interrupt.
Note that if we lose HPET interrupts (which can happen if anything
keeps interrupts disabled for too long), it is quite possible for our
best guess of wall time to go backwards.
DS