diff options
author | cheloha <cheloha@cvs.openbsd.org> | 2019-12-02 02:24:30 +0000 |
---|---|---|
committer | cheloha <cheloha@cvs.openbsd.org> | 2019-12-02 02:24:30 +0000 |
commit | b7440db19385239f812a1ef05bbfbea026c2fa3a (patch) | |
tree | 18007cc1408235abbbaf0b55c6ee8b5ce86612c0 /distrib/sets/lists/etc/mi | |
parent | 6e1dd155d1ddb11a265d8d157a07db480d9d3553 (diff) |
tc_windup: separate timecounter.tc_freq_adj from timehands.th_adjustment
We currently mix timecounter.tc_freq_adj and timehands.th_adjtimedelta
in ntp_update_second() to produce timehands.th_adjustment, our net skew.
But if you set a low enough adjfreq(2) adjustment you can freeze time.
This prevents ntp_update_second() from running again. So even if you
then set a sane adjfreq(2) you cannot unfreeze time without rebooting.
If we just reread timecounter.tc_freq_adj every time we recompute
timehands.th_scale we avoid this trap. visa@ notes that this is
more costly than what we currently do but that the cost itself is
negligible.
Intuitively, timecounter.tc_freq_adj is a constant skew and should be
handled separately from timehands.th_adjtimedelta, an adjustment that
we chip away at very slowly.
tedu@ notes that this problem is sort-of an argument for imposing range
limits on adjfreq(2) inputs. He's right, but I think we should still
separate the counter adjustment from the adjtime(2) adjustment, with
or without range limits.
ok visa@
Diffstat (limited to 'distrib/sets/lists/etc/mi')
0 files changed, 0 insertions, 0 deletions