From: Jan Kiszka <jan.kiszka@domain.hid>
To: Philippe Gerum <rpm@xenomai.org>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] Synchronising TSC and periodic timer
Date: Mon, 20 Mar 2006 12:48:40 +0100 [thread overview]
Message-ID: <441E9698.5080506@domain.hid> (raw)
In-Reply-To: <44189C13.3010301@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
Philippe Gerum wrote:
> ...
> The issue that worries me - provided that we bound the adjustment offset
> to the duration of one tick after some jittery - is that any attempt to
> get intra-tick precision would lead to a possible discrepancy regarding
> the elapsed time according to those two different scales, between the
> actual count of jiffies tracked by the timer ISR on the timekeeper CPU,
> and the corrected time value returned by rtdm_read_clock. And this
> discrepancy would last for the total duration of the jitter. E.g., for a
> 100 us period, xnpod_get_time() could return 2 albeit rtdm_read_clock
> returns 300, instead of 200. Spuriously mixing both units in
> applications would lead to some funky chaos.
>
Trying to pick up this thread again, I just tried to understand your
concerns, but failed so far to imagine a concrete scenario. Could you
sketch such a "funky chaotic" situation from the application point of
view? And what would prevent us from improving the accuracy of other
timestamping API functions beyond RTDM as well, e.g. on converting from
ticks to nanos in rt_timer_ticks2ns()?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
next prev parent reply other threads:[~2006-03-20 11:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-14 20:45 [Xenomai-core] Synchronising TSC and periodic timer Jan Kiszka
2006-03-15 7:24 ` Jan Kiszka
[not found] ` <4417C74D.3060203@domain.hid>
2006-03-15 8:14 ` Jan Kiszka
2006-03-15 12:59 ` Philippe Gerum
2006-03-15 13:26 ` Gilles Chanteperdrix
2006-03-15 22:58 ` Philippe Gerum
2006-03-20 11:48 ` Jan Kiszka [this message]
2006-03-20 13:26 ` Philippe Gerum
2006-03-20 14:42 ` Rodrigo Rosenfeld Rosas
2006-03-20 16:51 ` Philippe Gerum
2006-03-20 19:27 ` Rodrigo Rosenfeld Rosas
2006-03-21 0:11 ` Jan Kiszka
2006-03-21 3:11 ` Rodrigo Rosenfeld Rosas
2006-03-20 14:46 ` Jan Kiszka
2006-03-21 12:44 ` Philippe Gerum
2006-03-24 13:14 ` Jan Kiszka
[not found] ` <200603201137.12548.rosenfeld@domain.hid>
2006-03-20 15:23 ` Philippe Gerum
2006-03-20 19:01 ` Rodrigo Rosenfeld Rosas
2006-03-21 17:57 ` Philippe Gerum
2006-03-15 13:34 ` Gilles Chanteperdrix
2006-03-15 16:50 ` Jan Kiszka
2006-03-16 15:26 ` Gilles Chanteperdrix
2006-03-17 1:16 ` Jan Kiszka
[not found] <1CFEB358338412458B21FAA0D78FE86D02CABF1C@rennsmail02.eu.thmulti.com>
2006-03-15 17:20 ` 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=441E9698.5080506@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=rpm@xenomai.org \
--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.