Problem in measuring time!!

Philippe Gerum rpm at xenomai.org
Sat Oct 9 19:12:03 CEST 2004


On Sat, 2004-10-09 at 18:49, Hannes Mayer wrote:
> Tarik KHOUTAIF wrote:
> > I’m using the kernel RTAI 2.4.20 _ RTHAL5 to develop a protocol of 
> > control/command. I work under  PERIODIC mode (and not ONESHOT mode). I 
> > have two real time tasks the first "Slave" who await a message on the 
> > serial port COM2, and the second "Master" which sends the message on the 
> > COM1.
> > 
> > Once the Slave task receives the message, returns a ACK to the Master. 
> > To measure time in the loop of asservissement of my system, and the time 
> > of execution of certain functions, I initialised start_rt_timer(1E1) in 
> > the nitialisation of the serials port.
> > The time of the transmission RTIME Time_transmission Time_send_command = 
> > rt_get_time_ns(); //in Master task Time_receive_command = 
> > rt_get_time_ns(); //in Slave task Time_send_response  = 
> > rt_get_time_ns(); Time_receive_response = rt_get_time_ns(); 
> > Time_transmission = time_receive_command – Time_send_command;
> > The problem is that :
> > Time_send_command = Time_send_response and Time_receive_command = 
> > Time_receive_response!! Is what you can inform me or to show me how to 
> > program differently to solve this problem???
> 
> Tarik,
> 
> I don't know if you need nanosecond resolution, but when I must measure
> time (in kernel modules; in microseconds) I use this:
> 
> do_gettimeofday(&tv);
> time = tv.tv_sec+(1.0*tv.tv_usec)/1000000;
> 
> That may be not the preferred way in RT context, but it seems to work.
> 

It works but unsafely on x86 at least. do_gettimeofday() runs code which
needs to be interrupt-free, but since the interrupt masking is fully
virtualized for all of the vanilla kernel code, it happens to run hw
interrupts on when called on behalf a RT task. In UP mode, a preemption
of this code path by some RT task that calls it back is likely to cause
a wrong output at best; on SMP, a hard lockup due to an attempt to grab
a spinlock recursively is a potential outcome, unless your system has
the local APIC enabled (but in the latter case, you've just been lucky
with the current Linux implementation...).

So the conclusion of this is: do _not_ call do_gettimeofday() on behalf
a RT context.

> Best regards,
> Hannes.
> 
> 
> _______________________________________________
> RTAI mailing list
> RTAI at rtai.org
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
-- 

Philippe.





More information about the Rtai mailing list