< ^ txt
Tue Apr 3 09:06:48 EDT 2018
Slept from eleven to six-thirty without waking.
High of thirty-nine today. Rain likely.
Work:
- Discovery for MGP lawsuit
Mostly done, but a bit more Florida stuff tomorrow.
- Work on MECS deployment plans
Not much.
Twenty-minute walk at lunch.
Saw a quartet of crows.
Home:
- Run offsite backup
Done.
- Check out time keeping under ntp vs systemd (systemd-timesyncd)
Done.
- Go to bed early
Done.
Clyde has been acting a little poky the last few weeks.
Not sure if this is a cause or a symptom, but I notice the date is badly wrong — it things today is March 30.
Ntp is running, and hasn't logged any errors.
```
--- 1146 --- clyde ~ $ ntpctl -s all
2/4 peers valid, constraint offset 390289s (15 errors), clock unsynced, clock offset is 78697541.952ms
peer
wt tl st next poll offset delay jitter
91.148.192.49 from pool pool.ntp.org
1 10 2 176s 3193s 268838098.935ms 96.591ms 0.192ms
211.233.40.78 from pool pool.ntp.org
1 2 2 962s 3264s ---- peer not valid ----
162.210.110.4 from pool pool.ntp.org
1 2 2 218s 3265s ---- peer not valid ----
91.236.251.12 from pool pool.ntp.org
1 10 2 2294s 3084s 8.761ms 154.486ms 10.565ms
```
http://openbsd-archive.7691.n7.nabble.com/ntpd-clock-unsynced-in-vm-td322922.html
> This problem has nothing to do with ntpd. ntpd's ability to adjust the clock is limited by adjtime(), which can correct time up to a generous maximum of 5 milliseconds for each second. If your clock drift is worse than that, your clock is broken. Which alas is the case for vm.
All I can assume is that the hypervisor's clock is wrong.
```
--- 1163 --- clyde ~ $ uptime
12:36AM up 2 days, 23:31, 1 user, load averages: 1.17, 1.22, 1.41
```
That's a lot of drift.
Time was correct after restart.
Pretty solid thunderstorm this evening.
Lunch: coffee, Thai catfish
Dinner: left-over ham, coleslaw, carrots, garlic sauce
< ^ txt