Paolo Mantegazza schrieb:
Giudici, Marina wrote:
Hello, I'm working with Real Time Workshop and RtaiLab.
I need to manage my local network, so I need to write new custom blocks
using s-functions. I suppose that I have to use RTNet calls in my blocks. Am
I right? Are there examples about menaging a lan with RTW and RtaiLab? Or is
anybody doing my same thing? I've never done net programming so I think I'll
need some help.. :)
You have to do nothing but install RTNet, all the rest comes by itself. Read NETRPC README.
There is a whole activity here at DIAPM on the subject, see: http://www.aero.polimi.it/~mbdyn/mbdyn-rt/index.html.
Interesting page! I will put a link on the RTnet homepage if it's ok. Paolo, do you already have some more background information about the hard real-time part of the network (configuration, benchmark figures, traps, pitfalls, or other experiences)? It would also be interesting to get on overview of the wire protocol of NetRPC. Knowing the communication characteristics will become helpful for system designers when scheduling the time slot on the real-time network (future versions of RTnet will add more flexibility to the RTmac disciplines).
I can just thank you for setting a link. The person that has put all the pieces toghether is Matteo Martegani, starting from an earlier work presented at the real time Linux conference in Valencia. Naturally working toghether with DIAPM RTAI and MBDyn people. Matteo is on both email lists and migh add something more.
At the moment my idea is to use a brute force RTNet approach, i.e. its very core and fast switches. I'm looking forward for your Gbits support :-). I'm not an expert of the stuff but I've read well written reports supporting the idea that a good ethernet layout, i.e. (in the most complex of our cases) a couple of real time cards per PC and fast switches, can reduce the worst case latency probability to fit practical determinism for controllers in the range of 1-2 KHz, which is what we need at the moment.
That does not mean that we will not exploit RTmac also. It is just what is enough for our beginning.
Although NetRPC is undoubtedly a very useful transparent communication mechanism, I think it's worth noting again that, as an additional abstraction layer, it can introduce noticeable overhead when exchanging lager amounts of data or calling RPC's too frequently (due to additional copy-steps and acknowledge packets). For certain scenarios, e.g. when using lower-end PCs (Pentium I class or worse), shared memory models or other application-specific protocols may be necessary to save resources.
Agreed, but at DIAPM it is impossible for us to use anything below a PII 200 MHz :-), on which the 1-2 Khz range applications do not suffer too much for NETRPC.
Take into account that NETRPC is very simple and has an overhead far below that of more complex middleware layers. Nonetheless it has some overhead as you suggest. What is important is that if you are forced to run a NETRPC applications on a single node, possibly SMP, it will need no changes and loose any overhead by simply setting all of the local nodes to zero. AFAIK at the moment the only people using it are here at DIAPM, where I'm advertising to develop new stuff using the RT_ prefix anywhere so that anything can work transparently in a local/distributed way.
Paolo.
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ RTnet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/rtnet-users
