Problem in measuring time!!

[Philippe Gerum]

On Sat, 2004-10-09 at 19:12, Philippe Gerum wrote:
> 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.
> 

Which could even be extended to: do _not_ call any vanilla kernel
routine on behalf of a RT context unless you have previously made sure
that it does not depend on any mutual exclusion construct involving
interrupt masking provided by the Linux kernel.

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

Philippe.