3 ms·
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, a
by jcrawfordor 7y ago
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.
- Arnt 7y agoScuse 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.
- jcrawfordor 7y agoThese 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.