Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making every (leap) second count with our new public NTP servers

cloudplatform.googleblog.com

Post reply on HN
Print view View original

41–50 of 73 posts

Re: Making every (leap) second count with our new public NTP servers

#41

Post by toomuchtodo »

paulajohnson wrote: post #34
klodolph wrote: post #32

Earlier quoted context omitted.

Wow, that's a really boneheaded thing to put in a standard. I think we can all agree that it's important to make leap smearing available for those who want to use it, especially considering the bugs in leap second handling for common NTP clients.

I disagree. The point of NTP, and of time services in general, is that everyone agrees about the time. If an organisation wants to use non-standard time it can, but public-facing NTP servers should all agree and all provide the standard time. Google, for whatever reasons, is making its NTP servers deliberately wrong, and there is no mechanism in NTP for a server to say "I'm using time-smearing". So they shouldn't be…

> and there is no mechanism in NTP for a server to say "I'm using time-smearing".

That should most definitely be in the standard, along with communicating to the client full details about how smearing is configured.

Re: Making every (leap) second count with our new public NTP servers

#42

Post by klodolph »

paulajohnson wrote: post #34
klodolph wrote: post #32

Earlier quoted context omitted.

Wow, that's a really boneheaded thing to put in a standard. I think we can all agree that it's important to make leap smearing available for those who want to use it, especially considering the bugs in leap second handling for common NTP clients.

I disagree. The point of NTP, and of time services in general, is that everyone agrees about the time. If an organisation wants to use non-standard time it can, but public-facing NTP servers should all agree and all provide the standard time. Google, for whatever reasons, is making its NTP servers deliberately wrong, and there is no mechanism in NTP for a server to say "I'm using time-smearing". So they shouldn't be…

Then NTP has already failed. Most systems are already incapable of agreeing on whether it is 23:59:59 or 23:59:60 on days with leap seconds. There is simply not an API that will let you distinguish the two.

It is better to be deliberately wrong in a controlled fashion than to be accidentally wrong because you never expected your clock to be non-monotonic. You seem to be arguing for the status quo, are you aware of just how deeply broken the status quo is?

Re: Making every (leap) second count with our new public NTP servers

#43

Post by creshal »

klodolph wrote: post #42
paulajohnson wrote: post #34

Earlier quoted context omitted.

I disagree. The point of NTP, and of time services in general, is that everyone agrees about the time. If an organisation wants to use non-standard time it can, but public-facing NTP servers should all agree and all provide the standard time. Google, for whatever reasons, is making its NTP servers deliberately wrong, and there is no mechanism in NTP for a server to say "I'm using time-smearing". So they shouldn't be…

Then NTP has already failed. Most systems are already incapable of agreeing on whether it is 23:59:59 or 23:59:60 on days with leap seconds. There is simply not an API that will let you distinguish the two. It is better to be deliberately wrong in a controlled fashion than to be accidentally wrong because you never expected your clock to be non-monotonic. You seem to be arguing for the status quo, are you aware of ju…

What is your definition of "most systems"? Because we had very few (if somewhat high-profile) leap second bugs since its introduction in 1972.

Re: Making every (leap) second count with our new public NTP servers

#44

Post by creshal »

toomuchtodo wrote: post #41
paulajohnson wrote: post #34

Earlier quoted context omitted.

I disagree. The point of NTP, and of time services in general, is that everyone agrees about the time. If an organisation wants to use non-standard time it can, but public-facing NTP servers should all agree and all provide the standard time. Google, for whatever reasons, is making its NTP servers deliberately wrong, and there is no mechanism in NTP for a server to say "I'm using time-smearing". So they shouldn't be…

> and there is no mechanism in NTP for a server to say "I'm using time-smearing". That should most definitely be in the standard, along with communicating to the client full details about how smearing is configured.

Sure, but until then, public-facing NTP servers should stick to the current standard.

Re: Making every (leap) second count with our new public NTP servers

#45

Post by creshal »

tyldum wrote: post #30
ac29 wrote: post #8

Earlier quoted context omitted.

>Linux timekeeping (which currently handles leap seconds via a 61-second minute instead) Google doesn't think so: "No commonly used operating system is able to handle a minute with 61 seconds"

One of the big problems is application support. How many will break by seeing 60 as current second as opposed to 59 twice?

Break them, fix them, and move on. Must we coddle to every programmer's incompetence?

Re: Making every (leap) second count with our new public NTP servers

#46

Post by nullc »

I predicted this for leap smear a while back-- we have time sync because having systems with different times is a source of problems... logical fix: get them onto the same time.

Smear is a workaround for those who care about phase alignment but don't care about frequency error. ... and who don't need to exchange times with anyone else. This last point reduces the set to no one, since it can't extend to everyone (some parties care a lot more about frequency error than phase error!).

This circus is enhanced by NTP's inability to tell you what timebase it's using (or, god forbid, offsets between what its giving you and other timebases...)

It's going be especially awesome when NTP daemons with both smear and non-smear peers get both the smear frequency error AND get a leap second.

I for one welcome this great opportunity for an enhanced trash fire to help convince the world that we need to stop issuing leap seconds. (It's absurd-- causes tens of millions in disruption easily, -- and it would take 4000 years to even drift an hour off solar time, at which point timezones could be rotated if anyone really cared).

Re: Making every (leap) second count with our new public NTP servers

#47

Post by nullc »

leni536 wrote: post #33
detaro wrote: post #27

Earlier quoted context omitted.

Google introduced this exactly to not have to deal with it client-side, while still having UTC timestamps that match the rest of the world most of the time.

You have to deal with it at client side. It doesn't make sense to fix broken software by introducing broken time servers. It could make sense to provide a wrapper library that provides smeared leap seconds and use that for broken software only (like libfaketime). Now if I want to write software that uses precise TAI, I can't do that because of broken UTC from time servers and TAI is defined as UTC+tai_offset on my si…

> Now if I want to write software that uses precise TAI, I can't do that because of broken UTC from time servers and TAI is defined as UTC+tai_offset on my side.

Yup. Even if your NTP UTP source is perfect (lol), there aren't any cryptographically authenticated sources for the offset as far as I'm aware. (and NTP doesn't carry even an unauthenticated one).

GPS carries an offset between UTC and the (leapsecondless) GPS timescale... but the GPS signal is a bit of a pain to get to, and also unauthenticated...

Re: Making every (leap) second count with our new public NTP servers

#48

Post by jve »

klodolph wrote: post #32
liotier wrote: post #29

“Leap Smearing must not be used for public-facing NTP servers” - https://tools.ietf.org/html/draft-ietf-ntp-bcp-02

Wow, that's a really boneheaded thing to put in a standard. I think we can all agree that it's important to make leap smearing available for those who want to use it, especially considering the bugs in leap second handling for common NTP clients.

Is that a standard?

              Network Time Protocol Best Current Practices
                         draft-ietf-ntp-bcp-02
1. Introduction

   NTP Version 4 (NTPv4) has been widely used since its publication as
   RFC 5905 [RFC5905].  This documentation is a collection of Best
   Practices from across the NTP community.

Re: Making every (leap) second count with our new public NTP servers

#49

Post by detaro »

nullc wrote: post #46

I predicted this for leap smear a while back-- we have time sync because having systems with different times is a source of problems... logical fix: get them onto the same time. Smear is a workaround for those who care about phase alignment but don't care about frequency error. ... and who don't need to exchange times with anyone else. This last point reduces the set to no one, since it can't extend to everyone (some…

> Smear is a workaround for those who care about phase alignment but don't care about frequency error. ... and who don't need to exchange times with anyone else. This last point reduces the set to no one, since it can't extend to everyone (some parties care a lot more about frequency error than phase error!).

I don't quite understand that point. E.g. the typical web server doesn't have much of a need to exchange precise time with others. HTTP, TLS, ... require timestamps, timestamps are shown to users occasionally, but as long as they are roughly right that is enough. As long as all internal systems work off the same standard it is fine. Which seems to be the reasoning under which Google choose to use it, even though one might argue that with their cloud offerings they are not as insular.

Re: Making every (leap) second count with our new public NTP servers

#50

Post by heisenbit »

jve wrote: post #48
klodolph wrote: post #32

Earlier quoted context omitted.

Wow, that's a really boneheaded thing to put in a standard. I think we can all agree that it's important to make leap smearing available for those who want to use it, especially considering the bugs in leap second handling for common NTP clients.

Is that a standard? Network Time Protocol Best Current Practices draft-ietf-ntp-bcp-02 1. Introduction NTP Version 4 (NTPv4) has been widely used since its publication as RFC 5905 [RFC5905]. This documentation is a collection of Best Practices from across the NTP community.

Don't think it is a standard, looks like work in progress.

Imho a bit short notice to publish something like that Nov. 30th. Just at the time when they had to start advertising the leap second in NTP (or not advertise it where smearing). Not sure but somehow it sounds in draft-ietf-ntp-bcp-02 that that clients may need attention.

   Clients that are connected to leap smearing servers must not apply
   the "standard" NTP leap second handling.  So if they are using ntpd,
   these clients must not have a leap second file loaded, and the
   smearing servers must not advertise that a leap second is pending.
Post reply on HN