One more update .. when I look at `ntpctl -sa` now, it does not show any
"peer not valid" errors. However, it still rons a good 14 seconds behind.
And it gets worse every minute.
# ntpctl -sa
4/4 peers valid, 1/1 sensors valid, constraint offset -115s (4 errors),
clock unsynced
peer
wt tl st next poll offset delay jitter
213.154.236.182 from pool pool.ntp.org
1 10 2 3080s 3153s 2298.229ms 3.482ms 1.359ms
83.98.201.134 from pool pool.ntp.org
1 10 2 3154s 3220s 2764.077ms 2.686ms 0.703ms
217.23.3.234 from pool pool.ntp.org
1 10 2 2952s 3020s 2682.053ms 2.880ms 0.528ms
185.92.220.131 from pool pool.ntp.org
1 10 2 2999s 3076s 2266.144ms 2.287ms 0.937ms
sensor
wt gd st next poll offset correction
vmmci0
1 1 0 6s 15s 14607.577ms 0.000ms
On Fri, Nov 9, 2018 at 7:18 PM Stefan Arentz <stefan.are...@gmail.com>
wrote:
> Here is an update on the situation:
>
> I installed -current on this VM, clean install, and the ntpd error does
> not happen anymore. But the clock issues remain, even with ntpd running.
>
>
> The ntpd starts without complaints now, and seems to be running with its
> regular processes:
>
> _ntp 70093 0.0 0.5 920 2540 ?? S<sp 7:04PM 0:00.02 ntpd:
> ntp engine (ntpd)
> _ntp 51912 0.0 0.5 736 2464 ?? Isp 7:04PM 0:00.01 ntpd:
> dns engine (ntpd)
> root 46674 0.0 0.3 792 1640 ?? S<sp 7:04PM 0:00.00
> /usr/sbin/ntpd -s
>
>
> I have set kern.timecounter.hardware to tsc:
>
> # systctl kern.timecounter
> kern.timecounter.tick=1
> kern.timecounter.timestepwarnings=0
> kern.timecounter.hardware=tsc
> kern.timecounter.choice=i8254(0) tsc(-1000) dummy(-1000000)
>
>
> trondd asked for the output of ntpctl -sa, which shows me the following:
>
> # ntpctl -sa
> 0/4 peers valid, 1/1 sensors valid, constraint offset -3s, clock unsynced,
> clock offset is 12771.710ms
>
> peer
> wt tl st next poll offset delay jitter
> 213.154.236.182 from pool pool.ntp.org
> 1 2 - 152s 300s ---- peer not valid ----
> 83.98.201.134 from pool pool.ntp.org
> 1 2 - 152s 300s ---- peer not valid ----
> 217.23.3.234 from pool pool.ntp.org
> 1 2 - 152s 300s ---- peer not valid ----
> 185.92.220.131 from pool pool.ntp.org
> 1 2 - 152s 300s ---- peer not valid ----
>
> sensor
> wt gd st next poll offset correction
> vmmci0
> 1 1 0 15s 15s 18001.915ms 0.000ms
>
>
> I am not sure how to interpret these numbers. I also don't understand the
> "peer not valid" messages here. I have another OpenBSD VM which has the
> exact same ntpd.conf and it does not complain about any of the peers.
>
>
> I think my conclusion is that this is not something that can be solved at
> the VM level.
>
> S.
>
>
> On Sat, Nov 3, 2018 at 8:10 PM Stefan Arentz <stefan.are...@gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> I am having an issue where an OpenBSD VM running on vmd is having
>> serious clock skew issues.
>>
>> I am relatively new to OpenBSD, so I am not sure how to properly debug
>> this. What I hope is that I can provide a good amount of data and folks
>> here can give me some hints and ask me for additional information to
>> get to the root cause of this.
>>
>> So first some facts and symptoms:
>>
>> - Both Host and Guest are running OpenBSD 6.4. The host runs GENERIC.MP
>> and the guest GENERIC.
>> - The host runs 50 guests, all OpenBSD (openbsd.amsterdam)
>> - Only this VM is having this clock issue (is this correct, or were
>> there others?)
>>
>> - The guest has kern.timecounter.hardware=tsc
>> - The time on the VM was set with rdate a couple of days ago, and as of
>> now the VM is running about 4 hours behind.
>> - ntpd is running (main process, dns engine, ntp engine)
>> - when started or restarted, ntpd complains about "pipe write error
>> (from main): No such file or directory" but does seem to start
>>
>> - I just ran rdate nl.pool.ntp.org and the date was properly updated
>> - One minute after running rdate, the clock is already 7 seconds slow
>>
>> - The guest also has some severe networking issues. often I cannot type
>> more than a few characters before a ~15 second delays happens.
>> Interactive typing is difficult.
>> - I can SSH into the Host and have none of these issues, ruling out
>> connectivity issues between me (Toronto) and the Host (Amsterdam)
>>
>> It would be easy to blame this on NTPd, which does have an unexplained
>> error message. However, I think even without running NTPd, the clock
>> skew should not be this extreme.
>>
>> Somehow I have a gut feeling that the clock issues and the networking
>> issues are related.
>>
>> I am root on the VM but I am not on the host. I do have vmctl access.
>> However, the host admin is friendly (Hi Mischa) and is happy to help to
>> debug this issue.
>>
>> I tried to ktrace ntpd to get more insight in the "pipe write error
>> (from main): No such file or directory" error but I did not get useful
>> info out of it. This may be because of my unfamiliarity with those
>> tools.
>>
>> Help appreciated :-)
>>
>> S.
>>
>>
