Subject: [Ntp] Servers stepping back their clocks

From: Danny Mayer <[email-masked]>
Date: Tue, 12 Feb 2019 17:18:47 -0500

I'd just like to reiterate what I said in the virtual interim meeting
during the roughtime discussion that any server that steps their clock
backwards is fundamentally broken and breaks the NTP protocol. It does
not matter where it's broken, if Posix, the O/S, or elsewhere.

Any such server should not be used as a source of NTP packets and should
be avoided at all costs.

Danny

---

From: Steve Allen <[email-masked]>
Date: Wed, 13 Feb 2019 09:29:04 -0800

> Any such server should not be used as a source of NTP packets and should

Suppose I start up my system, and it is an NTP server.
Suppose that at startup my LAN has no connection to the outside world.
Suppose that I later get a network connection and find that my system
clock is 10 seconds ahead of UTC.

It is possible for any system not to know what time it is.
A good protocol should recommend what actions should be taken.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Warner Losh <[email-masked]>
Date: Wed, 13 Feb 2019 10:29:24 -0700

> Any such server should not be used as a source of NTP packets and should

POSIX absolutely requires it. All Unix kernels do this, or at least all the
ones I've seen[*]. The clock is stepped back, but that doesn't stop it from
being a viable NTP server because the UTC TAI offiset is bumped when the
clock is stepped back. Since it does that, ntpd can get enough information
to produce the proper time stamps, repeating the last second once w/o the
leap indicator and once with the leap indicator. ntp_adjtime is how they
cope.

POSIX is fundamentally broke, but ain't going to change it's fundamental
brokenness ever.

You can't get both 'simple math' that POSIX requires along with a count
since epoch, which POSIX also requires.

But to say servers that step time can't get NTP right is 100% wrong.

Warner

[*] More recently, there's been attempts to get kernels to tick in TAI and
then "hide" the delta from the applications except when specifically asked
for TAI time. I fixed FreeBSD's kernel years ago to do the right thing when
it was stepping so that ntpd could do the right thing. I did a lot of
research at the time and the then-current was hand-wavy at best: many
people tried TAI and found that it broke a lot of things that were hard to
fix. Coupled with the lack of reliable leap second distribution of the
time, and nothing was more than a science experiment at the time.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 13 Feb 2019 13:20:19 -0500

> A good protocol should recommend what actions should be taken.
This is the case where you should step the clock to be where it should
be (more or less) but you shouldn't provide time to any other system
until you have synchronized the clock and you shouldn't start any
application on your system which requires a good clock until you have
done so. At an Observatory like yours that is crucial to pointing your
telescope in the right direction.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 13 Feb 2019 13:56:26 -0500

Danny

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 14 Feb 2019 08:19:54 +0100

>>> Steve Allen <[email-masked]> schrieb am 13.02.2019 um 18:29 in Nachricht
<[email-masked]>:
> On Tue 2019‑02‑12T17:18:47‑0500 Danny Mayer hath writ:

Isn't the practice to use a program to set the time quick and dirty first
(SNTP client, maybe), then starting the ntp daemon)? Are we talking about bad
time when the daemon starts, or bad time while the daemon is running? Actually
it's an interesting case to decide when a server is properly synced: In the
past I had cases where the time was badly synced, but it wasn't always
indicated by the numbers I could get from ntpd.

So maybe the best practices document could include some guidelines how to
decide whether a server is "well-synced". In the past I developed a set of
tests that can either succeed or fail, for each successful test, the component
gets one point, and in the end I converted the point score to a value in the
range [0-1], where 0 is a complete failure and 1 is "perfect" sync.
Unfortunately the test parameters depend on the type of server I'm monitoring
(e.g. stratum, LAN or WAN, etc.)...

Regards,
Ulrich

> 
> ‑‑
> Steve Allen                    <[email-masked]>              WGS‑84 (GPS)
> UCO/Lick Observatory‑‑ISB 260  Natural Sciences II, Room 165  Lat 
+36.99855
> 1156 High Street               Voice: +1 831 459 3046         Lng
‑122.06015
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 14 Feb 2019 00:18:02 -0800

> indicated by the numbers I could get from ntpd.

There should be no need to set the clock before calling ntpd.

That's why we recommend -g on cold-start (only).

I've heard a couple of people say that they think it's still useful, and
I would love to understand exactly why that would be the case.

The best thing to do is to have "enough" sources of time.

H
--

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 14 Feb 2019 09:54:24 +0100

> Suppose that at startup my LAN has no connection to the outside world.

If ntpd, for example, has no reliable time source that is accessible
then it just indicates that it is not synchronized (leap bits '3',
stratum 16), doesn't adjust its own system time, and passed the "not
synchronized" status on to its clients, so its clients don't accept the
time, either.

> clock is 10 seconds ahead of UTC.

Then ntpd *can* start to synchronize its own system time, and indicate
that it is synchronized, so its clients will accept it at time source.

*How* the initial offset of its own system time is corrected when ntpd
actually can figure out what the correct time is depends on the policy
or preferences for the particular system:

1.) If it doesn't hurt it can quickly step the time, even if the initial
time offset is huge. Usually this can be achieved with ntpd's '-g' flag,
which steps the time if the ffset exceeds the default 128 ms limit.

Current versions of ntpd also support a '-G' flag which also steps the
system time if the initial time offset is below the 128 ms limit, when
ntpd would normally just slew the time. So using '-G', too, make the
initial time synchronization even faster *if* time steps can be tolerated.

2.) If it would hurt to step the time then ntpd can "slew always" the
system time, but it may take very long until a large offset has been
compensated.

3.) If there are applications running on the local system that require
accurate time then it would be wise to start them only *after* the
system time is known to be accurate enough. This can be achieved by
running ntpdate, sntp, or 'ntpd -gGq' *before* the affected applications
are started, and then start ntpd in "normally" to keep the system time
synchronized.

> A good protocol should recommend what actions should be taken.

If your system actually doesn't know which time it is then it's anyway
no good idea to run applications that require accurate time.

As I said above, the actions to be taken depend on your own preferences
and requirements, and you have to configure your system in a way that it
meets your requirement. At least NTP/ntpd offer various possibilities.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Warner Losh <[email-masked]>
Date: Thu, 14 Feb 2019 07:30:17 -0700

> meets your requirement. At least NTP/ntpd offer various possibilities.

The problems I ran into usually were a requirement to start some control
program, even if you didn't know what time it was (an LED was lit in this
case, for example). And it was better everybody had the same time so ntpd
started serving time.

The other case was I have time, life is good. GPS receiver goes out and the
OXCO that was disciplining PPS drifts a bit for a while. GPS comes back and
now we have a huge offset, larger than we're supposed to tolerate. The
choice is 'slew the clock slowly' or 'step now'. Different applications
landed on difference sides of that coin due to the other requirements.

So you can not know time at boot but you can also not know time later.

Warner

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 14 Feb 2019 16:20:14 +0100

Warner Losh wrote:
> program, even if you didn't know what time it was (an LED was lit in
> this case, for example). And it was better everybody had the same time
> so ntpd started serving time.
> 
> The other case was I have time, life is good. GPS receiver goes out and
> the OXCO that was disciplining PPS drifts a bit for a while. GPS comes
> back and now we have a huge offset, larger than we're supposed to
> tolerate. The choice is 'slew the clock slowly' or 'step now'. Different
> applications landed on difference sides of that coin due to the other
> requirements.
> 

I fully agree, and it conforms that there is no general "best case" how
to handle such cases. The best way to correct this kind of things
depends on the requirements of your application.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Rob Seaman <[email-masked]>
Date: Thu, 14 Feb 2019 08:41:31 -0700

On 2/14/19 7:30 AM, Warner Losh wrote:

> The choice is 'slew the clock slowly' or 'step now'. Different

Yes. For example, the 10,000-year Clock (a mechanical digital computer)
implements multiple time scales, some of which can step backwards (say,
when re-synchronizing to the sun after a nuclear winter) and others that
pause to step slowly (so the Clock's orrery doesn't move backward as a
result):

http://hanksville.org/futureofutc/2011/preprints/10_AAS_11-665_Hillis.pdf

Others can comment on how NTP deals with the natural variation in
precision reference clocks, e.g., an IRIG card rated to 5 microseconds
driving a kernel clock. At whatever level of precision, one eventually
drills down to a physical process that oscillates both positive and
negative.

The clock discipline overlaid on such physical processes must also be
responsive to computer science requirements:

    https://lamport.azurewebsites.net/pubs/pubs.html#time-clocks

Even Einstein punted on synchrony. IIRC, relativity theory places the
simultaneity convention with the choice of gauge. Whereas the most
famous clock maintained by physicists steps forward and backward roughly
on an annual cadence:

    https://thebulletin.org/doomsday-clock/current-time/

Indeed, one suspects most here would be delighted to see that clock take
a big step backward.

Rob Seaman, University of Arizona