RE: Re: [PATCH] clocksource=tsc

["Dan Magenheimer" <dan.magenheimer@oracle.com>]

> I don't think this is necessarily true. If we write code to generate
> accurate time records specifically for clocksource=tsc then 
> we should easily
> get accuracy down to a couple of parts per billion. This is 
> certainly a more
> pragmatic solution than extending the guest time interfaces. 
> I am at least
> coming round to the fact that the changes required in Xen's 
> time.c are going
> to have to be a bit more drastic than I first hoped.
> 
>  -- Keir

I guess you are correct as long as "generate a time record"
doesn't include recomputing the scaling factor every
second (which is I think what introduces the jitter... see
more on this below).

However, I'm not sure why you perceive the aesthetics to
be so bad to put "if (ideal_clocksource)" in get_s_time()
and a few other places in time.c... or for that matter in
the PV guest code.

Your existing algorithm is a very cool and elegant way to
optimize time handling for all "legacy" time sources.
The more I understand about it, the more I am impressed!
But it is very difficult to understand and for most "modern"
hardware it unnecessarily obfuscates time handling.  So IMHO
I much prefer the "if (ideal_clocksource)... else ..."
approach rather than shoehorning the ideal to look like
the legacy.  And that applies for the PV guest code as well.

On a related note:

> The problem is that this is sensitive to small errors in the 
> scale factor!
> And unfortunately we compute a new scale factor, to convert to us, as
> scale_factor_ns/1000. The resulting scale factor is obviously 
> less accurate,
> and leads to an accumulating absolute error as the TSC value 
> gets large.

Yes I noticed that the mul_frac+scale_delta code gives different
answers than muldiv64, though they have essentially the same API.
I didn't do much testing but they differed after about 5 digits
and muldiv64 does a hardware divide so I suspect it is more
accurate (though also probably slower).  It might be worth looking
at this to squeeze out more precision.

Thanks for all your time and attention on this.  As Xen supports
more time-sensitive workloads (such as databases on enterprise
systems and games on PCs), I think it will pay off!

Dan