[Xenomai-help] Xenomai 2.5.3 vs gettimeofday() --> livelock?

[Xenomai-help] Xenomai 2.5.3 vs gettimeofday() --> livelock?

[Jeremy Friesner]

Hi all,

I'm developing a product that consists of a small number of x86 Linux boxes connected over a LAN.  These boxes run Debian Linux with Xenomai 2.5.3 installed.  In order to co-ordinate their activities, they all run ptpd (as a Linux userspace daemon) to synchronize their clocks, as returned by gettimeofday().

The issue we're having is that occasionally (maybe once or twice a week, or even less), at a seemingly random time, one of these boxes (not always the same one) will simply quit working... it stops responding to pings, stops sending or receiving network traffic, etc.   We suspect (but haven't yet proved) that this is due to the box's Xenomai real-time thread spinning in-place somewhere, causing the Linux kernel to quit running.

Our Xenomai real-time thread doesn't do much (mainly ot just copies a fixed amount of data from one location to another), but it does occasionally call gettimeofday(), in order to record the current correlation between the PTP-based Linux clock and the Xenomai rt_timer_tsc() clock, so that it can account for drift between them.

From reading this post, it seems like the call to gettimeofday() might be the culprit:

	http://www.mail-archive.com/xenomai@xenomai.org

My first question is:  Am I right in suspecting that gettimeofday() can occasionally spin/livelock, when called from a Xenomai 2.5.3 real-time thread?  FWIW, it gets called from the real-time thread once every 333mS.

And if that is the case, my second question is:  Is there an alternative "safe" way to call gettimeofday() (or something equivalent) so that the real-time thread can find out the current PTP system time?  Or do I need to re-write my code so that the real-time thread never calls gettimeofday()?

Is there a recommended practice for using Xenomai threads in conjunction with PTP?

Thanks,
Jeremy

Re: [Xenomai-help] Xenomai 2.5.3 vs gettimeofday() --> livelock?

[Gilles Chanteperdrix]

On 07/06/2011 10:38 PM, Jeremy Friesner wrote:
> My first question is:  Am I right in suspecting that gettimeofday()
> can occasionally spin/livelock, when called from a Xenomai 2.5.3
> real-time thread?  FWIW, it gets called from the real-time thread
> once every 333mS.

Yes, this is a known issue.

> 
> And if that is the case, my second question is:  Is there an
> alternative "safe" way to call gettimeofday() (or something
> equivalent) so that the real-time thread can find out the current PTP
> system time?  Or do I need to re-write my code so that the real-time
> thread never calls gettimeofday()?
> 
> Is there a recommended practice for using Xenomai threads in
> conjunction with PTP?

There are several ways out:
- the rtdk library provides a version of gettimeofday which switches to
secondary mode before calling the real gettimeofday. In order to use it,
you have to link your application with:
-Wl,--wrap,gettimeofday -lrtdk
- you can forcibly emit the syscall like the clocktest application does.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai 2.5.3 vs gettimeofday() --> livelock?

[Uwe Fechner]

 Hi,

where can I find the documentation of the rtdk library?
I googled it, but only found people talking about it, but no api
documentation.

Regards:

Uwe Fechner

On 07.07.2011 06:54, Gilles Chanteperdrix wrote:
> rtdk library

Re: [Xenomai-help] Xenomai 2.5.3 vs gettimeofday() --> livelock?

[Gilles Chanteperdrix]

On 07/07/2011 10:01 AM, Uwe Fechner wrote:
>  Hi,
> 
> where can I find the documentation of the rtdk library?
> I googled it, but only found people talking about it, but no api
> documentation.

I do not think it has a documentation, but the code is relatively short.
The essential part of the API is rt_printf which essentially works as a
drop-in replacement for printf, except that you need some
initializations (rt_print_auto_init, or rt_print_init for each thread
which wants to log).

-- 
                                                                Gilles.