On 18.01.2022 12:37, David Vrabel wrote: > > > On 18/01/2022 08:50, Jan Beulich wrote: >> On 13.01.2022 14:41, Jan Beulich wrote: >>> Calibration logic assumes that the platform timer (HPET or ACPI PM >>> timer) and the TSC are read at about the same time. This assumption may >>> not hold when a long latency event (e.g. SMI or NMI) occurs between the >>> two reads. Reduce the risk of reading uncorrelated values by doing at >>> least four pairs of reads, using the tuple where the delta between the >>> enclosing TSC reads was smallest. From the fourth iteration onwards bail >>> if the new TSC delta isn't better (smaller) than the best earlier one. >>> >>> Signed-off-by: Jan Beulich <[email protected]> >> >> When running virtualized, scheduling in the host would also constitute >> long latency events. I wonder whether, to compensate for that, we'd want >> more than 3 "base" iterations, as I would expect scheduling events to >> occur more frequently than e.g. SMI (and with a higher probability of >> multiple ones occurring in close succession). > > Should Xen be continually or periodically recalibrating? Rather than > trying to get it perfect at the start of day?
I wouldn't call dealing with bad samples "getting it perfect". IOW I think recalibrating later may be an option, but independent of what I'm doing here. > You may also be able to find inspiration from the design or > implementation of the Precision Time Protocol which has to similarly > filter out outliers due to transmission delays. Thanks for the pointer. Jan
