On Thu, Aug 24, 2017 at 12:39:33PM +0800, Adam Steen wrote: > On Thu, Aug 24, 2017 at 2:35 AM, Mike Larkin <mlar...@azathoth.net> wrote: > > On Wed, Aug 23, 2017 at 09:29:15PM +0800, Adam Steen wrote: > >> On Thu, Aug 17, 2017 at 12:19:28PM +0800, Adam Steen wrote: > >> > On Tue, Aug 8, 2017 at 10:12 PM, Mike Belopuhov <m...@belopuhov.com> > >> > wrote: > >> > > On Tue, Aug 08, 2017 at 08:18 +0800, Adam Steen wrote: > >> > >> On Mon, Jul 31, 2017 at 3:58 PM, Mike Belopuhov <m...@belopuhov.com> > >> > >> wrote: > >> > >> > On Mon, Jul 31, 2017 at 09:48 +0800, Adam Steen wrote: > >> > >> >> Ted Unangst wrote: > >> > >> >> > we don't currently export this info, but we could add some > >> > >> >> > sysctls. there's > >> > >> >> > some cpufeatures stuff there, but generally stuff isn't exported > >> > >> >> > until > >> > >> >> > somebody finds a use for it... it shouldn't be too hard to add > >> > >> >> > something to > >> > >> >> > amd64/machdep.c sysctl if you're interested. > >> > >> >> > >> > >> >> I am interested, as i need the info, i will look into it and > >> > >> >> hopefully > >> > >> >> come back with a patch. > >> > >> > > >> > >> > This is a bad idea because TSC as the time source is only usable > >> > >> > by OpenBSD on Skylake and Kaby Lake CPUs since they encode the TSC > >> > >> > frequency in the CPUID. All older CPUs have their TSCs measured > >> > >> > against the PIT. Currently the measurement done by the kernel isn't > >> > >> > very precise and if TSC is selected as a timecounter, the machine > >> > >> > would be gaining time on a pace that cannot be corrected by our NTP > >> > >> > daemon. (IIRC, about an hour a day on my Haswell running with NTP). > >> > >> > > >> > >> > To be able to use TSC as a timecounter source on OpenBSD or Solo5 > >> > >> > you'd have to improve the in-kernel measurement of the TSC frequency > >> > >> > first. I've tried to perform 10 measurements and take an average and > >> > >> > it does improve accuracy, however I believe we need to poach another > >> > >> > bit from Linux and re-calibrate TSC via HPET: > >> > >> > > >> > >> > > >> > >> > http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L409 > >> > >> > > >> > >> > I think this is the most sane thing we can do. Here's a complete > >> > >> > procedure that Linux kernel undertakes: > >> > >> > > >> > >> > > >> > >> > http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L751 > >> > >> > > >> > >> > Regards, > >> > >> > Mike > >> > >> > >> > >> Hi Mike/All > >> > >> > >> > >> I would like to improve the accuracy of TSC frequency calibration as > >> > >> Mike B. describes above. > >> > >> > >> > >> I initially thought the calibration would take place at line 470 of > >> > >> amd64/identcpu.c > >> > >> (https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/identcpu.c?annotate=1.87) > >> > >> > >> > > > >> > > Indeed, it cannot happen there simply because you don't know at > >> > > that point whether or not HPET actually exists. > >> > > > >> > >> But I looked into using the acpihpet directly but it is never exposed > >> > >> outside of acpihpet.c. > >> > >> > >> > > > >> > > And it shouldn't be. > >> > > > >> > >> Could someone point me to were if would be appropriate to complete > >> > >> this calibration and how to use the acpihpet? > >> > > > >> > > The way I envision this is a multi-step approach: > >> > > > >> > > 1) TSC frequency is approximated with the PIT (possibly performing > >> > > multiple measurements and averaging them out; also keep in mind that > >> > > doing it 8 times means you can shift the sum right by 3 instead of > >> > > using actual integer division). This is what should happen around > >> > > the line 470 of identcpu.c > >> > > > >> > > 2) A function can be provided by identcpu.c to further adjust the > >> > > TSC frequency once acpitimer(4) (this is a PM timer) and acpihpet(4) > >> > > (or any other timer for that matter) are attached. > >> > > > >> > > 3) Once acpitimer(4) or acpihpet(4) or any other timecounter source > >> > > are attached and are verified to be operating correctly, they can > >> > > perform TSC re-calibration and update the TSC frequency with their > >> > > measurements. The idea here is that the function (or functions) that > >> > > facilitate this must abstract enough logic so that you don't have to > >> > > duplicate it in the acpitimer or acpihpet themselves. > >> > > > >> > >> (Will it need to be > >> > >> exposed like i8254_delay/delay_func/delay in machdep.c and cpu.h) > >> > >> > >> > > > >> > > No it won't. > >> > > > >> > >> Lastly should the calibration be done using both delay(i8254 pit) and > >> > >> hpet timers similar to Linux described above or just using the hpet? > >> > >> > >> > > > >> > > Well, that's what I was arguing for. As I said in my initial mail > >> > > on misc (not quoted here), the TSC must be calibrated using separate > >> > > known clocks sources. > >> > > >> > Hi Mike > >> > > >> > Please see the below diff to improve the accuracy of the TSC > >> > frequency. It is model after the linux calibration you linked to > >> > earlier. https://marc.info/?l=openbsd-misc&m=150148792804747&w=2 > >> > > >> > I feel like i don't know enough about the kernel internals, the > >> > consistency of the results across reboots are not as close as i would > >> > have liked, i feel the call to do the actual calibration should be > >> > later in the boot cycle, when things have calmed down a little, but > >> > couldn't figure out the best way of doing this. > >> > > >> > please bear with me i haven't been programming c for long, but the > >> > only way to get things done is to do it your self. > >> > > >> > Cheers > >> > Adam > >> > >> <SNIP> > >> > >> Thank you Mike on the feedback on the last patch, please see the diff > >> below, update with your input and style(9) > >> > >> I have continued to use tsc as my timecounter and /var/db/ntpd.driff > >> has stayed under 10. > >> > >> cat /var/db/ntpd.drift > >> 6.665 > >> > >> ntpctl -s all > >> 4/4 peers valid, constraint offset -1s, clock synced, stratum 3 > >> > >> peer > >> wt tl st next poll offset delay jitter > >> 144.48.166.166 from pool pool.ntp.org > >> 1 10 2 4s 32s -3.159ms 87.723ms 10.389ms > >> 13.55.50.68 from pool pool.ntp.org > >> 1 10 3 11s 32s -3.433ms 86.053ms 18.095ms > >> 14.202.204.182 from pool pool.ntp.org > >> 1 10 1 14s 32s 1.486ms 86.545ms 16.483ms > >> 27.124.125.250 from pool pool.ntp.org > >> * 1 10 2 12s 30s -10.275ms 54.156ms 70.389ms > >> > >> Cheers > >> Adam > > > > IIRC you have an x220, right? > > > > If so, could you try letting the clock run for a bit (while using tsc > > timecounter selection) after apm -L to drop the speed? (make sure > > apm shows that it dropped). > > > > Even though my x230 supposedly has a constant/invar TSC (according to > > cpuid), the TSC drops from 2.5GHz to 1.2GHz when apm -L runs, which > > causes time to run too slowly when tsc is selected there. > > > > -ml > > > > Yes, x220 > (bios: LENOVO version "8DET69WW (1.39 )" date 07/18/2013) > (cpu: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz) > > I took some measurements to before starting the test. > > note: the laptop has been up for a few days with apm -A set via rc.conf.local > and sysctl kern.timecounter.hardware as tsc via sysctl.conf and mostly > idle. > > cat /var/db/ntpd.drift > 6.459 > > apm -v > Battery state: high, 100% remaining, unknown life estimate > A/C adapter state: connected > Performance adjustment mode: auto (800 MHz) > > 6 hours ago i ran apm -L, verified it was running slowly (800 MHz), > and got the following results > > The clock appears correct (comparing to other computers) > > apm -v > Battery state: high, 100% remaining, unknown life estimate > A/C adapter state: connected > Performance adjustment mode: manual (800 MHz) > > cat /var/db/ntpd.drift > 6.385 > > ntpctl -s all > 4/4 peers valid, constraint offset 0s, clock synced, stratum 4 > > peer > wt tl st next poll offset delay jitter > 203.23.237.200 from pool pool.ntp.org > 1 10 2 153s 1505s -25.546ms 73.450ms 2.644ms > 203.114.73.24 from pool pool.ntp.org > 1 10 2 253s 1560s -1.042ms 75.133ms 0.752ms > 192.189.54.33 from pool pool.ntp.org > * 1 10 2 204s 1558s 31.644ms 70.910ms 3.388ms > 54.252.165.245 from pool pool.ntp.org > 1 10 2 238s 1518s 0.146ms 73.005ms 2.025ms > > I will leave the laptop in lower power mode over the weekend and see > what happens. >
No need, I think you've convinced me that it works :)
