[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Re: [PATCH] clocksource=tsc
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |