This probably doesn't mean anything, but I'll report it anyway. At Fri, 11 Apr 2025 12:35:24 -0700, "Greg A. Woods" <woods%planix.ca@localhost> wrote: Subject: Re: PHP performance on Xen domU with mulitple vcpu > > I can now report that with clockinterrupt as the timecounter my dom0 on > the test machine is continuing to keep "close enough" time for ntpd to > stay in sync though it is getting a little more jittery. > > # /sbin/sysctl kern.timecounter > kern.timecounter.choice = clockinterrupt(q=0, f=1000 Hz) xen_system_time(q=10000, f=1000000000 Hz) ichlpcib0(q=1000, f=3579545 Hz) ACPI-Safe(q=900, f=3579545 Hz) dummy(q=-1000000, f=1000000 Hz) > kern.timecounter.hardware = clockinterrupt > kern.timecounter.timestepwarnings = 1 That continued to work "well enough", keeping time, for about 30 days, then I started seeing (the second line is the important one) [Mon May 5 00:43:08 2025][ 2762194.6707292] xen_rtc_set: Setting to 1746430988.967090000 s at systime 2762208251432576 ns, gst 2762037071714406 ns (nanouptime: 2762194670729214 ns, initial: 13580703362 ns) diff(gst-(nt+init)): -171.179718170 s [Mon May 5 00:43:18 2025][ 2762203.6712933] WARNING: hardclock jumped past timecounter max 2762042776689492ns (2762047071714160 -> 4295024668), exceeding maximum of 4294967295ns for timecounter(9) (Here the first number is "last", the second is "now" (i.e. xen global system time), and the third number is the delta from last to now. That now repeats once per second. Remember that with my version of xen_clock.c the "diff" shown in the first line is the xen "global system time", i.e. gst - (nanouptime + initial). 2762037071714406 - (2762194670729214 + 13580703362) = -171179718170 So it's the difference between the time Xen thinks it is, vs. the time the system thinks it is. Probably it is the unaccounted for drift in the emulated TSC. That's after 2,762,194 seconds uptime of course. NTP is still running in sync and the machine is still keeping good time. The FreeBSD domU is also still keeping time, but the NetBSD domUs, which were still using xen_system_time are long lost in time. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpcs3U6a95FM.pgp
Description: OpenPGP Digital Signature