[Rtai] Time delay

[Carlos Jimenez - Encopim]

Hello,


I have a problem and I do not know if someone could help me.
I have a system where it seems that the cycles are delayed in time. I
configure a cycle at 5kHz of 10 seconds, and I take out an analog signal to
measure it with an external system.
In the cycle I collect the time through the instructions rt_get_time_ns ()
and rt_get_cpu_time_ns (), and according to the results, the cycle completes
correctly in 10 seconds (with nanoseconds of difference), but instead,
looking in the external system, I have always a delay of up to 2
milliseconds.
If I do not restart the computer, this delay remains constant, and each time
I restart the computer, this delay is modified.
It seems a problem directly with the computer (Siemens IPC427D), but does
anyone have any ideas?



Thank you in advance and best regards

[Graeme Foot]

Hi,

Linux calculates a Timebase Frequency on startup. It is only a quick calculation so that it does not hold up booting Linux for too long, but that also means it is not particulary accurate, and can be different each time you reboot Linux.

When you install the RTAI scheduler module if reports the timebase frequency being used, e.g.:
RTAI[sched]: Linux timer freq = 100 (Hz), TimeBase freq = 1398139005 hz.

When you install the RTAI scheduler module you can set your own explicit cpu frequency via the rtai_cpufreq_arg parameter. If you don't set this parameter then it will use the Linux calculated one. e.g.:
insmod rtai_hal.ko rtai_cpufreq_arg=1398139005

So to calibrate it to your external clock source:
- Run your test to get your external test time
- Look up the TimeBase freq from the syslog
- Calculate your calibrated TimeBase freq e.g.:
Calibrated TimeBase = Current TimeBase * expected time / measured time
- Use your calibrated timebase value when installing the RTAI scheduler


Notes:
- I'm still using RTAI 3.8.1 so things may be a little different now, but the concept should still be the same.
- I may have got the expected time vs measured time the wrong way around. If your time gets worse, swap them over.

Regards,
Graeme.

From: Rtai <rtai-***@rtai.org> On Behalf Of Carlos Jimenez - Encopim
Sent: Thursday, 20 September 2018 8:02 PM
To: ***@rtai.org
Subject: [Rtai] Time delay

Hello,

I have a problem and I do not know if someone could help me.
I have a system where it seems that the cycles are delayed in time. I configure a cycle at 5kHz of 10 seconds, and I take out an analog signal to measure it with an external system.
In the cycle I collect the time through the instructions rt_get_time_ns () and rt_get_cpu_time_ns (), and according to the results, the cycle completes correctly in 10 seconds (with nanoseconds of difference), but instead, looking in the external system, I have always a delay of up to 2 milliseconds.
If I do not restart the computer, this delay remains constant, and each time I restart the computer, this delay is modified.
It seems a problem directly with the computer (Siemens IPC427D), but does anyone have any ideas?

Thank you in advance and best regards

[Paolo Mantegazza]

Graeme explanation is still OK.
Nonetheless I think Linux frequency calibration should grant at least  a
factor of 10 better than what you get.
In any case you are likely running a controller with a cycle time of 200
us. Thus, you have an average  per cycle  uncertainty noise of 2 ms
divided by 50000 cycles, which should be negligible. What will affect
your controller most are worst latencies, likely in the range of 10 us.
The following note could still be of some interest:
General-Purpose Processors for Active Vibro-Acoustic Control: Discussion
and Experiences, Control Engineering Practice, Vol. 15, N. 2, 2007, p.
163-176.

Paolo

Hi,
Linux calculates a Timebase Frequency on startup.  It is only a quick
calculation so that it does not hold up booting Linux for too long,
but that also means it is not particulary accurate, and can be
different each time you reboot Linux.
When you install the RTAI scheduler module if reports the timebase
  RTAI[sched]: Linux timer freq = 100 (Hz), TimeBase freq = 1398139005 hz.
When you install the RTAI scheduler module you can set your own
explicit cpu frequency via the rtai_cpufreq_arg parameter.  If you
  insmod rtai_hal.ko rtai_cpufreq_arg=1398139005
- Run your test to get your external test time
- Look up the TimeBase freq from the syslog
  Calibrated TimeBase = Current TimeBase * expected time / measured time
- Use your calibrated timebase value when installing the RTAI scheduler
- I'm still using RTAI 3.8.1 so things may be a little different now,
but the concept should still be the same.
- I may have got the expected time vs measured time the wrong way
around.  If your time gets worse, swap them over.
Regards,
Graeme.
Encopim
*Sent:* Thursday, 20 September 2018 8:02 PM
*Subject:* [Rtai] Time delay
Hello,
I have a problem and I do not know if someone could help me.
I have a system where it seems that the cycles are delayed in time. I
configure a cycle at 5kHz of 10 seconds, and I take out an analog
signal to measure it with an external system.
In the cycle I collect the time through the instructions
rt_get_time_ns () and rt_get_cpu_time_ns (), and according to the
results, the cycle completes correctly in 10 seconds (with nanoseconds
of difference), but instead, looking in the external system, I have
always a delay of up to 2 milliseconds.
If I do not restart the computer, this delay remains constant, and
each time I restart the computer, this delay is modified.
It seems a problem directly with the computer (Siemens IPC427D), but
does anyone have any ideas?
Thank you in advance and best regards
_______________________________________________
Rtai mailing list
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai

[Carlos Jimenez - Encopim]

Hi,



Thank you for your answer, I have sent a request to download the document.



Regards



De: Paolo Mantegazza <***@polimi.it>
Enviado el: viernes, 21 de septiembre de 2018 10:16
Para: Graeme Foot <***@touchcut.com>; Carlos Jimenez - Encopim
<***@encopim.com>; ***@rtai.org
Asunto: Re: [Rtai] Time delay



Graeme explanation is still OK.
Nonetheless I think Linux frequency calibration should grant at least a
factor of 10 better than what you get.
In any case you are likely running a controller with a cycle time of 200 us.
Thus, you have an average per cycle uncertainty noise of 2 ms divided by
50000 cycles, which should be negligible. What will affect your controller
most are worst latencies, likely in the range of 10 us.
The following note could still be of some interest:
General-Purpose Processors for Active Vibro-Acoustic Control: Discussion and
Experiences, Control Engineering Practice, Vol. 15, N. 2, 2007, p. 163-176.

Paolo

On 09/21/2018 01:40 AM, Graeme Foot wrote:

Hi,



Linux calculates a Timebase Frequency on startup. It is only a quick
calculation so that it does not hold up booting Linux for too long, but that
also means it is not particulary accurate, and can be different each time
you reboot Linux.



When you install the RTAI scheduler module if reports the timebase frequency
being used, e.g.:

RTAI[sched]: Linux timer freq = 100 (Hz), TimeBase freq = 1398139005 hz.



When you install the RTAI scheduler module you can set your own explicit cpu
frequency via the rtai_cpufreq_arg parameter. If you don't set this
parameter then it will use the Linux calculated one. e.g.:

insmod rtai_hal.ko rtai_cpufreq_arg=1398139005



So to calibrate it to your external clock source:

- Run your test to get your external test time

- Look up the TimeBase freq from the syslog

- Calculate your calibrated TimeBase freq e.g.:

Calibrated TimeBase = Current TimeBase * expected time / measured time

- Use your calibrated timebase value when installing the RTAI scheduler





Notes:

- I'm still using RTAI 3.8.1 so things may be a little different now, but
the concept should still be the same.

- I may have got the expected time vs measured time the wrong way around.
If your time gets worse, swap them over.



Regards,

Graeme.



From: Rtai <mailto:rtai-***@rtai.org> <rtai-***@rtai.org> On Behalf
Of Carlos Jimenez - Encopim
Sent: Thursday, 20 September 2018 8:02 PM
To: ***@rtai.org <mailto:***@rtai.org>
Subject: [Rtai] Time delay



Hello,


I have a problem and I do not know if someone could help me.
I have a system where it seems that the cycles are delayed in time. I
configure a cycle at 5kHz of 10 seconds, and I take out an analog signal to
measure it with an external system.
In the cycle I collect the time through the instructions rt_get_time_ns ()
and rt_get_cpu_time_ns (), and according to the results, the cycle completes
correctly in 10 seconds (with nanoseconds of difference), but instead,
looking in the external system, I have always a delay of up to 2
milliseconds.
If I do not restart the computer, this delay remains constant, and each time
I restart the computer, this delay is modified.
It seems a problem directly with the computer (Siemens IPC427D), but does
anyone have any ideas?



Thank you in advance and best regards

[Carlos Jimenez - Encopim]

Hi,



Thank you for your answer, I will try this solution.



regards



De: Graeme Foot <***@touchcut.com>
Enviado el: viernes, 21 de septiembre de 2018 1:41
Para: Carlos Jimenez - Encopim <***@encopim.com>; ***@rtai.org
Asunto: RE: [Rtai] Time delay



Hi,



Linux calculates a Timebase Frequency on startup. It is only a quick
calculation so that it does not hold up booting Linux for too long, but that
also means it is not particulary accurate, and can be different each time
you reboot Linux.



When you install the RTAI scheduler module if reports the timebase frequency
being used, e.g.:

RTAI[sched]: Linux timer freq = 100 (Hz), TimeBase freq = 1398139005 hz.



When you install the RTAI scheduler module you can set your own explicit cpu
frequency via the rtai_cpufreq_arg parameter. If you don't set this
parameter then it will use the Linux calculated one. e.g.:

insmod rtai_hal.ko rtai_cpufreq_arg=1398139005



So to calibrate it to your external clock source:

- Run your test to get your external test time

- Look up the TimeBase freq from the syslog

- Calculate your calibrated TimeBase freq e.g.:

Calibrated TimeBase = Current TimeBase * expected time / measured time

- Use your calibrated timebase value when installing the RTAI scheduler





Notes:

- I'm still using RTAI 3.8.1 so things may be a little different now, but
the concept should still be the same.

- I may have got the expected time vs measured time the wrong way around.
If your time gets worse, swap them over.



Regards,

Graeme.



From: Rtai <rtai-***@rtai.org <mailto:rtai-***@rtai.org> > On Behalf
Of Carlos Jimenez - Encopim
Sent: Thursday, 20 September 2018 8:02 PM
To: ***@rtai.org <mailto:***@rtai.org>
Subject: [Rtai] Time delay



Hello,


I have a problem and I do not know if someone could help me.
I have a system where it seems that the cycles are delayed in time. I
configure a cycle at 5kHz of 10 seconds, and I take out an analog signal to
measure it with an external system.
In the cycle I collect the time through the instructions rt_get_time_ns ()
and rt_get_cpu_time_ns (), and according to the results, the cycle completes
correctly in 10 seconds (with nanoseconds of difference), but instead,
looking in the external system, I have always a delay of up to 2
milliseconds.
If I do not restart the computer, this delay remains constant, and each time
I restart the computer, this delay is modified.
It seems a problem directly with the computer (Siemens IPC427D), but does
anyone have any ideas?



Thank you in advance and best regards