gettimeofday() resolution in Linux? - Kernel

This is a discussion on gettimeofday() resolution in Linux? - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: gettimeofday() resolution in Linux?

  1. gettimeofday() resolution in Linux?

    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!
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: gettimeofday() resolution in Linux?

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: gettimeofday() resolution in Linux?

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: gettimeofday() resolution in Linux?

    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

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: gettimeofday() resolution in Linux?

    On Thu, Apr 10, 2008 at 4:04 PM, Lennart Sorensen
    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
    >

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: gettimeofday() resolution in Linux?

    On Thu, Apr 10, 2008 at 4:40 PM, 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.
    > 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: gettimeofday() resolution in Linux?

    On Thu, Apr 10, 2008 at 5:59 PM, Jack Harvard
    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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: gettimeofday() resolution in Linux?

    On Thu, Apr 10, 2008 at 7:57 PM, Jack Harvard
    wrote:
    > On Thu, Apr 10, 2008 at 6:41 PM, Bart Van Assche
    > wrote:
    > > On Thu, Apr 10, 2008 at 5:59 PM, Jack Harvard
    > > 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread