0

I'm using Devuan GNU/Linux (~= Debian Buster without systemd) on my machine. On Debian-based systems, we can install the packages ntpdate, which provides the ntpdate binary - an NTP client that synchronizes your clock, once, and ntp, which provides the ntpd daemon. Among other things, it performs periodic synchronization.

Now, the accepted answer to this question:

How to keep Debian internal clock synchronized (with NTP servers)?

suggests I should install the ntp package. I wonder, though, whether that's really necessary. That is, why doesn't ntpdate simply come with a cron script which runs the client once every X hours, or days or whatnot? Do I really need all of the ntpd functionality - as suggested, when its own man page? :

BUGS
    The **ntpd** utility has gotten rather fat.  While not huge, it has gotten larger than
    might be desirable for an elevated-priority ntpd running on a workstation, particularly
    since many of the fancy features which consume the space were designed more with a busy
    primary server, rather than a high stratum workstation in mind.

Note: This question is about a physical, not a virtual, machine.

einpoklum
  • 8,772
  • 19
  • 65
  • 129
  • Are you aware of the differences between ntpdate and ntpd? You hinted at it with "run ntpdate every X hours or days". Why manually reinvent ntpd? – Jeff Schaller May 05 '20 at 16:43
  • Now read the package description for the ntpdate package and its NEWS file. (-: – JdeBP May 05 '20 at 16:44
  • @JeffSchaller: Because it's a small subset of what ntpd can probably do (as the quote suggest), and it's just for a lowly workstation. Also, a bunch of other things work like that, e.g. dynamic DNS server updaters. – einpoklum May 05 '20 at 18:32
  • @JdeBP: I haven, and that makes sense - but I didn't suggest sync'ing every time you bring an interface up or down - that does seem problematic. A cron-based mechanism seems more appropriate if you're not very concerned about the details the answers here mention. – einpoklum May 05 '20 at 18:37
  • Would you please specify whether we are talking about VMWare VMs or VMs vs physical servers? It does make a difference. – Rui F Ribeiro May 06 '20 at 11:37
  • @RuiFRibeiro: Physical, see edit. Also, it's not a server... just my PC. – einpoklum May 06 '20 at 11:52
  • Ok, not as bad then. Does it sleep? – Rui F Ribeiro May 06 '20 at 12:02
  • @RuiFRibeiro: No, actually. – einpoklum May 06 '20 at 12:54

2 Answers2

3

It depends on how much error (drift) you could allow your clock to have.

It is a known fact that clocks drift over time. The small error that may be generated on each cycle of the clock accumulates over longer periods and may (and usually do) keep a clock apart from the "real time".

The internal clock on many computers is kept by a hardware chip that has a small drift that is affected by temperature (around 10ppm for normal quartz crystals). Sometimes it goes faster than real time, sometimes slower. It could become 20 seconds (10 ppm in a month) out of sync in a month. Periodic syncs could reduce the maximum error. For example, using ntpdate once each week, the max error would be less than 5 seconds (~20/4).

The ntp program aims to have more frequent syncs to the "ntp time" (which is not exactly the "real time" but quite close). The usual error for a ntp sync is limited by the network latency, probably less than 100 Mili seconds, usually less than 10 Milli seconds. That will set the hardware clock to an Atomic clock time (quite close to the "real time"). That time will drift from that point on. There are some ways in which the ntp client might adjust the drift of the computer clock to keep it closer to the received time.

Yes, for all the small corrections and precision of the ntp protocol, it has become somewhat complex. It is not uncommon in present days to have a GPS clock, which is within 50 nano seconds (50.0e-09 seconds) of the "world time" (UTC). That is more than any NTP system could give. In that case, computers with such devices, are given the 0 level (stratum) for ntp use.

Of course, an ntpdate adjust every so often will mean that the computer knowledge of "real time" will be changed step-wise every so often. Which means that a file written now could have a timestamp smaller than a file written before. The ntp system works to avoid such "jumps" as best it could.

There are at least ntpd and chrony as servers for ntp time. You could use either (not both) to keep the computer clock, or you can use a GPS clock.

  • Actually, if that's the case - how come OSes don't have adjustment for clock drift based on temperature monitoring? Or - why doesn't the clock circuitry itself have that? – einpoklum May 05 '20 at 18:34
  • 2
    There is no externally accessible temperature sensor on most RTC clocks. In fact there is no temperature sensor, period. And, even if there were one, trying to control the RTC externally will fail, for one, it has to work also when the computer is off. Also, I am grossly simplifying the problem just to give some simple sound bites. Reducing quartz drift to 1ppm or 0.1 ppm is not as simple as controlling only the temperature. –  May 05 '20 at 20:13
1

Yes you can run ntpdate periodically and maintain a synchronised clock by adjusting it every so often. The clock may skip (jump) some time at every adjustment which could cause issues depending on whether you run software that requires consistent timekeeping.

You can also run ntpd and have it take care of the clock using the protocol designed for that purpose. You can also consider chrony which looks to be a fresher and lighter weight implementation. Again it relies on a daemon to keep the clock synchronised or you can use a command line to synchronise at any time.

The solution using the NTP protocol will cause your clock to be adjusted consistently and gently thus aiming for minimal adjustments and the smoothest transitions between adjustments (the time isn't actually adjusted directly once the daemon gets going).

Pedro
  • 1,821
  • 12
  • 23