Anders Blomdell wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> Hi,
>>> for those who haven't followed the endless "RTDM and Timer functions"
>>> thread: we are currently discussing a way to provide high-resolution
>>> timestamps in periodic mode for RTDM users. It was suggested to use the
>>> TSC for this, but I noted that this source will not be in sync with the
>>> periodic system timer and may even be out of sync across multiple CPUs.
>>> A straight-forward approach to overcome this might be to record the
>>> current TSC value together with the current jiffies in
>>> xntimer_do_tick_periodic(). This tuple (per CPU) could then be provided
>>> to skin implementers in order to let them offer a high-resolution
>>> timestamp source even in periodic mode. Hmm, sounds too simple actually,
>>> so I'm waiting now for someone pointing out the pitfalls.
>> Likely too simple: The periodic IRQ seems to pop up on every CPU so that
>> the TSC could be recorded, but will this happen synchronously? At least
>> we will see (IRQ) jitters, and those jitters could already create in the
>> single-CPU case a non-monotonic clock...
> Returning a struct with { jiffies, cpu#, tsc, clockscaling, ... } and
> routines to compare ( lt | equal | gt | unordered ) and calculate
> differences { diff, accuracy }. And then people (of course) will send
> them over the network and compare items emanating from different systems!

Well, I think it's more obvious that timestamps taken on box A will not
necessarily match timestamps of box B. Moreover, tasks on box A will not
that often get migrated automatically to box B, while this can happen
inside SMP boxes if you do not explicitly bind to a certain CPU.

For the local usage I have this scheme in mind:


So, nothing has to be exported to the skin user.

Or did I misunderstand what you wanted to express?


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to