noticed NTP having trouble on a box after reboot (clock frequency was off by a lot, despite having been stable before reboot). I think I see why in the HPET code (and I noticed another glitch while I was in there..)

will be filing bugs shortly..

first glitch: hpet_read_main_counter_value() loops until the most significant 32 bits read the same twice in a row to work around tearing of the 64-bit value by reads through a 32-bit bus somewhere in the chip. Except that `counter` isn't declared volatile, and the compiler eliminates the loop.

the machine in question I noticed this on runs the HPET at 19.2MHz, which is ~52ns/tick. the loop that reads the HPET vs the TSC terminates right after the HPET ticks up, but it doesn't *start* at a tick (two consecutive reads that differ), so there will be ~52ns of slop at the start, which is quite a bit when the overall loop runs for only 100us.

calibration might well be more stable if it spun waiting for the HPET to tick at the start.

looks like I rediscovered illumos.org/issues/14556

→ BUG 14556: TSC calibration from HPET includes too much error (New)

it might be useful to note which HPET you have as well -- apparently not all HPETs are created equal... e.g. on the system I had with both an HPET and TSC, the HPET consistently gave more accurate results than the TSC (the other system didn't have a TSC but the result agreed fairly well with the expected clock rate), but apparently other HPETs are not as great (they they are _supposed_ to at least have a

[illumos-gate] 16763 dladm simnet functionality should be documented -- William Welliver <william⊙wo>

minimum frequency

(at least compared to the published frequency -- which intel says in the architecture manuals you should not use, even though intel themselves has contributed code to linux that does exactly what they say you shouldn't)

you mean PIT rather than TSC ? (anything we run on should have a TSC)

that's not true (and was the reason behind the changes)

at least some newer systems don't have a PIT

err yeah

been a long day already :)

don't have a PIT

annoying there's no way to tell other than try it and guess it's probably not makingprogress

that and my brain is still fried from a excruciating problem over the long weekend

okay, threw a bunch of tweaks and instrumentation into the hpet code and it's looking much more accurate (previously NTP found a frequency error of 327 ppm. now it locked with <1ms offset and a frequency error of ~2 ppm); I'll let it sit for the afternoon ...

is the system new(ish) ?

I've been meaning to throw up a change that adds using CPUID (when possible)... now that I've found a couple of systems where leaf 15 actually provides the values

gist.github.com/jasonbking/6f1475e4fe1684042b9fb17c617d3151 is a small program that'll test (just reads /dev/cpu/self/cpuid)

oh hrm.. tsoome isn't here..

tsoome_:

oh

newish. "12th Gen Intel(r) Core(tm) i5-1235U"

From leaf 0x15:

eax: 2 ebx: 130 ecx: 38400000 edx: 0

TSC Frequency: 0.35 GHz

which is .. not what calibration found

TSC calibrated using HPET; freq is 2496 MHz

(or in my patched code: TSC calibrated using HPET; freq is 2496094662 Hz

)

hrmm.. that's odd

jbk: aha, it's an integer overflow issue.

need to widen things to 64 bits first.

modified version yields 2496MHz which matches the HPET calibration.

38400000 * 130 = 4992000000 which doesn't fit in a uint32_t