Discussion:
[Rtai] Does RTAI 5.1 work? Also, quick calibration question
Alec Ari
2018-10-08 02:14:40 UTC
Permalink
Does anyone have RTAI 5.1 working, besides Paolo? Seb (LinuxCNC) tried getting RTAI 5.0.1 working, but the system would crash upon unloading the modules. I experienced the same issue, and other sporadic crashes, and everyone I know has stopped bothering with it due to instability. With RTAI 5.1, has this issue been fixed? I remember there was talk about violated usage of syscalls or something, could that have been the problem? Something about RTAI_USE_STACK_ARGS?

I'm a bit out of touch with the latest RTAI code, but it'd be nice to switch to RTAI 5 considering RTnet is working again, thank you Paolo for the information. Who did the RTnet update btw? I bet that was a real pain to get working with 4.x kernels.

If anyone can confirm RTAI 5 is working for them, that'd be great. All I'm looking for is just some positive feedback. RTAI 5 has re-worked calibration code (which is where I think this damage occurred) but I am a bit confused as to why RTAI needs to "calibrate" at all since latency is generally under 20 microseconds, under 5 microseconds if you don't use Firefox. Does calibrating RTAI and mucking with those values affect the latency spikes you'll get when watching YouTube videos or is this inevitable? Can anyone guess as to why Firefox causes such a dramatic and nearly instant impact on latency? After your real-time code is loaded and your threads are hard real-time, that shouldn't happen. Browsing YouTube should _always_ be a lower priority to the kernel than your real-time code and should not interfere with those hard real-time threads. If there's a delay, YouTube can wait. The most important and highest priority thread should _always_ be real-time.

Thank you!

Alec
Felix Frey
2018-10-08 06:41:31 UTC
Permalink
We are running RTAI 5.1 with kernel 4.9.80 without problems on a AMD
quad core R-series CPU.
I can't say anything about Firefox, Youtube or so because it's an embedded
system without graphics and just a handful of tasks running.

Felix
Post by Alec Ari
Does anyone have RTAI 5.1 working, besides Paolo? Seb (LinuxCNC)
tried getting RTAI 5.0.1 working, but the system would crash upon
unloading the modules. I experienced the same issue, and other
sporadic crashes, and everyone I know has stopped bothering with it
due to instability. With RTAI 5.1, has this issue been fixed? I
remember there was talk about violated usage of syscalls or
something, could that have been the problem? Something about
RTAI_USE_STACK_ARGS?
I'm a bit out of touch with the latest RTAI code, but it'd be nice to
switch to RTAI 5 considering RTnet is working again, thank you Paolo
for the information. Who did the RTnet update btw? I bet that was a
real pain to get working with 4.x kernels.
If anyone can confirm RTAI 5 is working for them, that'd be great.
All I'm looking for is just some positive feedback. RTAI 5 has
re-worked calibration code (which is where I think this damage
occurred) but I am a bit confused as to why RTAI needs to "calibrate"
at all since latency is generally under 20 microseconds, under 5
microseconds if you don't use Firefox. Does calibrating RTAI and
mucking with those values affect the latency spikes you'll get when
watching YouTube videos or is this inevitable? Can anyone guess as to
why Firefox causes such a dramatic and nearly instant impact on
latency? After your real-time code is loaded and your threads are
hard real-time, that shouldn't happen. Browsing YouTube should
_always_ be a lower priority to the kernel than your real-time code
and should not interfere with those hard real-time threads. If
there's a delay, YouTube can wait. The most important and highest
priority thread should _always_ be real-time.
Thank you!
Emmanuel Pacaud
2018-10-08 06:52:53 UTC
Permalink
Hi,


Cheers,

Emmanuel.
Post by Alec Ari
Does anyone have RTAI 5.1 working, besides Paolo? Seb (LinuxCNC)
tried getting RTAI 5.0.1 working, but the system would crash upon
unloading the modules. I experienced the same issue, and other
sporadic crashes, and everyone I know has stopped bothering with it
due to instability. With RTAI 5.1, has this issue been fixed? I
remember there was talk about violated usage of syscalls or
something, could that have been the problem? Something about
RTAI_USE_STACK_ARGS?
I have a working setup with rtai 5.1 and linux 4.9.80, on a CentOS 7
base. I have started from a standard linux configuration extracted from
a linux 4.4 RPM package downloaded here:
http://elrepo.org/linux/kernel/el7/x86_64/RPMS/

Then applied what I have seen in README.CONF_RMRKS.

The linux kernel comes from kernel.org.
Post by Alec Ari
If anyone can confirm RTAI 5 is working for them, that'd be great.
All I'm looking for is just some positive feedback. RTAI 5 has
re-worked calibration code (which is where I think this damage
occurred) but I am a bit confused as to why RTAI needs to "calibrate"
at all since latency is generally under 20 microseconds, under 5
microseconds if you don't use Firefox. Does calibrating RTAI and
mucking with those values affect the latency spikes you'll get when
watching YouTube videos or is this inevitable? Can anyone guess as to
why Firefox causes such a dramatic and nearly instant impact on
latency? After your real-time code is loaded and your threads are
hard real-time, that shouldn't happen. Browsing YouTube should
_always_ be a lower priority to the kernel than your real-time code
and should not interfere with those hard real-time threads. If
there's a delay, YouTube can wait. The most important and highest
priority thread should _always_ be real-time.
The latency spike you see watching youtube videos from firefox can come
from the hardware used for video decoding and may be GPU used for html
display itself.

If you want reliable realtime performance, you should run only the bare
minimal required by your task.

Cheers,

Emmanuel.
Emmanuel Pacaud
2018-10-08 08:20:49 UTC
Permalink
I forgot to tell a word about the machines. We are using DELL T630,
R730 and T640 servers. These servers are great for their remote
management system (Idrac), but I would not recommend them as they are
complex beast, with a gazillion devices on the PCI bus. Their power
management is the cause of increased latencies, when one of the
redundant power supplies is disconnected for example.

Cheers,

Emmanuel.

Le lun. 8 oct. 2018 à 8:52, Emmanuel Pacaud
Post by Emmanuel Pacaud
Post by Alec Ari
Does anyone have RTAI 5.1 working, besides Paolo? Seb (LinuxCNC)
tried getting RTAI 5.0.1 working, but the system would crash upon
unloading the modules. I experienced the same issue, and other
sporadic crashes, and everyone I know has stopped bothering with it
due to instability. With RTAI 5.1, has this issue been fixed? I
remember there was talk about violated usage of syscalls or
something, could that have been the problem? Something about
RTAI_USE_STACK_ARGS?
I have a working setup with rtai 5.1 and linux 4.9.80, on a CentOS 7
base. I have started from a standard linux configuration extracted
http://elrepo.org/linux/kernel/el7/x86_64/RPMS/
Then applied what I have seen in README.CONF_RMRKS.
The linux kernel comes from kernel.org.
Alec Ari
2018-10-08 19:35:55 UTC
Permalink
The latency spike you see watching youtube videos from firefox can come from the hardware used for video decoding and may be GPU used for html display itself.
If you want reliable realtime performance, you should run only the bare minimal required by your task.
Cheers,
Emmanuel.
Even if I have AGP and DRM disabled, using llvmpipe or even softpipe (software rendering Mesa drivers, softpipe being the simpler one) and even tried vesa and fbdev video drivers, still not much improvement. Using xf86-video-fbdev or xf86-video-vesa without any 2D nor 3D hardware acceleration should fix this issue, but it doesn't. If I want reliable real-time performance, the kernel should know better than to not have anything interrupt the real-time task. Simply launching Firefox can cause a latency spike too, and like I said, should be lower priority.

So if calibration isn't related to these spikes, what is it for, if RTAI is supposed to work this way? I've never tampered with the calibration code, but I have considered porting the old calibration code from RTAI 3 and 4 to RTAI 5 to see if the system hangs go away, but as you and Felix are not having issues, perhaps the bug is gone.

Oh by the way, the complexity of those DELL systems made me chuckle.

Thank you for the feedback everyone!

Alec

Loading...