| created | 2020-01-23T09:53:26Z |
|---|---|
| begin | 2019-12-02T01:38:06Z |
| end | 2019-12-02T02:24:29Z |
| path | src/sys |
| commits | 1 |
| date | 2019-12-02T02:24:29Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_tc.c | log | diff | annotate |
| message |
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@ |
|||