> Intel have specified a cpuid leaf that gives us that information (leaf 15H), however they only did so relatively recently, and I have yet to see a CPU that im

> Intel have specified a cpuid leaf that gives us that information (leaf 15H), however they only did so relatively recently, and I have yet to see a CPU that implements this. (The code checks for it, and will use it if it can, but it’s clearly not a general solution, and obviously hasn’t been tested :-)). FYI, Intel does list some nominal values for what the code calls 'coreCrystalFreq' (15H.ECX), in Vol. 3B§18.7.3. In my situation (i7-8559U, I don't have a compiler on anything newer), I do have 15H.EAX and 15H.EBX, and if I patch out the check for 15H.ECX and replace it with the constant given in the SDM for "6th and 7th generation Intel® Core™ processors", it's sane: cpuid leaf 15H: coreCrystal = 24, eax=2, ebx=226, ecx=0 => 368.73 us Sanity check against std::chrono::steady_clock gives frequency 2.71 GHz => 368.75 ps Measured granularity = 14 ticks => 192.86 MHz, 5.19 ns From model name string frequency 2.70 GHz => 370.37 ps (Also, I needed #include <cstdarg> to compile, since that's where va_start is defined....) > While there is no specification that requires that [the model name frequency] is the same as the notional time-stamp counter rate, so far I haven’t seen an Intel processor where it is different. Intel explicitly states that this is not a valid assumption. Vol.3B§17.17 Other than that... why not determine the rate of the counter by comparing against comparing against a counter of known rate? Which is what you do for a "sanity check" anyway! And is probably what the OS does! Or, better yet, admit the truth: none of these counters are appropriate for absolute measurement, especially at nanosecond scale. They are only appropriate for relative measurement, between two samples from a single device around the same time.