Re: How to tune one shot time period

Paolo Mantegazza <[email protected]>
Newsgroups gmane.linux.real-time.rtai
Message-ID <VI1PR06MB14719FE5D5A0F6163270177790E20@VI1PR06MB1471.eurprd06.prod.outlook.com>
Even if you do not report it, I'm assuming that you are matching a make_periodic with a wait_period. Therefore your pacing is based on the absolute, monotonic, pacing of the CPU Time Stamp Clock (TSC). So the drift you see should be related just to that and I'm wondering why it is so high. A 100 ms over a time lapse of 1000 s seems 100us/s, Is that possible?
In any case RTAI has a support to update the timebase so that it is kept aligned to any update of the system time to the real time. For that you should enable  "Support for Posix CLOCK_REALTIME APIs" (in Supported services), using rt_get_real_time and rt_get_real_time_ns to get the time. 
Then, instead of making it periodic, to set up  a periodic scheme based on the absolute real time, you should follow the following scheme :
period = nano2count(period_in_nanos=;
until = rt_get_real_time();
while(1) {
  rt_sleep_until(until += period);
  .
  .
}
Meanwhile an RTAI enabled Linux task should care of calling rt_gettimeorig now and then, to keep RTAI aligned to the system time.
To see what is all about I suggest looking at the related RTAI functions, is very simple. In case you'll need further help tell it to me. I'll try to find a bit of time to draft a simple test program.
Paolo

________________________________________
From: Randy Ricklefs [[email protected]]
Sent: Saturday, December 19, 2015 1:01 AM
To: Paolo Mantegazza; [email protected]
Subject: Re: [Rtai] How to tune one shot time period

Paolo,

A little bit of the set up and function calls are below. This is based
on the vgttime sample code from rtai.dk.
long ticks_per_second=0;
   ticks_per_second = (long)nano2count((RTIME)(1000000000));
....
   rt_set_oneshot_mode()
....
   start_rt_timer(0);
....
rt_task_make_periodic(hrttsk, rt_get_time()
/*+(RTIME)(period*ticks_per_second+.5)*/, (RTIME)(period*ticks_per_second));
....
   time=rt_get_time()/ticks_per_second;

During initialization, an offset between the timer and the system time
is calculated and applied thereafter, so system and counter times start
close and drift.

Randy

On 12/18/2015 04:49 PM, Paolo Mantegazza wrote:
> How do you set the period, i.e:  what RTAI timing function do you use for that?
> Paolo
> ________________________________________
> From: Rtai [[email protected]] on behalf of Randy Ricklefs [[email protected]]
> Sent: Friday, December 18, 2015 7:37 PM
> To: [email protected]
> Subject: [Rtai] How to tune one shot time period
>
> Hi,
>
> I am working on a project that requires a 100msec loop that has a drift
> of no more than about 100usec per hour. I am using the oneshot mode with
> RTAI 4.1 with kernel 3.10.32 on an i7 computer, and the 100msec period
> is very stable (+/- a few usec), but compared to the system time and UTC
> is actually larger than 100msec by an amount than creates a drift rates
> close to 10msec every 10 or 20 minutes. I have tried varying the 100msec
> period by small amounts to compensate, but the results are not
> satisfactory. I understand there is a method of calibrating the timer
> used for oneshots, but I have not found documentation of the procedure.
> Once calibrated, will the period remain stable, or are there temperature
> variations? Any help would be appreciated!
>
> Thanks!
>
> Best regards,
> Randy Ricklefs
> _______________________________________________
> Rtai mailing list
> [email protected]
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai


--
  -----------------------    Randy Ricklefs    ------------------------
                        [email protected]
      Center for Space Research,  The University of Texas at Austin
                            Austin TX 78712

_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.