[Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

I need to timetag events from a realtime context with a NPT-synchronized
system clock.  This topic comes up periodically on the mailing list.  Last I
recall, there was talk of adding the capability via an alternate
(non-CLOCK_REALTIME) clock_id. What is the status of this topic?

thanks,
Jeff

[-- Attachment #2: Type: text/html, Size: 331 bytes --]

Re: [Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

On 2011-03-23 01:59, Jeff Weber wrote:
> I need to timetag events from a realtime context with a NPT-synchronized
> system clock.  This topic comes up periodically on the mailing list.  Last I
> recall, there was talk of adding the capability via an alternate
> (non-CLOCK_REALTIME) clock_id. What is the status of this topic?
> 

The special POSIX clock CLOCK_HOST_REALTIME is part of xenomai head (2.6
development tree), ipipe back-end support is available for x86 so far.
That clock allows to read the Linux CLOCK_REALTIME without leaving the
RT context.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Gilles Chanteperdrix]

Jeff Weber wrote:
> I need to timetag events from a realtime context with a NPT-synchronized
> system clock.  This topic comes up periodically on the mailing list.  Last I
> recall, there was talk of adding the capability via an alternate
> (non-CLOCK_REALTIME) clock_id. What is the status of this topic?

The CLOCK_HOST_REALTIME is available in the xenomai-head branch (to be
2.6 branch, soon). It requires modifications of the I-pipe patch which
are available, at least, on x86, but are probably not really hard to
implement on other platforms.

-- 
                                                                Gilles.

Re: [Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Wed, Mar 23, 2011 at 2:37 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Jeff Weber wrote:
> > I need to timetag events from a realtime context with a NPT-synchronized
> > system clock.  This topic comes up periodically on the mailing list.
>  Last I
> > recall, there was talk of adding the capability via an alternate
> > (non-CLOCK_REALTIME) clock_id. What is the status of this topic?
>
> The CLOCK_HOST_REALTIME is available in the xenomai-head branch (to be
> 2.6 branch, soon). It requires modifications of the I-pipe patch which
> are available, at least, on x86, but are probably not really hard to
> implement on other platforms.
>

 clock_gettime(CLOCK_HOST_REALTIME) fails when called from kernel, and from
clocktest.  Any ideas why?
Does the CLOCK_HOST_REALTIME need to be initialized in some way?
Test and config follow.

TIA,
Jeff



# /usr/xenomai/bin/clocktest -D -C 42
hostrt data area is not live
clock_gettime failed for clock id 42
hostrt data area is not live

# grep -rw CLOCK_HOST_REALTIME /usr/xenomai/include/
/usr/xenomai/include/posix/time.h:#define CLOCK_HOST_REALTIME 42

 # zgrep HOSTRT /proc/config.gz
CONFIG_XENO_OPT_HOSTRT=y
CONFIG_HAVE_IPIPE_HOSTRT=y

# cat /proc/xenomai/version
2.5.90

# cat /proc/ipipe/version
2.9-00

# uname -r
2.6.37.3-xeno-head-smp

Architecture is x86 32-bit SMP with TSC.

[-- Attachment #2: Type: text/html, Size: 2130 bytes --]

Re: [Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Gilles Chanteperdrix]

Jeff Weber wrote:
> On Wed, Mar 23, 2011 at 2:37 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> Jeff Weber wrote:
>>> I need to timetag events from a realtime context with a NPT-synchronized
>>> system clock.  This topic comes up periodically on the mailing list.
>>  Last I
>>> recall, there was talk of adding the capability via an alternate
>>> (non-CLOCK_REALTIME) clock_id. What is the status of this topic?
>> The CLOCK_HOST_REALTIME is available in the xenomai-head branch (to be
>> 2.6 branch, soon). It requires modifications of the I-pipe patch which
>> are available, at least, on x86, but are probably not really hard to
>> implement on other platforms.
>>
> 
>  clock_gettime(CLOCK_HOST_REALTIME) fails when called from kernel, and from
> clocktest.  Any ideas why?
> Does the CLOCK_HOST_REALTIME need to be initialized in some way?
> Test and config follow.
> 
> TIA,
> Jeff
> 
> 
> 
> # /usr/xenomai/bin/clocktest -D -C 42
> hostrt data area is not live
> clock_gettime failed for clock id 42
> hostrt data area is not live
> 
> # grep -rw CLOCK_HOST_REALTIME /usr/xenomai/include/
> /usr/xenomai/include/posix/time.h:#define CLOCK_HOST_REALTIME 42
> 
>  # zgrep HOSTRT /proc/config.gz
> CONFIG_XENO_OPT_HOSTRT=y
> CONFIG_HAVE_IPIPE_HOSTRT=y
> 
> # cat /proc/xenomai/version
> 2.5.90
> 
> # cat /proc/ipipe/version
> 2.9-00
> 
> # uname -r
> 2.6.37.3-xeno-head-smp
> 
> Architecture is x86 32-bit SMP with TSC.

CLOCK_HOST_REALTIME will work, only if the Linux kernel also uses the
TSC as its clocksource. So, check the "Switching to clocksource"
messages, or "disabling.*tsc" in the kernel log to see if the kernel has
not decided to use another clock source.

-- 
                                                                Gilles.

Re: [Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

On Wed, Mar 30, 2011 at 5:00 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Jeff Weber wrote:
> > On Wed, Mar 23, 2011 at 2:37 AM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> >> Jeff Weber wrote:
> >>> I need to timetag events from a realtime context with a
> NPT-synchronized
> >>> system clock.  This topic comes up periodically on the mailing list.
> >>  Last I
> >>> recall, there was talk of adding the capability via an alternate
> >>> (non-CLOCK_REALTIME) clock_id. What is the status of this topic?
> >> The CLOCK_HOST_REALTIME is available in the xenomai-head branch (to be
> >> 2.6 branch, soon). It requires modifications of the I-pipe patch which
> >> are available, at least, on x86, but are probably not really hard to
> >> implement on other platforms.
> >>
> >
> >  clock_gettime(CLOCK_HOST_REALTIME) fails when called from kernel, and
> from
> > clocktest.  Any ideas why?
> > Does the CLOCK_HOST_REALTIME need to be initialized in some way?
> > Test and config follow.
> >
> > TIA,
> > Jeff
> >
> >
> >
> > # /usr/xenomai/bin/clocktest -D -C 42
> > hostrt data area is not live
> > clock_gettime failed for clock id 42
> > hostrt data area is not live
> >
> > # grep -rw CLOCK_HOST_REALTIME /usr/xenomai/include/
> > /usr/xenomai/include/posix/time.h:#define CLOCK_HOST_REALTIME 42
> >
> >  # zgrep HOSTRT /proc/config.gz
> > CONFIG_XENO_OPT_HOSTRT=y
> > CONFIG_HAVE_IPIPE_HOSTRT=y
> >
> > # cat /proc/xenomai/version
> > 2.5.90
> >
> > # cat /proc/ipipe/version
> > 2.9-00
> >
> > # uname -r
> > 2.6.37.3-xeno-head-smp
> >
> > Architecture is x86 32-bit SMP with TSC.
>
> CLOCK_HOST_REALTIME will work, only if the Linux kernel also uses the
> TSC as its clocksource. So, check the "Switching to clocksource"
> messages, or "disabling.*tsc" in the kernel log to see if the kernel has
> not decided to use another clock source.
>
>
The kernel is using the TSC:

 # dmesg  | grep -i -e tsc -e clock -e switching
[    0.000000] Fast TSC calibration using PIT
[    0.204507] Switching to clocksource tsc
[    2.602836] rtc_cmos 00:06: setting system clock to 2011-03-30 19:24:03
UTC (1301513043)

Jeff

[-- Attachment #2: Type: text/html, Size: 3002 bytes --]

Re: [Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Gilles Chanteperdrix]

Jeff Weber wrote:
> On Wed, Mar 30, 2011 at 5:00 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> Jeff Weber wrote:
>>> On Wed, Mar 23, 2011 at 2:37 AM, Gilles Chanteperdrix <
>>> gilles.chanteperdrix@xenomai.org> wrote:
>>>
>>>> Jeff Weber wrote:
>>>>> I need to timetag events from a realtime context with a
>> NPT-synchronized
>>>>> system clock.  This topic comes up periodically on the mailing list.
>>>>  Last I
>>>>> recall, there was talk of adding the capability via an alternate
>>>>> (non-CLOCK_REALTIME) clock_id. What is the status of this topic?
>>>> The CLOCK_HOST_REALTIME is available in the xenomai-head branch (to be
>>>> 2.6 branch, soon). It requires modifications of the I-pipe patch which
>>>> are available, at least, on x86, but are probably not really hard to
>>>> implement on other platforms.
>>>>
>>>  clock_gettime(CLOCK_HOST_REALTIME) fails when called from kernel, and
>> from
>>> clocktest.  Any ideas why?
>>> Does the CLOCK_HOST_REALTIME need to be initialized in some way?
>>> Test and config follow.

It definitely works here with clocktest. I get, for instance:

# clocktest -C 42 -D
hostrt data area is live
Sequence counter : 66552
wall_time_sec    : 1301523397
wall_time_nsec   : 660000002
wall_to_monotonic
          tv_sec : -1301523264
         tv_nsec : 785932050
cycle_last       : 465912010644
mask             : 0xffffffffffffffff
mult             : 1345300900
shift            : 31

== Tested clock: 42 (CLOCK_HOST_REALTIME)
CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
--- -------------------- ---------------- ---------- --------------
  0                  1.2           -0.001          0            0.0
  1                  1.4            0.002          0            0.0
^C


-- 
                                                                Gilles.

Re: [Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Jeff Weber wrote:
>> On Wed, Mar 30, 2011 at 5:00 PM, Gilles Chanteperdrix <
>> gilles.chanteperdrix@xenomai.org> wrote:
>>
>>> Jeff Weber wrote:
>>>> On Wed, Mar 23, 2011 at 2:37 AM, Gilles Chanteperdrix <
>>>> gilles.chanteperdrix@xenomai.org> wrote:
>>>>
>>>>> Jeff Weber wrote:
>>>>>> I need to timetag events from a realtime context with a
>>> NPT-synchronized
>>>>>> system clock.  This topic comes up periodically on the mailing list.
>>>>>  Last I
>>>>>> recall, there was talk of adding the capability via an alternate
>>>>>> (non-CLOCK_REALTIME) clock_id. What is the status of this topic?
>>>>> The CLOCK_HOST_REALTIME is available in the xenomai-head branch (to be
>>>>> 2.6 branch, soon). It requires modifications of the I-pipe patch which
>>>>> are available, at least, on x86, but are probably not really hard to
>>>>> implement on other platforms.
>>>>>
>>>>  clock_gettime(CLOCK_HOST_REALTIME) fails when called from kernel, and
>>> from
>>>> clocktest.  Any ideas why?
>>>> Does the CLOCK_HOST_REALTIME need to be initialized in some way?
>>>> Test and config follow.
> 
> It definitely works here with clocktest. I get, for instance:

... and it definitely does not work with a 32 bits kernel.

-- 
                                                                Gilles.

Re: [Xenomai-help] CLOCK_REALTIME synchronized to NTP

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Jeff Weber wrote:
>>> On Wed, Mar 30, 2011 at 5:00 PM, Gilles Chanteperdrix <
>>> gilles.chanteperdrix@xenomai.org> wrote:
>>>
>>>> Jeff Weber wrote:
>>>>> On Wed, Mar 23, 2011 at 2:37 AM, Gilles Chanteperdrix <
>>>>> gilles.chanteperdrix@xenomai.org> wrote:
>>>>>
>>>>>> Jeff Weber wrote:
>>>>>>> I need to timetag events from a realtime context with a
>>>> NPT-synchronized
>>>>>>> system clock.  This topic comes up periodically on the mailing list.
>>>>>>  Last I
>>>>>>> recall, there was talk of adding the capability via an alternate
>>>>>>> (non-CLOCK_REALTIME) clock_id. What is the status of this topic?
>>>>>> The CLOCK_HOST_REALTIME is available in the xenomai-head branch (to be
>>>>>> 2.6 branch, soon). It requires modifications of the I-pipe patch which
>>>>>> are available, at least, on x86, but are probably not really hard to
>>>>>> implement on other platforms.
>>>>>>
>>>>>  clock_gettime(CLOCK_HOST_REALTIME) fails when called from kernel, and
>>>> from
>>>>> clocktest.  Any ideas why?
>>>>> Does the CLOCK_HOST_REALTIME need to be initialized in some way?
>>>>> Test and config follow.
>> It definitely works here with clocktest. I get, for instance:
> 
> ... and it definitely does not work with a 32 bits kernel.
>

The problem is that in the x86_32 patch, nobody calls
ipipe_update_hostrt. The following patch should get it working. Though
may not be the cleanest way to do it.

And except for the "if (clock == clocksource_tsc)", is probably the way
we could get it working for other architectures.

I am not sure it really works, since the clocktest output seemed to have
much more jitter than on x86_64, though the jitter decreased over time.

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cef6fde..4ac1073 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -154,7 +154,7 @@ config GENERIC_CALIBRATE_DELAY

 config GENERIC_TIME_VSYSCALL
        bool
-       default X86_64
+       default X86_64 || HAVE_IPIPE_HOSTRT

 config ARCH_HAS_CPU_RELAX
        def_bool y
diff --git a/arch/x86/kernel/ipipe.c b/arch/x86/kernel/ipipe.c
index d1d4544..04de06d 100644
--- a/arch/x86/kernel/ipipe.c
+++ b/arch/x86/kernel/ipipe.c
@@ -30,6 +30,7 @@
 #include <linux/irq.h>
 #include <linux/clockchips.h>
 #include <linux/kprobes.h>
+#include <linux/ipipe_tickdev.h>
 #include <asm/unistd.h>
 #include <asm/processor.h>
 #include <asm/system.h>
@@ -49,6 +50,7 @@
 #include <asm/apic.h>
 #endif /* CONFIG_X86_LOCAL_APIC */
 #include <asm/traps.h>
+#include <asm/tsc.h>

 int __ipipe_tick_irq = 0;      /* Legacy timer */

@@ -814,6 +816,19 @@ int __ipipe_check_tickdev(const char *devname)
        return ret;
 }

+#ifdef CONFIG_X86_32
+void update_vsyscall(struct timespec *wall_time, struct timespec *wtm,
+                       struct clocksource *clock, u32 mult)
+{
+       if (clock == &clocksource_tsc)
+               ipipe_update_hostrt(wall_time, clock);
+}
+
+void update_vsyscall_tz(void)
+{
+}
+#endif /* CONFIG_X86_32 */
+
 EXPORT_SYMBOL(__ipipe_tick_irq);

 EXPORT_SYMBOL_GPL(irq_to_desc);


-- 
                                                                Gilles.