Hello all,
I have few questions concerning the state/usage of rtnet:
Few? Quite a lot! ;)
Question 1:
Is it currently possible to have a _realtime_ communication between rtnet/rtai host and another host, which has _different_ realtime OS (like rtems, qnx, vx works)?
Communication: yes, the UDP/IP stack of RTnet interoperates with other implementations. Real-time: no. These systems are lacking a compatible media access control layer. And they also do not provide a real-time optimised network protocol stack (with respect to memory management and bounded execution time).
As I understand rtnet has a modified version of MAC (rtmac) and modified
Better: We add a MAC layer which avoids indeterministic states in the hard-wired Ethernet MAC protocol.
version of udp/ip. Then, I suppose I need also the equivalent stack implemented on second host (stack implementing the rtnet protocols)?
Yep. It is absolutely not impossible to set up an RTnet stack on some other RTOS.
Question 2:
Now let's take the system with 2 rtnet/rtai hosts. As I see there is no "realtime-tcp" implemented and to guarantee the reliability one need to do this by himself. So the question is, whether there is already a light "user-level library" which would take care of resending, timeouts, sequencing etc? Are there any
Yes, take a look at the ORTE project, an Open Source implementation of the standardised Real-Time Publish-Subscribe protocol. It is part of European OCERA project (www.ocera.org). If you want to run it with RTnet, make sure that you obtain a CVS checkout. AFAIK, no official ORTE release yet includes all patches to run with RTnet smoothly. The CVS does :)
plans/agenda to implement a realtime tcp (or another reliable protocol)?
Not yet, as such services typically collide with requirements of real-time systems: When something fails (a packet gets lost), you rather need a) some alarm or b) the next valid message containing the current status instead of a repeated outdated message. Furthermore, there is an inherent problem in the application programming model of stream-oriented protocols like TCP: in principle, the applications cannot control when and in which chunks the stream is transmitted (and it typically doesn't care as well). After writing some bytes, shall the stack send immediately or wait some more time?
BTW, RTPS uses for this reasons UDP and not TCP as transport protocol.
Question 3: Are there any viable open-source hard realtime systems, preferably comparable with rtnet+rtai+linux and not being based on Linux and offering realtime networking? What about RTEMS?
There are some academic real-time networking approaches. Some of them run on research RTOSes like described in "Low-latency Hard Real-Time Communication over Switched Ethernet" by Jork Loeser and Hermann Haertig, ECRTS 04, (running on DROPS) or the FTT-Ethernet (Flexibility, Timeliness and Efficiency over Ethernet, Paulo Pedreiras, Lu�s Almeida) which was implemented for SHARK. Don't know if any of these implementations are publically available.
RTEMS comes with a "normal" network stack without real-time optimisations (if I didn't oversee something the last time I checked).
Question 4: This one is maybe more concerning rtai.. Is it really OK to write hard realtime c and c++ programs in user space? It used to be only possible to write the user apps as kernel modules with all the inconveniences. Recently I read that you can do hard realtime in user space and in c++. But how mature is it? Is it working so good (stability, maturity) as kernel + c ? Are there any constraints / problems from the side of rtnet if I want to write a c/c++ program in user space, using rtnet for communication?
You "only" have to take care that your C++ runtime library behaves in a controllable way. Doing some unplanned malloc etc. can easily stop your real-time expedition. But this is a generic problem when using libraries in real-time programs.
Userspace is stable with RTAI for quite a long time. The latency is slightly higher, foremost due to the privilege level switches. RTnet also runs without known problems with LXRT. There is no C++ library for the RTnet API so far, neither in kernel (generally a bad idea) nor in userspace.
BTW, it's a nice piece of software!
Thanks.
What is your concern in RTnet and real-time networking about?
Jan
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ RTnet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/rtnet-users
