Time measurements - Unix

This is a discussion on Time measurements - Unix ; Andrei Voropaev wrote: > I'm asking this question because I was bitten one time by the > situation when the admin set the time 10 minutes behind and my program > that was using gettimeofday got really confused So, is ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: Time measurements

  1. Re: Time measurements

    Andrei Voropaev wrote:
    > I'm asking this question because I was bitten one time by the
    > situation when the admin set the time 10 minutes behind and my program
    > that was using gettimeofday got really confused So, is the
    > CLOCK_REALTIME immune to this? Or it is safer to rely on
    > CLOCK_MONOTONIC?


    If you care about actual wall time then use CLOCK_REALTIME or
    gettimeofday(). This is useful if you want an action to happen at a
    specific time of day (or date), regardless of actual interval. (So
    setting the system time forward/backward could trigger the action, for
    instance.)

    If you care about intervals, and don't care about actual time of day,
    then use CLOCK_MONOTONIC.

    Chris

  2. Re: Time measurements

    On 2007-10-12, Rainer Weikusat wrote:
    > Andrei Voropaev writes:

    [...]
    >> I'm asking this question because I was bitten one time by the
    >> situation when the admin set the time 10 minutes behind and my program
    >> that was using gettimeofday got really confused .

    [...]
    >> So, is the CLOCK_REALTIME immune to this? Or it is safer to rely on
    >> CLOCK_MONOTONIC?

    >
    > Why do pretend to ask questions with implied, obvious answers?
    > No amount of smoke and mirrors will ever protect a program from admin
    > intervention intended to break it.


    Well. Your attitude is strange. If the time has to be adjusted it has to
    be adjusted. The programs that measure time intervals should not suffer
    from this. They don't need absolute time, they need just intervals. So
    I'm trying to understand the words from the manpage that states that
    CLOCK_REALTIME provides reliable interval measurements. Nothing else.

    --
    Minds, like parachutes, function best when open

  3. Re: Time measurements

    Andrei Voropaev writes:
    > On 2007-10-12, Rainer Weikusat wrote:
    >> Andrei Voropaev writes:

    > [...]
    >>> I'm asking this question because I was bitten one time by the
    >>> situation when the admin set the time 10 minutes behind and my program
    >>> that was using gettimeofday got really confused .

    > [...]
    >>> So, is the CLOCK_REALTIME immune to this? Or it is safer to rely on
    >>> CLOCK_MONOTONIC?

    >>
    >> Why do pretend to ask questions with implied, obvious answers?
    >> No amount of smoke and mirrors will ever protect a program from admin
    >> intervention intended to break it.

    >
    > Well. Your attitude is strange. If the time has to be adjusted it
    > has to be adjusted.


    I see nothing particularly 'strange' in the assumption that the
    purpose of a clock is to measure time.

  4. Re: Time measurements

    Rainer Weikusat wrote:
    > Andrei Voropaev writes:
    >> On 2007-10-12, Rainer Weikusat wrote:
    >>> Andrei Voropaev writes:

    >> [...]
    >>>> I'm asking this question because I was bitten one time by the
    >>>> situation when the admin set the time 10 minutes behind and my program
    >>>> that was using gettimeofday got really confused .

    >> [...]
    >>>> So, is the CLOCK_REALTIME immune to this? Or it is safer to rely on
    >>>> CLOCK_MONOTONIC?
    >>> Why do pretend to ask questions with implied, obvious answers?
    >>> No amount of smoke and mirrors will ever protect a program from admin
    >>> intervention intended to break it.

    >> Well. Your attitude is strange. If the time has to be adjusted it
    >> has to be adjusted.

    >
    > I see nothing particularly 'strange' in the assumption that the
    > purpose of a clock is to measure time.


    Time is a relative measurement. Change your velocity and you change how you
    measure it compared to someone else. (We have gotten to the point where a clock
    at the pole vs a clock at the equator is a measurable difference.) So here is
    your question, what is time = 0? Was that 10, 15 or 20 billion years ago to the
    big bang? Your absolute clock time could be in error by 10 billion years! You
    can measure intervals from now forward. You can't measure it absolutely, but
    you can count how many ticks pass. And I'm not just talking about on a
    computer, but using any measuring device you choose. Anyone can come along and
    move the stick for the starting point (admin changing the wall clock time, a
    leap second or even a Pope decreeing some number of days aren't in this year's
    calendar) and you are hosed.

    If you want stuff to happen on wall clock times, use the system to figure it out
    and assume it is only as good as you getting to work on time. (It is usually a
    lot better.) If you want stuff to happen some interval later, use an interval
    measurement and ignore the wall clock. If you need that interval to survive a
    reboot, well you have no choice but to use the wall clock because the interval
    timer gets is absolute zero point (epoch) from the wall clock timer. Sometimes
    you have to write your programs to accept dirty input.

    Since it is possible to have a file out there that has a time stamp from one
    system that is not in agreement with other systems (never mind maliciously set
    wrong), if your program depends on it being so, you had better not allow your
    program to run until you have satisfied that isn't the case. Maybe you need a
    daemon to keeps the clocks consistent. Maybe you yourself have to use only one
    clock for time stamps.

    Think of your granularity. Is it critical to nano seconds or is it critical to
    ten minutes. That can make your choice much easier. If you are mission
    critical on time being correct (to your granularity) then you have to assure
    that. Unix does not and does not care. Like it doesn't care if you have a
    buffer overflow. Do what you must. Attach an external clock to the hardware
    and use it and only it as your time reference. Or maybe you set off a dozen
    peoples pagers if you detect an error in time. Just do what you need to.


  5. Re: Time measurements

    Golden California Girls writes:
    > Rainer Weikusat wrote:
    >> Andrei Voropaev writes:
    >>> On 2007-10-12, Rainer Weikusat wrote:
    >>>> Andrei Voropaev writes:
    >>> [...]
    >>>>> I'm asking this question because I was bitten one time by the
    >>>>> situation when the admin set the time 10 minutes behind and my program
    >>>>> that was using gettimeofday got really confused .
    >>> [...]
    >>>>> So, is the CLOCK_REALTIME immune to this? Or it is safer to rely on
    >>>>> CLOCK_MONOTONIC?
    >>>> Why do pretend to ask questions with implied, obvious answers?
    >>>> No amount of smoke and mirrors will ever protect a program from admin
    >>>> intervention intended to break it.
    >>> Well. Your attitude is strange. If the time has to be adjusted it
    >>> has to be adjusted.

    >>
    >> I see nothing particularly 'strange' in the assumption that the
    >> purpose of a clock is to measure time.

    >
    > Time is a relative measurement.


    A measurement is always relative, because it must be put into a
    relation with a known value of the quantity to be measured to have any
    meaning. "The length is 3000" does not communicate if these are 3000
    feet or 3000 German geographical miles (7421.5m).

    [...]

    > Anyone can come along and move the stick for the starting point


    Indeed. But since 'moving the starting point' invalidates all
    previously measured values, that someone should better be careful when
    doing so, because this is a delibarte violation of an invariant all
    users of the measuring device have to rely upon to be able to
    meaningfully compared values they have measured in the past.

    Eg, while it is certainly possible to set a 'wall clock' forward to
    Monday morning every Friday afternoon and kindly request that all
    people in some office take a ten minute break and then go back to work
    a pronto, it is unlikely that someone trying to do so would be taken
    seriously, because a commonly agreed upon reference time base does
    exist, sticking to which demands that two days have to pass before it
    again is Monday. Which means a lot of people will use indepently
    running 'measurement device' to determine when this time has come and
    the 'lone office admin' trying to change the time just changes a
    particular clock and the only effect is that this diminuishes its
    usefulness for measuring time to the point of non-existence.

    A similar situation exists on any set of computers running some kind of
    distributed application.

    [...]

    > a leap second




    > or even a Pope decreeing some number of days aren't in this year's
    > calendar) and you are hosed.


    This was a one-time adjustment necessitated by the fact the the leap
    days of the Julian calendar didn't yield an accurate enough
    approxmiation of the solar year and it took place in 1582.

    > If you want stuff to happen on wall clock times, use the system to figure it out
    > and assume it is only as good as you getting to work on time. (It is usually a
    > lot better.)


    It is usually a lot worse due to one hundred million little
    prospective popes really believing to be masters of time and not yet
    quite accustomed to the existence of networked computers running
    software which needs to coordinate its operation based on time, the
    same way humans need to. Most of them were presumably born after 1990,
    because 'older people' already knew better before this time, but one
    of the nice things about computers is that yesterdays mistakes
    reappear as tomorrows innovations once the quote of people old enough
    to still remember them has dropped to a sufficiently low value to
    render them a minority.

    > If you want stuff to happen some interval later, use an interval
    > measurement and ignore the wall clock.


    And if I want 'stuff too happen' on six computers, two in Germany, two
    at US east cost, one US west cost and the last in southern China (this
    is a realistic example) 'some interval later', then I need to ensure
    that all of them use a common reference time base and have their
    clocks running at the 'most identical set of clock speeds' technically
    achievable. And some of these computer are even running operating
    systems which support the traditional UNIX(*) interfaces for perusing
    the clock but don't support recent additions for surreal-time
    applications. 'Dali clocks', which suddenly bend in an arbitrary
    direction cannot be used for this.

    Neither can Dali clocks emulated by manually or semi-manually 'setting the clock'
    to some value whose relation to the previous values is arbitray.

  6. Time measurements

    GCG> [...] a leap second or even a Pope decreeing some number
    GCG> of days aren't in this year's calendar) and you are hosed.

    RW> This was a one-time adjustment necessitated by the fact
    RW> the the leap days of the Julian calendar didn't yield an
    RW> accurate enough approxmiation of the solar year and it
    RW> took place in 1582.

    It look place in (amongst others) 1582, 1700, 1752, 1867, 1873, 1896,
    1912, 1918, 1923, and 1929. That's stretching "one-time" quite a lot.

    A tip: Don't argue this subject from a parochial viewpoint that
    assumes that events in one country, and rules for one religion, apply
    universally. Such an argument always falls apart.

    RW> Most of them were presumably born after 1990,
    RW> because 'older people' already knew better before
    RW> this time, but one of the nice things about computers
    RW> is that yesterdays mistakes reappear as tomorrows
    RW> innovations once the quote of people old enough to
    RW> still remember them has dropped to a sufficiently
    RW> low value to render them a minority.

    Henry Spencer said it more succinctly.


  7. Re: Time measurements

    J de Boyne Pollard writes:
    > GCG> [...] a leap second or even a Pope decreeing some number
    > GCG> of days aren't in this year's calendar) and you are hosed.
    >
    > RW> This was a one-time adjustment necessitated by the fact
    > RW> the the leap days of the Julian calendar didn't yield an
    > RW> accurate enough approxmiation of the solar year and it
    > RW> took place in 1582.
    >
    > It look place in (amongst others) 1582, 1700, 1752, 1867, 1873, 1896,
    > 1912, 1918, 1923, and 1929. That's stretching "one-time" quite a
    > lot.


    The 'decree of the pope' took place in 1582. Different countries
    switched to the Gregorian calender at different times in the past.
    I am hard pressed to believe that you really didn't understand that
    and the relevance to either the discussion in general or my text in
    specific is zero.

    > A tip:


    Try to address the content of a text instead of trying to start a
    completely pointless sidelines flamewar instead.

  8. Time measurements

    GCG> [...] a leap second or even a Pope decreeing some number
    GCG> of days aren't in this year's calendar) and you are hosed.

    RW> This was a one-time adjustment necessitated by the fact
    RW> the the leap days of the Julian calendar didn't yield an
    RW> accurate enough approxmiation of the solar year and it
    RW> took place in 1582.

    JdeBP> It look place in (amongst others) 1582, 1700, 1752,
    JdeBP> 1867, 1873, 1896, 1912, 1918, 1923, and 1929. That's
    JdeBP> stretching "one-time" quite a lot.

    RW> The 'decree of the pope' took place in 1582. Different
    RW> countries switched to the Gregorian calender at different
    RW> times in the past.

    .... which multiple changes are exactly the moving of the measuring
    sticks that Golden California Girls was talking about in the message
    that you replied to. When the decree was issued is irrelevant. It
    was when the changes happened that is relevant. Go back and read
    Golden California Girls' message again, carefully this time.

    RW> I am hard pressed to believe that you really didn't
    RW> understand that

    The lack of understanding is yours, not anyone else's.

    RW> the relevance to either the discussion in
    RW> general or my text in specific is zero.

    If that were actually true, you wouldn't have been discussing it in
    the first place. But as can be seen from above quote, you were. As I
    said, it is you that doesn't understand, not the other people around
    you. You didn't understand the message that you replied to, and you
    didn't understand the point that I made, either.

    RW> Try to address the content of a text instead of trying
    RW> to start a completely pointless sidelines flamewar instead.

    We are addressing your message content. The content that you wrote is
    quoted above.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2