All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Rosenfeld Rosas <lbocseg@domain.hid>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] RTDM and Timer functions
Date: Wed, 15 Mar 2006 00:31:34 +0000 (GMT)	[thread overview]
Message-ID: <20060315003134.11232.qmail@domain.hid> (raw)
In-Reply-To: <441748D5.9050305@domain.hid>

--- Jan Kiszka <jan.kiszka@domain.hid> escreveu:

> ...
> >> Moreover, when considering the TSC as high-resolution timestamp source,
> >> this is not applicable on SMP / multicore systems. Those tend to have
> >> unsynchronised and drifting TSCs. So if the first picture was taken on
> >> one CPU and the second on some other...
> > 
> > Unfortunately I can not arguee on that for now since I know almost nothing 
> > about SMP systems. I'll take a look on the topic and hopely soon I'll return 
> > you what I think about it.
> 
> Then let me continue my sentence:
> 
> ... the timestamps can not be used to calculate the delay between both
> of them. The reason is that you are lacking the offset between both TSC
> sources at the respective timestamp acquisition dates.

I understood that. What I've said is that I do not have enough knowledge about SMP systems for
suggesting you a way of dealing with this kind of problem.

> > ...
> > I don't understand why adding a new function like this would change a lot the 
> > documentation. I really can not see your worries... If you could give me a 
> > practical example, maybe it would be easier for me...
> 
> A driver that reports TSC timestamps instead of system clock timestamps
> to the user has to state this fact and its potential effects in periodic
> mode - as long as both clocks are out of sync.

That I understand. But I couldn't figure out which changes should be made to documentation for
adding this function. Of course, as usual, the programmer will need to know what (s)he is doing. A
single note explaining the situation in the rtdm_clock_read_tsc() function would suffice in my
opinion. I do not think that adding this function would imply in any confusion for developers.

> My idea is now to
> synchronise them and report corrected TSC-based timestamps via
> rtdm_clock_read() when in periodic mode. No need for new functions, use
> the old one, and all your problems would be solved automatically.

What do you mean by "corrected TSC-based timestamps"? How would be this mechanism? Which
resolution would it give?

I think you are meaning that:

On RTDM load, there is an automatic calculation of the offsets between the TSC of each CPU and the
Xenomai timer. Then, rtdm_clock_read() would change it behaviour to returning a higher precision
time read, based on TSC and correcting them with the stored offsets. Is that right?

Rodrigo.



		
_______________________________________________________ 
Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça. 
http://br.messenger.yahoo.com/


  reply	other threads:[~2006-03-15  0:31 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-09 17:43 [Xenomai-core] RTDM and Timer functions Rodrigo Rosenfeld Rosas
2006-03-09 20:33 ` Jan Kiszka
2006-03-10 13:54   ` Rodrigo Rosenfeld Rosas
2006-03-10 18:32     ` Jan Kiszka
2006-03-10 20:00       ` Rodrigo Rosenfeld Rosas
2006-03-13 11:48         ` Jan Kiszka
2006-03-13 14:54           ` Rodrigo Rosenfeld Rosas
2006-03-13 17:15             ` Rodrigo Rosenfeld Rosas
2006-03-13 17:58               ` Rodrigo Rosenfeld Rosas
2006-03-13 18:24                 ` Jan Kiszka
2006-03-13 19:25                   ` Rodrigo Rosenfeld Rosas
2006-03-13 19:19                 ` Rodrigo Rosenfeld Rosas
2006-03-15  4:44                   ` Jim Cromie
2006-03-13 18:12             ` Jan Kiszka
2006-03-14  1:28               ` Rodrigo Rosenfeld Rosas
2006-03-13 17:25       ` Gilles Chanteperdrix
2006-03-13 17:31         ` Rodrigo Rosenfeld Rosas
2006-03-13 18:33           ` Jan Kiszka
2006-03-13 19:31             ` Rodrigo Rosenfeld Rosas
2006-03-13 23:05               ` Jan Kiszka
2006-03-14  1:36                 ` Rodrigo Rosenfeld Rosas
2006-03-14  6:44                   ` Jan Kiszka
2006-03-14 14:27                     ` Rodrigo Rosenfeld Rosas
2006-03-14 16:46                       ` Jan Kiszka
2006-03-14 16:59                         ` Rodrigo Rosenfeld Rosas
2006-03-14 18:45                           ` Rodrigo Rosenfeld Rosas
2006-03-14 19:00                             ` Jan Kiszka
2006-03-14 19:40                               ` Rodrigo Rosenfeld Rosas
2006-03-14 20:29                                 ` Jan Kiszka
2006-03-14 22:32                                   ` Rodrigo Rosenfeld Rosas
2006-03-14 22:51                                     ` Jan Kiszka
2006-03-15  0:31                                       ` Rodrigo Rosenfeld Rosas [this message]
2006-03-15 13:06                                     ` Philippe Gerum
     [not found]                 ` <44167BE9.2090703@domain.hid>
2006-03-14 10:16                   ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060315003134.11232.qmail@domain.hid \
    --to=lbocseg@domain.hid \
    --cc=jan.kiszka@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.