Hacker News Reader

Comment by thedance | Hacker News Reader

It says my mac is off by nearly a full second, and sntp from the command line agrees.

  2020-02-07 20:49:08.720955 (+0800) +0.949762 +/- 0.732397 pool.ntp.org 108.59.2.24 s2 no-leap

Why is the clock discipline on macos so bad?

ETA: my local linux box by contrast is off by 1ms.

  2020-02-07 20:54:23.770052 (+0800) +0.000570 +/- 0.019234 pool.ntp.org 50.205.244.108 s2 no-leap

View on HN

NTP and even SNTP are performance intensive on the server side and so are generally configured to run at a low interval (either a fixed interval or, on Linux, an interval that becomes longer as local clock skew becomes known). This means that, at any random point, there's probably some reasonable amount of local clock skew that has accumulated since the last synchronization despite attempts to compensate by estimating the skew (essentially local skew is not constant, so estimating and offsetting only helps so much).

There is a tradeoff between highly accurate timekeeping vs. the cost of providing the service, and since the vast majority of users will never notice an inaccuracy of even a few seconds, OS vendors default in the direction of lower cost to maintain their NTP infrastructure.

There can be a bit of a tragedy of the commons situation since equipment which relies on the volunteer-operated pool.ntp.org is also somewhat more likely to have their NTP clients configured in an aggressive way that drives up load on that public resource - since the people configuring the client aren't responsible for operating the infrastructure.

Scuse me, I ran an NTP server on a net4501, which has a CPU so slow you can't even imagine it these days, and that left practically all of that CPU free for other work.

NTP is demanding of the CPU and OS, but what it demands isn't a lot of seconds (or a lot of memory), it is being run at precisely the right time. The OS can't run the NTP server when there's nothing else to do, the NTP server needs the right nanoseconds in order to work well.

These being open internet time services though, and especially in the case of time.windows.com, we are talking about millions of clients. You can build a cluster to handle this, as Microsoft has, but it costs money. The issue is especially clear since, at least historically (I'm not sure about now), the popular time.nist.gov was not a cluster but a single machine. It was nearly impossible to carry out a successful NTP session with that machine due to its load, an especially large problem because some well-meaning vendors configured time.nist.gov as a default on embedded devices. The NIST requests that it not be used except as a source for stratum-2 NTP servers but few people would do that today considering the reliability problems.

My Windows 10 was off by 3.3sec and just checked when it was last sync (12hours ago).

Did the resync and now just off by 0.08sec

My Android is off by 1.744. I wonder if it could be used for tracking as additional bits of info

Eh, my Linux server is off by 2s, and that’s supposed to be server grade hardware.

The reality might simply be that being off by a second doesn’t matter so much, as long as it’s gradual.

For example, Google chose to “smear” a leap second by prolonging each second by a tiny bit, and everything was fine.

And finally, to pay devils advocate, clients being off by +- a few seconds might actually be a good thing. If everyone was aligned to the millisecond 99.99% of the time, then a lot of timing bugs and inconsistencies won’t be surfaced except on the field.

If you're running some form of ntp, the underlying hardware doesn't matter that much. An offset greater than 0.5s is probably caused by ntp not running, time jumps during hibernation, automatic VM live migrations, or other virtualization issues. Not sure how bad a time jump of 0.5s really is, but in the past those did not happen on servers, so there are old ntp configs that attempt to correct it over days. Probably a mistake, because the instant correction of a large time jump should have no worse effects than the time jump itself.

I once forgot to install NTP on a Debian server (It is not installed by default). The skew reached 31s after 2 years and it invalidated all my JWT tokens.

Am I correct in inferring that you're saying the system time on your machine has lost 2 seconds since you last synchronised it with time.gov?

Over what time period did the slippage occur?

I can't load time.gov right now but time.is says my Mac is only off by 3ms (±17ms).

I have a phone connected to a wifu network time.gov states im off by .028. I have gps turned on so suerly I must have better time than anything available over ip, no? Anyone know how time.gov thinks it knows the time on my device taking into accout ip latency?

Reply on news.ycombinator.com