Re: Unix Time and Leap Seconds

David Schwartz <davids@xxxxxxxxxxxxx> writes:
Rainer Weikusat wrote:
David Schwartz <davids@xxxxxxxxxxxxx> writes:
Which means it is clearly supposed to be monotonic.

No. The system's best estimate of the time since the epoch may
legitimately go backwards.

The text above states 'shall return the value of time in seconds since
the epoch'.

That is an obviously nonsensical reading of the passage.

This is not 'an obviously nonsensical reading of the passage' (and if
it was, why precisely would it be nonsensical?) but a direct quote.

And this is monotonic by definition, because this is a
fixed point in time in the past which does not suddenly 'come closer'
timewise. It does not talk about 'the systems best estimate of seconds
since the epoch' but demands that the correct value shall be returned.
Anything else would be an implementation or local policy issue. For
instance, if the time returned by time(2) suddenly jumps backward or
forward due to manual adjustement, this is technically out-of-spec
and eventual problems are for the local sysadmin to deal with.

Which is a fancy way of saying that the specification does not require
monotonicity, countering your initial claim that it did.

Since I was clearly writing about things not contained in the
specification (of time(2)), how can that possibly affect things
contained in it? The answer is 'it cannot'.

Think long and hard about that case -- a very accurate time source
provides a time stamp earlier than one the system has already given
out based on a less accurate time source. Ask yourself which is more
faithful to the definition above:

1) We are monotonic, but we give out a time we *know* is too late.

2) We are not monotonic, but we do give out our best estimate of
seconds since the Epoch.

I think it's quite clear that the definition above is more faithfully
implemented by the latter interpretation.

I'd say neither of both.

You are certainly good at being cryptic.

The 'number of seconds since the epoch' is a montonically increasing
value. 1) returns a wrong value, 2) returns a random value, based on
some external events. Neither of both qualify.

[...]

On a 'modern' networked system, the timesource should either be a
locally attached reference clock or NTP, meaning, once this system is
up and running and has a correct 'initial time', time jumps should not
happen.

Nonsense. The timesource cannot be "a locally attached reference clock
or NTP" because NTP alone *cannot* serve as a timesource. NTP can be
used to discipline a local time source, but it cannot be used as one
by itself.

On UNIX(*), timekeeping is done by the kernel, utilizing specific
hardware features (like the ability to generate interrupts with a
close approximation of a fixed frequency) and some 'time source' which
is not part of the kernel that provides a suitable initial value for
the system clock. At least that was what I meant when using the term
'time source'. And a NTP server which is part of some NTP-coordinated
subnet can certainly provide this 'suitable initial value'. Depending
on the hardware, it may well be the only availabe 'source of the
current time'.

Additionally, NTP can be used to modify the 'clock speed' of the
system clock, as maintained by the kernel, such that matches the
'virtual' clock speed of the NTP-maintained "network clock" (which, in
turn, uses 'some time sources' external to the NTP network as inputs).

This is, of course, theory, and in practice, people either let
their clocks drift until this cause problems or run something like
ntpdate from a cronjob according to some random schedule, meaning,
the system time will jump arbitrary amounts at arbitrary intervals in
arbitrary directions.

But this is a problem cause by sysadmin incompetence or neglect, so
'let their own blood be on their hands'.

You are completely and totally wrong. This problem could be caused by
sysadmin incompetence or neglect, but can also arise from fundamental
limitations about the way the universe works.

That people run ntpdate from cron, causing thew system time to either
decrease or increase by an unpredictable amount at arbitrary intervals
is not 'a fundamental limitiation about the way the universe works'.
It is a policy descision that has been made by some system manager.

Consider a well-disciplined local time source that is managed by a
properly configured NTP server. After a timestamp is received by NTP,
the local time source speeds up a bit. Just before a new NTP timestamp
comes in, a program grabs the time from the kernel, then a new
timestamp comes in that's a bit earlier, then the program grabs the
time from the kernel again.

This forces the kernel to decide whether to be monotonic or to give
its best estimate of the time.

It does not work this way (for details, please try the publically
available NTP documentation). After a possible 'initial adjustment'
the reference time provided by NTP is used to adjust the frequency of
the the system clock in a way that is supposed to cause it to converge
with the reference time. Apart from that:

Correctness Principles

Applications requiring reliable time synchronization such as
air traffic control must have confidence that the local clock
is correct within some bound relative to a given timescale
such as UTC.

[...]

System clock correctness principles require that clock
readings must be always monotonically increasing, so that no
two successive clock readings will be the same. As long as the
reading latency exceeds the hardware resolution, this behavior
is guaranteed.
<URL:http://www.eecis.udel.edu/%7emills/exec.html>

[...]

I hate to sound like a broken record, but you are not only wrong but
you are dangerously wrong.

As the matter stands, I am not wrong. There isn't even a theoretical
possibility for 'wrongness' because the 'amount of seconds since time
X', with X being constant, is a monotonically increasing
value. That's one of the core property of the concept of 'time': The
past is always gone and the future can never be actually reached. It
is kind-of absurd to even attempt to discuss this, except if the
context is epistemology.

You are suggesting that programmers can reasonably assume that
properly-managed systems will not show backwards time jumps and that
they can blame such problems on system administrators.

I am suggesting that applications written for something which is
supposed to behave like UNIX(*) can reasonably assume that UNIX(*)
API calls do what they are supposed to do.
.

Relevant Pages

  • Re: Windows server sync to LocalCLK
    ... Now I have a linux box that tries to sync with this xp box but it doesn't work for at least 5 minutes of the NTP service starting. ... I've searched around and people are saying that it takes about 5-8 minutes before the server trusts the local clock as the source. ... one clock is selected more or less at random to act as the time source for the herd. ...
    (comp.protocols.time.ntp)
  • Re: Getting the Real NTP Server Active on XP Pro
    ... > Back in mid I asked this group about using my Garmin 12XL as a time source ... Some urged me to use NTP instead. ... I'd like to set the clock on the XP box daily from an NTP source ... that on even an hourly update, ...
    (sci.geo.satellite-nav)
  • Re: System Clock Apparently Gaining One Second Every 30 Minutes
    ... mains were used as a time source. ... but it wasn't NTP. ... causing jumps and a lot of clock wandering. ... Unfortunately it seems that all of the sources are moving to GPS. ...
    (comp.sys.mac.system)
  • Re: NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
    ... Only a very small part of the mandatory parts of the NTP specification describe the wire formats. ... They have no clock that is better ... Dave Mills, if you are still reading, I would point out that to anyone reading this except for the committed ntpd users on this list will be pretty convinced that they should be using chrony for any real world clock synchronization. ...
    (comp.protocols.time.ntp)
  • Re: SABERTOOTH X58 clock drift
    ... Network time protocol (NTP), can do a couple things for you. ... Say the hardware clock source (oscillator) ... real computers you also have the issue of SMM. ... On your computer, when an interrupt ...
    (alt.comp.periphs.mainboard.asus)