Re: [Xenomai-help] Question about getting system time
Steve Deiters wrote: The set of services which you can call from a real-time thread without loosing determinism are those found in the Xenomai posix skin documentation: http://www.xenomai.org/documentation/xenomai-2.5/html/api/grou p__posix.html Other than that, any service emitting a syscall causes a switch to secondary mode. What remains are services not emitting syscalls, and for these ones, all bets are off. -- Gilles. I guess that is my point though. Not being all too familiar with the inner workings of Linux or glibc, how am I supposed to know which services are not emitting a syscall? I accept that I will lose determinism in calling these services, but I find it odd that it may allow the system to deadlock. If nothing else the syscall-less services should be listed and noted as unsafe. I am new to most of this, but I have went through most of the documentation and, unless I have overlooked it, found nothing mentioning this. Key services that do not reliably trigger syscalls: - gettimeofday - clock_gettime (unless the POSIX skin is in use) - malloc - free There are no guarantees either, but this list turned out to be fairly complete while porting a large (x86) application from plain Linux to Xenomai. Only gettimeofday (and, conditionally, clock_gettime) suffer from the live-lock problem. For runtime checks, enable T_WARNSW / PTHREAD_WARNSW for your RT threads, additionally link against librtdk, --wrap the above services, and assert_nrt() will trigger a SIGDEBUG when they are used from a RT thread (just like normal syscalls will do). There should be a few more services in the glibc that trigger malloc internally without issuing a syscall. When you come across one (check the man pages), additions to xenomai/src/rtdk/assert_context.c are welcome. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Jan Kiszka wrote: Steve Deiters wrote: I guess that is my point though. Not being all too familiar with the inner workings of Linux or glibc, how am I supposed to know which services are not emitting a syscall? I accept that I will lose determinism in calling these services, but I find it odd that it may allow the system to deadlock. If nothing else the syscall-less services should be listed and noted as unsafe. I am new to most of this, but I have went through most of the documentation and, unless I have overlooked it, found nothing mentioning this. Key services that do not reliably trigger syscalls: - gettimeofday - clock_gettime (unless the POSIX skin is in use) - malloc - free There are no guarantees either, but this list turned out to be fairly complete while porting a large (x86) application from plain Linux to Xenomai. Only gettimeofday (and, conditionally, clock_gettime) suffer from the live-lock problem. For runtime checks, enable T_WARNSW / PTHREAD_WARNSW for your RT threads, additionally link against librtdk, --wrap the above services, and assert_nrt() will trigger a SIGDEBUG when they are used from a RT thread (just like normal syscalls will do). There should be a few more services in the glibc that trigger malloc internally without issuing a syscall. When you come across one (check the man pages), additions to xenomai/src/rtdk/assert_context.c are welcome. Should not we make things more automatic? Integrate rtdk into libxenomai and forcibly do the wrapping? I am also thinking about modifying rt_print to make it possible to use it as a drop-in replacement of printf, and wrap it when using the posix skin. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Steve Deiters wrote:
Periodically setting the time is risky if timed jobs depend
on Xenomai's real-time clock - it may jump in all directions...
Any other suggestions for providing timestamps to real time
tasks in
this case?
Do you just need precise timestamps from with real-time
tasks, or do you have to synchronize timer events of the
Xenomai core on an external clock?
For the former case (precisely our scenario), we laid the
ground to extend Xenomai 2.5 with RT-safe syscalls to obtain
Linux's view on gettimeofday. It just needs some polishing
to post this for upstream.
Wolfgang (CC'ed) is working on this.
I'm just looking to get timestamps in the real time task. At least in
my case being able to call gettimeofday from the real time thread would
be exactly what I need.
then you might want to try the attached patches for Ipipe and
Xenomai. For upstream submission, they still need a bit of
cleaning up as Jan mentioned, and I'll also prepare a proper
series then. Testing is very welcome, however.
Best, Wolfgang
Pass generic time-of-day information from Linux to higher domains
From: Wolfgang Mauerer wolfgang.maue...@siemens.com
Introduce a mechanism to pass all information
required to implement a gettimeofday() call with
NTP corrections as delivered by the Linux domain
to other domains. Essentially, this is an equivalent
of the Linux vsyscall to perform this very action.
We need to ensure that updates of the timing information are
atomic wrt. non-Linux domains. While a simple solution would be to place
an appropriate lock around the updates, this would eliminate
the speed advantages of the kernel's seqlock. Therefore,
we implement a transactional mechanism using two copies of the
timing information that does not interfere with the updates
of the kernel itself.
The timing information is only updated from a single CPU
in the Linux domain, and updates preempted by Xenomai are
protected by the transactional mechanism. However, when a
reader on another CPU runs in parallel with an update on
CPU 0, an inconsistent state can arise. This is mended by
using a sequence counter to ensure that the data structure
was not modified during the read.
Note that since updating the structure takes a constant amount
of time that is much smaller than the interval between updates,
the number of iterations in the retry loop (in case of
modifications during the read) is bounded:
TODO: Explain why this is the case
---
include/linux/clocksource.h |8
include/linux/ipipe_tickdev.h | 20
kernel/ipipe/core.c | 36
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 64b1a4c..5ac07a7 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -281,12 +281,20 @@ extern void clocksource_resume(void);
extern struct clocksource * __init __weak clocksource_default_clock(void);
extern void clocksource_mark_unstable(struct clocksource *cs);
+/* Including ipipe_tickdev.h that declares update_ipipe_gtod()
+ would lead to a cycle, so we declare update_ipipe_gtod() here */
+void update_ipipe_gtod(struct timespec *ts, struct clocksource *c);
+
#ifdef CONFIG_GENERIC_TIME_VSYSCALL
extern void update_vsyscall(struct timespec *ts, struct clocksource *c);
extern void update_vsyscall_tz(void);
#else
+
static inline void update_vsyscall(struct timespec *ts, struct clocksource *c)
{
+#ifdef CONFIG_IPIPE
+ update_ipipe_gtod(ts, c);
+#endif
}
static inline void update_vsyscall_tz(void)
diff --git a/include/linux/ipipe_tickdev.h b/include/linux/ipipe_tickdev.h
index 4a1cb1b..68d9100 100644
--- a/include/linux/ipipe_tickdev.h
+++ b/include/linux/ipipe_tickdev.h
@@ -25,6 +25,7 @@
#if defined(CONFIG_IPIPE) defined(CONFIG_GENERIC_CLOCKEVENTS)
#include linux/clockchips.h
+#include linux/clocksource.h
struct tick_device;
@@ -44,6 +45,25 @@ struct ipipe_tick_device {
int real_shift;
};
+struct ipipe_gtod_data {
+ seqcount_t lock;
+ cycle_t (*vread)(void);
+ time_t wall_time_sec;
+ u32 wall_time_nsec;
+ struct timespec wall_to_monotonic;
+ cycle_t cycle_last;
+ cycle_t mask;
+ u32 mult;
+ u32 shift;
+};
+
+struct gtod_data_exchange {
+ int gtod_active;
+ struct ipipe_gtod_data gtod_data[2];
+};
+
+void ipipe_set_gtod_data_exchange(struct gtod_data_exchange *exchg);
+
int ipipe_request_tickdev(const char *devname,
void (*emumode)(enum clock_event_mode mode,
struct clock_event_device *cdev),
diff --git a/kernel/ipipe/core.c b/kernel/ipipe/core.c
index 63deaf9..53d9654 100644
--- a/kernel/ipipe/core.c
+++ b/kernel/ipipe/core.c
@@ -48,6 +48,12 @@ static unsigned long __ipipe_domain_slot_map;
struct ipipe_domain ipipe_root;
+static struct gtod_data_exchange *gtod_data_exchange = NULL;
+
+void ipipe_set_gtod_data_exchange(struct gtod_data_exchange *exchg) {
+ gtod_data_exchange = exchg;
+}
+
#ifndef CONFIG_SMP
Re: [Xenomai-help] Question about getting system time
Wolfgang Mauerer wrote: Steve Deiters wrote: Periodically setting the time is risky if timed jobs depend on Xenomai's real-time clock - it may jump in all directions... Any other suggestions for providing timestamps to real time tasks in this case? Do you just need precise timestamps from with real-time tasks, or do you have to synchronize timer events of the Xenomai core on an external clock? For the former case (precisely our scenario), we laid the ground to extend Xenomai 2.5 with RT-safe syscalls to obtain Linux's view on gettimeofday. It just needs some polishing to post this for upstream. Wolfgang (CC'ed) is working on this. I'm just looking to get timestamps in the real time task. At least in my case being able to call gettimeofday from the real time thread would be exactly what I need. then you might want to try the attached patches for Ipipe and Xenomai. For upstream submission, they still need a bit of cleaning up as Jan mentioned, and I'll also prepare a proper series then. Testing is very welcome, however. Ok. The following points should be fixed before submission: - gettimeofday should not have another timebase than clock_gettime(CLOCK_REALTIME): in other word, the whole clock system should be based on the ntp clock. - you should not use vread, you should use __xn_rdtsc directly in user-space, otherwise, your code would only work on x86. Of course this means that the I-pipe should create a clocksource with whatever hardware counter the architecture is providing to Xenomai. This also means that the I-pipe should declare a clocksource using whatever hardware counter is provided by the architecture with highest priority than other clocksources, to ensure that Linux is using the same clock source as Xenomai, and that NTP is correcting that clock source. This would also remove the issue with Linux declaring the tsc unstable. - why the transactionnal mechanism at all? Why not simply using seqlocks with an ipipe_spinlock, and do the update with irqs off? the locking section is much shorter than, say, xnpod_schedule, so it will not have any influence on the worst case latency, and the reader side will still be lockless. - the NTP event should trigger an ipipe event with ipipe_dispatch_event. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: Steve Deiters wrote: Periodically setting the time is risky if timed jobs depend on Xenomai's real-time clock - it may jump in all directions... Any other suggestions for providing timestamps to real time tasks in this case? Do you just need precise timestamps from with real-time tasks, or do you have to synchronize timer events of the Xenomai core on an external clock? For the former case (precisely our scenario), we laid the ground to extend Xenomai 2.5 with RT-safe syscalls to obtain Linux's view on gettimeofday. It just needs some polishing to post this for upstream. Wolfgang (CC'ed) is working on this. I'm just looking to get timestamps in the real time task. At least in my case being able to call gettimeofday from the real time thread would be exactly what I need. then you might want to try the attached patches for Ipipe and Xenomai. For upstream submission, they still need a bit of cleaning up as Jan mentioned, and I'll also prepare a proper series then. Testing is very welcome, however. Ok. The following points should be fixed before submission: thanks for the comments! - gettimeofday should not have another timebase than clock_gettime(CLOCK_REALTIME): in other word, the whole clock system should be based on the ntp clock. Sorry, I'm not quite sure what you are talking about here. The NTP corrections are provided for the clock offered in the vsyscall page by Linux, so the clock is based on the NTP clock, isn't it? Or am I misparsing your statement? - you should not use vread, you should use __xn_rdtsc directly in user-space, otherwise, your code would only work on x86. Of course this means that the I-pipe should create a clocksource with whatever hardware counter the architecture is providing to Xenomai. This also means that the I-pipe should declare a clocksource using whatever hardware counter is provided by the architecture with highest priority than other clocksources, to ensure that Linux is using the same clock source as Xenomai, and that NTP is correcting that clock source. This would also remove the issue with Linux declaring the tsc unstable. the reason why it's based on vread() is because the Linux kernel automatically makes sure that it points to a function that can be called from userland, so why would it only run on x86? Currently, the userland patch is limited to x86 because I've only adapted the sequence counter for this arch. Besides, vread() could also work with a different source than the TSC as long as it's accessible from userland. - why the transactionnal mechanism at all? Why not simply using seqlocks with an ipipe_spinlock, and do the update with irqs off? the locking section is much shorter than, say, xnpod_schedule, so it will not have any influence on the worst case latency, and the reader side will still be lockless. Because even if we don't increase the peak latency, we'll still increase the average latency. Additionally, it would also be possible to extend the base mechanism to an RCU-style communication channel between the kernel and Xenomai in the long run, so I'd argue that the lock-less solution is nicer. - the NTP event should trigger an ipipe event with ipipe_dispatch_event. could do, but I was following Gilles' suggestion ;-) to use an arch-specific hook since it's easier to maintain in the long run than writing a generic function and replacing every call to vsyscall_update(), also the future. (http://www.opensubscriber.com/message/xenomai-c...@gna.org/13126830.html, although I can change that, certainly no religious issues here) Thanks, Wolfgang ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Wolfgang Mauerer wrote: - gettimeofday should not have another timebase than clock_gettime(CLOCK_REALTIME): in other word, the whole clock system should be based on the ntp clock. Sorry, I'm not quite sure what you are talking about here. The NTP corrections are provided for the clock offered in the vsyscall page by Linux, so the clock is based on the NTP clock, isn't it? Or am I misparsing your statement? Unless I misunderstood your patch, what you provide is: gettimeofday which uses linux timebase clock_gettime which uses Xenomai timebase unrelated to linux' timebase This is unacceptable. What we want is a unique timebase. And since this will have a cost not everyone is willing to pay, I have another requirement: this code should be compiled conditionally. - you should not use vread, you should use __xn_rdtsc directly in user-space, otherwise, your code would only work on x86. Of course this means that the I-pipe should create a clocksource with whatever hardware counter the architecture is providing to Xenomai. This also means that the I-pipe should declare a clocksource using whatever hardware counter is provided by the architecture with highest priority than other clocksources, to ensure that Linux is using the same clock source as Xenomai, and that NTP is correcting that clock source. This would also remove the issue with Linux declaring the tsc unstable. the reason why it's based on vread() is because the Linux kernel automatically makes sure that it points to a function that can be called from userland, so why would it only run on x86? Currently, the userland patch is limited to x86 because I've only adapted the sequence counter for this arch. Besides, vread() could also work with a different source than the TSC as long as it's accessible from userland. vread is a function pointer call, which: - requires vsyscalls, currently only implemented on x86 (and maybe ppc) - is function pointer call, so damn slow on low end hardware. Xenomai has __xn_rdtsc on all architectures, so, we should be based on that. Since what we want is Xenomai to use the same clock source as Linux, and anything else than tsc is not implemented for Xenomai, we should implement tsc first and keep other clock sources for later. And when we use another clock, __xn_rdtsc will use that clock anyway. - why the transactionnal mechanism at all? Why not simply using seqlocks with an ipipe_spinlock, and do the update with irqs off? the locking section is much shorter than, say, xnpod_schedule, so it will not have any influence on the worst case latency, and the reader side will still be lockless. Because even if we don't increase the peak latency, we'll still increase the average latency. Additionally, it would also be possible to extend the base mechanism to an RCU-style communication channel between the kernel and Xenomai in the long run, so I'd argue that the lock-less solution is nicer. It is a useless optimization, it is a lot of code to avoid shutting interrupts of for a handful of assignments (since you can avoid copying vread, and mult and shift which never change if we enfore the clock source). There are many more, longer masking sections everywhere in the I-pipe patch and in Xenomai code. On the one hand you make complicated code (which will be costly on low end hardware) to avoid shutting interrupts around a few assignments, but on the other hand you leave an architecture specific function pointer call where we want a fast behaviour on average (remember, we do all this to avoid a system call, which is only a few hundreds nanoseconds on your big iron x86), and where we have a generic fast replacement. Sometimes, I do not understand your logic. - the NTP event should trigger an ipipe event with ipipe_dispatch_event. could do, but I was following Gilles' suggestion ;-) to use an arch-specific hook since it's easier to maintain in the long run than writing a generic function and replacing every call to vsyscall_update(), also the future. (http://www.opensubscriber.com/message/xenomai-c...@gna.org/13126830.html, although I can change that, certainly no religious issues here) What I mean is that vsyscall_update should trigger ipipe_dispatch_event. This is what I meant from the beginning. Ok. I will not be able to answer much more during the rest of the afternoon, so do not be surprised if I remain silent until tonight. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Hi, We had a similar problem. We solved it by compiling the native skin as a module and loading it _after_ the kernel has been syncronized with the real-time clock chip. Yes, that works too. There is also an option in the kernel for the kernel to synchronize with the RTC clock directly, without requiring hwclock. I do not know if it is run before starting Xenomai though. I have a similar requirement, except I want to keep the Xenomai clock synchronized with Linux services that use adjtime/adjtimex, e.g. NTP. It is not sufficient in this case to delay the startup of Xenomai. I suppose as a workaround I could create a low priority periodic thread that reads the Linux clock with gettimeofday and sets the Xenomai one with clock_settime. Any other suggestions for providing timestamps to real time tasks in this case? Thanks. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Steve Deiters wrote: Hi, We had a similar problem. We solved it by compiling the native skin as a module and loading it _after_ the kernel has been syncronized with the real-time clock chip. Yes, that works too. There is also an option in the kernel for the kernel to synchronize with the RTC clock directly, without requiring hwclock. I do not know if it is run before starting Xenomai though. I have a similar requirement, except I want to keep the Xenomai clock synchronized with Linux services that use adjtime/adjtimex, e.g. NTP. It is not sufficient in this case to delay the startup of Xenomai. I suppose as a workaround I could create a low priority periodic thread that reads the Linux clock with gettimeofday and sets the Xenomai one with clock_settime. Periodically setting the time is risky if timed jobs depend on Xenomai's real-time clock - it may jump in all directions... Any other suggestions for providing timestamps to real time tasks in this case? Do you just need precise timestamps from with real-time tasks, or do you have to synchronize timer events of the Xenomai core on an external clock? For the former case (precisely our scenario), we laid the ground to extend Xenomai 2.5 with RT-safe syscalls to obtain Linux's view on gettimeofday. It just needs some polishing to post this for upstream. Wolfgang (CC'ed) is working on this. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Periodically setting the time is risky if timed jobs depend on Xenomai's real-time clock - it may jump in all directions... Any other suggestions for providing timestamps to real time tasks in this case? Do you just need precise timestamps from with real-time tasks, or do you have to synchronize timer events of the Xenomai core on an external clock? For the former case (precisely our scenario), we laid the ground to extend Xenomai 2.5 with RT-safe syscalls to obtain Linux's view on gettimeofday. It just needs some polishing to post this for upstream. Wolfgang (CC'ed) is working on this. I'm just looking to get timestamps in the real time task. At least in my case being able to call gettimeofday from the real time thread would be exactly what I need. By the way, calling gettimeofday currently within a real time thread seems to occasionally freeze up my whole system. I was going to make another post for this after I got a chance to verify some details. Has anyone noticed anything similar to this? ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Steve Deiters wrote: Periodically setting the time is risky if timed jobs depend on Xenomai's real-time clock - it may jump in all directions... Any other suggestions for providing timestamps to real time tasks in this case? Do you just need precise timestamps from with real-time tasks, or do you have to synchronize timer events of the Xenomai core on an external clock? For the former case (precisely our scenario), we laid the ground to extend Xenomai 2.5 with RT-safe syscalls to obtain Linux's view on gettimeofday. It just needs some polishing to post this for upstream. Wolfgang (CC'ed) is working on this. I'm just looking to get timestamps in the real time task. At least in my case being able to call gettimeofday from the real time thread would be exactly what I need. By the way, calling gettimeofday currently within a real time thread seems to occasionally freeze up my whole system. I was going to make another post for this after I got a chance to verify some details. Has anyone noticed anything similar to this? Yes, that's expected: If gettimeofday runs syscall-less, it tries to read the time offset from a page which the Linux kernel updates regularly. When user-space detects an ongoing update, it spins until that has completed. But as Xenomai runs the task with higher priority than the Linux update handler, you just ran into a live-lock. Switching on the Xenomai watchdog will confirm this: It will shoot that task, and the system will recover. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Jan, If no ntp server updates are made to the Linux clock, we have noticed over a week's period a drift of ten or so seconds difference between the Linux clock and the Xenomai get time function and often have to reboot our machine to resynchronize the Xenomai and Linux clocks back to less than a couple seconds difference. I was wondering if you might explain why that might happen? SIncerely, Joshua Karch From: xenomai-help-boun...@gna.org [xenomai-help-boun...@gna.org] On Behalf Of Jan Kiszka [jan.kis...@siemens.com] Sent: Monday, May 17, 2010 10:13 AM To: Steve Deiters Cc: xenomai-help@gna.org; Mauerer, Wolfgang; Andreas Glatz Subject: Re: [Xenomai-help] Question about getting system time Steve Deiters wrote: Periodically setting the time is risky if timed jobs depend on Xenomai's real-time clock - it may jump in all directions... Any other suggestions for providing timestamps to real time tasks in this case? Do you just need precise timestamps from with real-time tasks, or do you have to synchronize timer events of the Xenomai core on an external clock? For the former case (precisely our scenario), we laid the ground to extend Xenomai 2.5 with RT-safe syscalls to obtain Linux's view on gettimeofday. It just needs some polishing to post this for upstream. Wolfgang (CC'ed) is working on this. I'm just looking to get timestamps in the real time task. At least in my case being able to call gettimeofday from the real time thread would be exactly what I need. By the way, calling gettimeofday currently within a real time thread seems to occasionally freeze up my whole system. I was going to make another post for this after I got a chance to verify some details. Has anyone noticed anything similar to this? Yes, that's expected: If gettimeofday runs syscall-less, it tries to read the time offset from a page which the Linux kernel updates regularly. When user-space detects an ongoing update, it spins until that has completed. But as Xenomai runs the task with higher priority than the Linux update handler, you just ran into a live-lock. Switching on the Xenomai watchdog will confirm this: It will shoot that task, and the system will recover. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
[please avoid top posting] Josh Karch wrote: Jan, If no ntp server updates are made to the Linux clock, we have noticed over a week's period a drift of ten or so seconds difference between the Linux clock and the Xenomai get time function and often have to reboot our machine to resynchronize the Xenomai and Linux clocks back to less than a couple seconds difference. I was wondering if you might explain why that might happen? I assume you are talking about an x86 platform: Normally, Linux should run on the TSC clocksource, just like Xenomai does. To ensure that the hardware isn't broken, Linux continuously performs runtime checks. The preemption by Xenomai tasks my fool this check an make Linux switch to a different clocksource. Now you have unsynchronized sources that usually drift. I haven't tried this with Xenomai yet but I could imagine it works just like it does in virtual machines: Pass tsc=reliable on the kernel command line. This disables the runtime checks, thus should take away any reason Linux may want to switch to anything else than TSC. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
If no ntp server updates are made to the Linux clock, we have noticed over a week's period a drift of ten or so seconds difference between the Linux clock and the Xenomai get time function and often have to reboot our machine to resynchronize the Xenomai and Linux clocks back to less than a couple seconds difference. I was wondering if you might explain why that might happen? Your clock oscillator on the x86 PC is drifting wrt NTP time (the oscillators are known to be bad time sources). We see the same effect here. With NTP running, try running a RT periodic thread and obtain both Linux system time and Xenomai RT time. You will see a sawtooth time difference reaching around 1msec in magnitude before NTP readjusts Linux system time back down to near zero. Then the clocks drift wrt one another until you have around a 1msec difference, and NTP adjusts the time again. I recall a periodicity of around 30-60sec per adjustment cycle (5-10 seconds per week) but it is dependent on the characteristics of your specific oscillator on the motherboard. I have thought to cope with this by having a rate parameter on the code encapsulating my timing source (I have drivers for Linux system time, Xenomai time, and hardware timing sources). The NTP rate in the drift file is pretty constant, so one could presumably use that rate to adjust your timers. hth - Tom ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Yes, that's expected: If gettimeofday runs syscall-less, it tries to read the time offset from a page which the Linux kernel updates regularly. When user-space detects an ongoing update, it spins until that has completed. But as Xenomai runs the task with higher priority than the Linux update handler, you just ran into a live-lock. Switching on the Xenomai watchdog will confirm this: It will shoot that task, and the system will recover. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux I'm not all too familiar with the time handling in the kernel. If you have any refernces that help me better follow your explanation that would be appreciated. If you linked against the POSIX skin it would then seem there is no safe way of calling gettimeofday. Even starting from main in this case is a real time task. In this case I would think that gettimeofday should be either wrapped to force a mode change before calling __real_gettimeofday, or should somehow be expressly forbidden. Even more of a problem is how I am supposed to know which calls are similar to this. I would expect I could call any Linux service without causing a deadlock/livelock situation, although in a nondeterministic manner. If I understood your explanation correctly, this is hanging whenever the Xenomai task tries to spin on the same lock as the kernel. However, I don't see how this is not a problem in general for acquiring any spinlock from a Xenomai task. I would expect once you introduce a priority based scheduler any spinlock becomes unsafe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Steve Deiters wrote: Yes, that's expected: If gettimeofday runs syscall-less, it tries to read the time offset from a page which the Linux kernel updates regularly. When user-space detects an ongoing update, it spins until that has completed. But as Xenomai runs the task with higher priority than the Linux update handler, you just ran into a live-lock. Switching on the Xenomai watchdog will confirm this: It will shoot that task, and the system will recover. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux I'm not all too familiar with the time handling in the kernel. If you have any refernces that help me better follow your explanation that would be appreciated. If you linked against the POSIX skin it would then seem there is no safe way of calling gettimeofday. Even starting from main in this case is a real time task. In this case I would think that gettimeofday should be either wrapped to force a mode change before calling __real_gettimeofday, or should somehow be expressly forbidden. The reason why I did not wrap gettimeofday is that we already have a wrapped clock_gettime, which is the newer service supposed to be used by real-time applications. If you are not porting a non real-time application, there is no reason to use gettimeofday, and if you are, this guide: http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Timing_services. Should explain you what you need to do. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Steve Deiters wrote: Even more of a problem is how I am supposed to know which calls are similar to this. I would expect I could call any Linux service without causing a deadlock/livelock situation, although in a nondeterministic manner. If I understood your explanation correctly, this is hanging whenever the Xenomai task tries to spin on the same lock as the kernel. However, I don't see how this is not a problem in general for acquiring any spinlock from a Xenomai task. I would expect once you introduce a priority based scheduler any spinlock becomes unsafe. The set of services which you can call from a real-time thread without loosing determinism are those found in the Xenomai posix skin documentation: http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__posix.html Other than that, any service emitting a syscall causes a switch to secondary mode. What remains are services not emitting syscalls, and for these ones, all bets are off. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
The set of services which you can call from a real-time thread without loosing determinism are those found in the Xenomai posix skin documentation: http://www.xenomai.org/documentation/xenomai-2.5/html/api/grou p__posix.html Other than that, any service emitting a syscall causes a switch to secondary mode. What remains are services not emitting syscalls, and for these ones, all bets are off. -- Gilles. I guess that is my point though. Not being all too familiar with the inner workings of Linux or glibc, how am I supposed to know which services are not emitting a syscall? I accept that I will lose determinism in calling these services, but I find it odd that it may allow the system to deadlock. If nothing else the syscall-less services should be listed and noted as unsafe. I am new to most of this, but I have went through most of the documentation and, unless I have overlooked it, found nothing mentioning this. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Hi, We had a similar problem. We solved it by compiling the native skin as a module and loading it _after_ the kernel has been syncronized with the real-time clock chip. Andreas From: xenomai-help-boun...@gna.org [xenomai-help-boun...@gna.org] On Behalf Of Abhijit Majumdar [abhijit.majum...@pivotalsys.com] Sent: Thursday, May 13, 2010 6:14 PM To: xenomai-help@gna.org Subject: [Xenomai-help] Question about getting system time Hi folks I am facing a strange problem in getting system time. My requirement: In a hard real time task I need to get the current system time and store it in a structure. Later at some point of time a java application a windows system is supposed to convert it into user-readable date-time format. I am using rt_timer_tsc2ns(rt_timer_read()) to get the current time. Problem: However the java application prints a date in 1980 (I converted nanosec to millisec before using java API). I kind of expected rt_timer_tsc2ns to return nanoseconds from 1st Jan 1970 because it is common for programming tools and languages, although I must admit that I did not see that in the xenomai API documentation. Am I doing something wrong? Should I have to compile the kernel with some specific parameter? Any help will be appreciated. thanks Abhijit ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Andreas Glatz wrote: Hi, We had a similar problem. We solved it by compiling the native skin as a module and loading it _after_ the kernel has been syncronized with the real-time clock chip. Yes, that works too. There is also an option in the kernel for the kernel to synchronize with the RTC clock directly, without requiring hwclock. I do not know if it is run before starting Xenomai though. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Question about getting system time
Abhijit Majumdar wrote: Hi folks I am facing a strange problem in getting system time. My requirement: In a hard real time task I need to get the current system time and store it in a structure. Later at some point of time a java application a windows system is supposed to convert it into user-readable date-time format. I am using rt_timer_tsc2ns(rt_timer_read()) to get the current time. You should be using rt_timer_ticks2ns(rt_timer_read()), rt_timer_tsc2ns should be used with rt_timer_tsc(). Problem: However the java application prints a date in 1980 (I converted nanosec to millisec before using java API). I kind of expected rt_timer_tsc2ns to return nanoseconds from 1st Jan 1970 because it is common for programming tools and languages, although I must admit that I did not see that in the xenomai API documentation. Am I doing something wrong? Should I have to compile the kernel with some specific parameter? The problem you may have is that Xenomai clock is synchronized with Linux clock when Xenomai starts, and it may happen at a time when Linux clock is not yet set to the current time. If that is the case, you should set xenomai's time during the boot process after Linux' time has been set. Currently, the only service to do this is clock_settime, implemented by the posix skin. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
