In message <[EMAIL PROTECTED]>, Luoqi Chen writes:
>> people have found sufficiently many cases where the counters are
>> not in sync after the BIOS is done.
>I would really like to know how they managed to read the TSCs simultaneously,
>or they resorted to some kind of statistical means (which I tried without
>much success, maybe I will try later with some kernel hooks).
The differences were pretty significant in offset, I havn't heard
any numbers from them on skew, and I don't know of anybody who
have tried to measure it.
The trouble with N counters for N>1 is that you need to add code
to synchronize AND syntonize them, you need code to make sure time
is monotonic no matter what and yada yada yada.
By the time you're done the i8254 doesn't look so bad after all...
The ACPI counter is a good sized step in the right direction, they
should have made it PCI clock driven, to get better resolution but
I suspect the fact that they didn't is a sign that the PCI clock
will be power munged at some point.
For "general purpose" time a clock which is about the resolution of
the IO busses is sufficient, the ACPI is a little low on frequency,
but hey, it's miles better than the i8254, and the APM/ACPI will
not fuck with it's frequency.
For high resolution timing of "in-cpu" events, the TSC is still the
way to go, and nothing (except SMP complexity) prevents it from
being used for that, and it is probably pointless to convert the
data to nanoseconds until the difference has been found in the
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message