On Tue, 20 Jul 2010 20:06:27 -0700, Pei Lin <telent997@xxxxxxxxx> wrote:
2010/7/17 Radhesh Kamath <rmk.list@xxxxxxxxx>:
On Fri, Jul 16, 2010 at 12:36 PM, Jan Ceuleers
<jan.ceuleers@xxxxxxxxxxxx> wrote:
On 15/07/10 18:42, Radhesh Kamath wrote:
I have a kernel module that sends me an RDTSC value to userspace, and
I need to get a UTC timestamp based on this.
As far as I understand, RDTSC gives me the clock ticks that have
elapsed since the processor was switched on (this is a 64-bit machine,
so my guess is that wraparound is not an issue).
How can I use this info to obtain a UTC timestamp?
Radhesh,
I suggest that you look into the NTP daemon (ntpd,
http://www.ntp.org/).
This daemon already does its best to obtain timing information from as
many sources as you configure, in order to discipline the local clock
to
observe UTC as closely as possible.
Jan
Hi Jan,
Thanks for the suggestion about the NTP daemon. But the problem I am
trying to solve is different.
I need to get a UTC timestamp, and use the RDTSC for doing so.
The CPU frequency is not varied, so a tick will represent the same
amount of time.
Nope, i think the CPU frequency maybe is varied. Pls. reference "CPU
throttling" http://en.wikipedia.org/wiki/Dynamic_frequency_scaling
Another article about the unrealiable nature of RDTSC is
http://en.wikipedia.org/wiki/Time_Stamp_Counter. You have to keep in
mind that "It counts the number of ticks since reset". With that,
you'll have to establish a relation between how many ticks per
second. Once you're counting in seconds, seems like you could just
add your seconds counter to gettimeofday() since that's already in
UTC. ie: sample gettimeofday at the beginning of your routine, and
add your RDTSC seconds counter to it from there.
Of course, it still sounds like a poor choice because of all the issues
stated in the wikipedia article. I would only use it if I knew my x86
cpu did not have power management or SMP (thinking PII, cause even some
PIII
supported frequency multiplier adjustments
http://en.wikipedia.org/wiki/SpeedStep).
Ah, this paper fits nicely
http://www.ccsl.carleton.ca/~jamuir/rdtscpm1.pdf :)
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
