gettimeofday() resolution in Linux?

gettimeofday() resolution in Linux?

[Jack Harvard]

Hi,

I would like to ask a few questions about how Linux keeps time.

As far as I understand,
1. Linux's time resolution is 10ms, as defined by HZ=100.
2. gettimeofday() can get time in microseconds, but I'm not sure about
the accuracy of the time finer than 10ms. Sometimes gettimeofday( )
can even give me microseconds results rolled backwards in time, which
I suspect could be caused by its accuracy. My question here is "how
accurate is the time from gettimeofday()"
3. If I want to increase the time resolution to 1ms, I can possibly
change HZ=1000, but if I want 1usec resolution, how can I do that? It
would be too busy for the processor to handle so frequent timer
interrupts if I just increase HZ=1000000.

Many thanks/muchas gracias/Danke vielmals!

Re: gettimeofday() resolution in Linux?

[Lennart Sorensen]

On Thu, Apr 10, 2008 at 03:40:59PM +0100, Jack Harvard wrote:
> I would like to ask a few questions about how Linux keeps time.
> 
> As far as I understand,
> 1. Linux's time resolution is 10ms, as defined by HZ=100.

The timer resolution, not the time resolution.

> 2. gettimeofday() can get time in microseconds, but I'm not sure about
> the accuracy of the time finer than 10ms. Sometimes gettimeofday( )
> can even give me microseconds results rolled backwards in time, which
> I suspect could be caused by its accuracy. My question here is "how
> accurate is the time from gettimeofday()"

On many systems gettimeofday uses the TSC, but on many multicore systems
the TSC on each core may be out of sync, in which case the cpu you are
running on may give a different gettimeofday result than another cpu,
which is probably a bad thing for some processes.

> 3. If I want to increase the time resolution to 1ms, I can possibly
> change HZ=1000, but if I want 1usec resolution, how can I do that? It
> would be too busy for the processor to handle so frequent timer
> interrupts if I just increase HZ=1000000.

I don't think that would work well.

-- 
Len Sorensen

Re: gettimeofday() resolution in Linux?

[Andi Kleen]

lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:
>
> On many systems gettimeofday uses the TSC, but on many multicore systems
> the TSC on each core may be out of sync, in which case the cpu you are
> running on may give a different gettimeofday result than another cpu,
> which is probably a bad thing for some processes.

In this case Linux falls back to other timers which are slower and 
less accurate.

jiffies based gettimeofday is theoretically possible, but near
never used.

-Andi

Re: gettimeofday() resolution in Linux?

[Jack Harvard]

On Thu, Apr 10, 2008 at 4:04 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Thu, Apr 10, 2008 at 03:40:59PM +0100, Jack Harvard wrote:
>  > I would like to ask a few questions about how Linux keeps time.
>  >
>  > As far as I understand,
>  > 1. Linux's time resolution is 10ms, as defined by HZ=100.
>
>  The timer resolution, not the time resolution.
>

ahh...that's right, gettimeofday resolution can be 1/f_proc_clk, which
will certainly be finer than 1us for processors clocked at 1mhz or
above. thanks a lot...

>
>  > 2. gettimeofday() can get time in microseconds, but I'm not sure about
>  > the accuracy of the time finer than 10ms. Sometimes gettimeofday( )
>  > can even give me microseconds results rolled backwards in time, which
>  > I suspect could be caused by its accuracy. My question here is "how
>  > accurate is the time from gettimeofday()"
>
>  On many systems gettimeofday uses the TSC, but on many multicore systems
>  the TSC on each core may be out of sync, in which case the cpu you are
>  running on may give a different gettimeofday result than another cpu,
>  which is probably a bad thing for some processes.
>
>

Perhaps X86 processors work like this - using the TSC for
gettimeofday, how about ARM processors? how can i determine how
reliable the results are from gettimeofday for arm?  i.e., whether
they are of microsecond accuracy or otherwise...

Here is an example of gettimeofday results, the time rolls back
sometimes...first timestamp is start time...second timestamp is end
time
# # ./gettimeofday
timestamp (us): 215922277
timestamp (us): 215923120 (diff) 843
# # ./gettimeofday
timestamp (us): 216158623
timestamp (us): 216153181 (diff) -5442
# # ./gettimeofday
timestamp (us): 216430758
timestamp (us): 216423223 (diff) -7535
# # ./gettimeofday
timestamp (us): 216665947
timestamp (us): 216663171 (diff) -2776
# # ./gettimeofday
timestamp (us): 216944243
timestamp (us): 216943023 (diff) -1220

>  > 3. If I want to increase the time resolution to 1ms, I can possibly
>  > change HZ=1000, but if I want 1usec resolution, how can I do that? It
>  > would be too busy for the processor to handle so frequent timer
>  > interrupts if I just increase HZ=1000000.
>
>  I don't think that would work well.
>
>  --
>  Len Sorensen
>

Re: gettimeofday() resolution in Linux?

[Bart Van Assche]

On Thu, Apr 10, 2008 at 5:59 PM, Jack Harvard
<jack.harvard@googlemail.com> wrote:
>  Here is an example of gettimeofday results, the time rolls back sometimes.

If the result of gettimeofday() rolls back, and there is no process on
your system that sets the time (like ntpd or hwclock --hctosys) then
this is a kernel bug. Which kernel version are you using, and which
kernel patches have been applied to that kernel ?

Bart.

Re: gettimeofday() resolution in Linux?

[Bart Van Assche]

On Thu, Apr 10, 2008 at 7:57 PM, Jack Harvard
<jack.harvard@googlemail.com> wrote:
> On Thu, Apr 10, 2008 at 6:41 PM, Bart Van Assche
>  <bart.vanassche@gmail.com> wrote:
>  > On Thu, Apr 10, 2008 at 5:59 PM, Jack Harvard
>  > <jack.harvard@googlemail.com> wrote:
>  >
>  > >  Here is an example of gettimeofday results, the time rolls back sometimes.
>  >
>  >  If the result of gettimeofday() rolls back, and there is no process on
>  >  your system that sets the time (like ntpd or hwclock --hctosys) then
>  >  this is a kernel bug. Which kernel version are you using, and which
>  >  kernel patches have been applied to that kernel ?
>
>  It's an embedded system with an ARM processor, uname -a give the following info:
>  Linux (none) 2.6.21-arm1-t2_1 #20 Thu Apr 10 15:20:46 BST 2008 armv6l unknown

Where did the kernel sources come from -- from kernel.org or from an
company that modified the kernel ? Most companies that offer support
for Linux on embedded devices modify the kernel with e.g. hard
real-time support and high resolution timers. It is easy to introduce
bugs by doing so.

Bart.

Re: gettimeofday() resolution in Linux?

[Chris Friesen]

Jack Harvard wrote:

> 1. Linux's time resolution is 10ms, as defined by HZ=100.

As others have said, this is not the time resolution, but the tick time. 
  In other words, this is the smallest amount of sleep that you can 
normally ask for, but you can obtain a timestamp with much more accuracy.

> 2. gettimeofday() can get time in microseconds, but I'm not sure about
> the accuracy of the time finer than 10ms.

Barring bugs, it should be accurate to microseconds.

> Sometimes gettimeofday( )
> can even give me microseconds results rolled backwards in time, which
> I suspect could be caused by its accuracy. My question here is "how
> accurate is the time from gettimeofday()"

This is due to bugs.  There was a recent thread called "gettimeofday() 
jumping into the future" which just fixed a problem in this area, and 
there have been other such issues in the past.  In particular, I think 
AMD multicore systems don't sync the TSC on the cores.

Usually it's possible to force the system to use something other than 
the TSC for timestamping.  This is generally somewhat slower but less 
likely to be buggy.

Chris

Re: gettimeofday() resolution in Linux?

[Bart Van Assche]

On Thu, Apr 10, 2008 at 4:40 PM, Jack Harvard
<jack.harvard@googlemail.com> wrote:
>  I would like to ask a few questions about how Linux keeps time.
>
>  As far as I understand,
>  1. Linux's time resolution is 10ms, as defined by HZ=100.
>  2. gettimeofday() can get time in microseconds, but I'm not sure about
>  the accuracy of the time finer than 10ms. Sometimes gettimeofday( )
>  can even give me microseconds results rolled backwards in time, which
>  I suspect could be caused by its accuracy. My question here is "how
>  accurate is the time from gettimeofday()"
>  3. If I want to increase the time resolution to 1ms, I can possibly
>  change HZ=1000, but if I want 1usec resolution, how can I do that? It
>  would be too busy for the processor to handle so frequent timer
>  interrupts if I just increase HZ=1000000.

You should use clock_gettime(CLOCK_MONOTONIC) instead of
gettimeofday() for interval timing. As soon as NTP software is
running, the result of gettimeofday() can jump forward or backward in
time. The result of clock_gettime() is guaranteed to be monotonic, and
additionally the resolution of clock_gettime() is higher than
gettimeofday() -- 1 ns instead of 1 us.

Changing HZ only makes sense on very old hardware that does not have a
TSC or equivalent register (e.g. the Intel 486 CPU).

Bart.