...
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 :-).
Well, did you see the question mark? As with many nice ideas, it requires someone willing and able to do the work... :o)
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's true as long as
a) your real-time traffic show deterministic characteristics which avoid e.g. packet bursts against a single station (if your overall system design is time-driven and synchronized, then this generally also applies to the traffic) and
b) you don't try to put some non-real-time management or whatever traffic on your net (the temptation is always there :)).
This might not be critical in an experimental setup, but it is essential in production scenarios.
That does not mean that we will not exploit RTmac also. It is just what is enough for our beginning.
We should make it *mandatory* so that more people notice its benefits. ;)
...
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.
Are you planning to introduce some kind of brokerage mechanism to avoid that components need to know where their counterpart is located? Or is it already there and I'm missing something? We are also running a middleware above RTAI and RTnet, but it was helpful to make the components agnostic of the network structure (see our Valencia paper).
Jan
------------------------------------------------------- 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
