| 1 |
On Tue, Aug 29, 2017 at 9:14 AM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 2 |
> |
| 3 |
> ntp is designed for timeservers that by design do not make the clock |
| 4 |
> jump around. Every second on the wall clock actually happens, none are |
| 5 |
> missing. To do that, ntp adjusts the length of a second till the |
| 6 |
> machine's time creeps up towards the real time as defined by the U.S |
| 7 |
> Navy. Unless you are running software that is extremely time-critical |
| 8 |
> (eg centralized auth servers, science experiments, etc) or you operate a |
| 9 |
> proper time server, you absolutely do not need this behaviour ever.[1] |
| 10 |
> |
| 11 |
|
| 12 |
I'd argue the opposite. Assuming your system boots with approximately |
| 13 |
the correct time then slewing the clock is going to be the best way to |
| 14 |
maintain time. |
| 15 |
|
| 16 |
Now, if you're talking about a system that starts up with no concept |
| 17 |
of the real time then I'd say the best approach is to do a one-time |
| 18 |
sync to a time server, and then run ntpd from then on to maintain the |
| 19 |
time using slewing. Obviously you don't want to slew from the epoch |
| 20 |
to the current time. |
| 21 |
|
| 22 |
The one-time sync strikes me as the sort of thing that might ideally |
| 23 |
go into an initramfs. If you're obtaining your root filesystem over |
| 24 |
the network it might even be a dependency. Doing it that early |
| 25 |
eliminates most of the issues with logging and running services. |
| 26 |
|
| 27 |
-- |
| 28 |
Rich |
Archives