ntpd does not always gracefully handle clock steps during resume.
This is probably most useful in conjunction with
ntpd_sync_on_start=YES which will work around any clock skew while
suspended.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 45969 Build 42857: arc lint + arc unit
Event Timeline
Comment Actions
Maybe check if sync_on_start is set and only restart ntpd then ?
I fear some bug reports that ntpd restart on resume for no reason ...
Comment Actions
I thought about that, but I don't really expect harm in restarting in general? ntpd is designed to restart across reboots and preserve state about long-term clock drift, etc.
Comment Actions
It is designed for that, yes. If we shut it down properly, saving the drift (aka frequency error) file, it might not be terrible. In the absence of data, it's unclear if resuming from a suspend would have a frequency error more like the drift file, or if we'd be better off starting from scratch. The drift file works well in continuous situations (which includes reboot since the system generally has the same systemic errors and reboot doesn't change the environmental conditions that affect time all that much, and experience has shown that this remains true enough across a shutdown and power up though it works less well since it copes with the systemic errors in the timing hardware, but not the environmental ones). For a laptop, the environmental stuff will vary quite a bit more than a server in a server room, or even a desktop in an unregulated office. Since we have no specific data, we likely should just treat it like we would a reboot, and accept that we may have a slightly higher frequency error as a result that will be steered out. While we might have worse frequency performance doing this, I think the benefits of better phase stepping would outweigh this theoretical benefit.
Having said that, there's not really a need to check in the general case....