illumos gate

Looking at the HPET period on a modern AMD system, we see:

# mdb -ke 'hpet_info::printf "%d\n" hpet_info_t period'
69841278

This is ostensibly in femtoseconds, so converting to Hz:

$ bc -l
1 / (69841278 * (10^-15)) / 10^6
14.31818014555804663253

This is ~14.318 Mhz (i.e., 12 times the PIT frequency of 1.193182 Mhz). At this frequency, there is a HPET tick every ~69.8 nanoseconds.

During calibration we currently wait for 100 usec worth of HPET ticks to pass while counting TSC ticks. For the 2.8Ghz CPU in this system, we would expect to see:

2.8 * 10^9 / 10^6 * 100
280000                          # TSC ticks per 100usec

Our polling of the HPET is unlikely to be precise. If we include just one extra HPET tick, that that's an extra 69.8 nanoseconds worth of TSC ticks:

2.8 * 10^9 / 10^9 * 69.8
195.44                          # TSC ticks per 69.8nsec

Depending on what happens during calibration, we could easily see an error of:

(280000 + 0) / 100 * 10^6
2800000000
(280000 + 195.44) / 100 * 10^6
2801954400

2801954400 - 2800000000
1954400                         # hz delta

(1954400 / 2800000000) * 10^6
698                             # PPM

This is somewhat less than ideal!

If, instead, we used a 10msec delta, we would reduce the error accordingly:

2.8 * 10^9 / 10^3 * 10
28000000                        # TSC ticks per 10ms

(28000000 + 0) / 10 * 10^3
2800000000.00000000000000000000
(28000000 + 195.44) / 10 * 10^3
2800019544.00000000000000000000

2800019544 - 2800000000
19544                           # hz delta

(19544 / 2800000000) * 10^6
6.98                            # PPM

Increasing the sample period further would continue to reduce the potential induced error, though due to other inaccuracies in the process we would fast approach the point of diminishing returns at the cost of increased calibration time cost.