Problem in measuring time!!
rpm at xenomai.org
Sat Oct 9 19:23:35 CEST 2004
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
More information about the Rtai