Hello,
I want to build a distributed kite control system.
We have at least two control-computers, one for the winch and one for
the kite.
If we link them with corba, is it realistic to reach a latency of less
then 50 ms,
that will not be a exceeded more than once per month?
(Kind of soft real-time?)
We can keep the load on both computers below 50% all the time, and the
network load below 10%.
One of the computers will be a core duo with 2,4 GHz, one an Atom with
1,6 Ghz,
both with Linux and Xenomai.
Perhaps someone did already latency measurement for a similar configuration.
Best regards:
Uwe Fechner
.
Any experiences with CORBA latency?
On Mon, Feb 28, 2011 at 8:59 PM, Uwe Fechner <u [dot] fechner [..] ...> wrote:
> Hello,
>
> I want to build a distributed kite control system.
>
> We have at least two control-computers, one for the winch and one for
> the kite.
>
> If we link them with corba, is it realistic to reach a latency of less
> then 50 ms,
> that will not be a exceeded more than once per month?
> (Kind of soft real-time?)
>
> We can keep the load on both computers below 50% all the time, and the
> network load below 10%.
>
> One of the computers will be a core duo with 2,4 GHz, one an Atom with
> 1,6 Ghz,
> both with Linux and Xenomai.
>
> Perhaps someone did already latency measurement for a similar configuration.
I think you will be fine. First of all, regarding your real-time
threads, they can read/write ports without switching out of the
real-time mode, since there is a decoupling buffer between the
component's thread and the CORBA threads. Next is your communication
itself. I don't see an immediate concern, but it's still not
guaranteed because of the non-realtime threading in CORBA :-),
especially on the Atom, which has less reserve. What is the size of
your data ?
We have closed 100Hz loops over a Corba network a few years ago.
In case you consider using the ROS (or yarp) transport, the same
principles apply: your thread will stay real-time and the transport
will do it's best effort.
Peter
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Any experiences with CORBA latency?
Hello Peter,
thanks for your answer.
The amount of data is small (probably only the cable force is really
important, and that is just
one integer value).
If we get this value 20 times per second, the control loop should work
fine, all the other data
can be updated less frequently.
Today I started to attend a course on distributed control, and learned,
how to describe the latency
and package error rate with simple statistical models.
The communication with the kite is a wireless communication, and not so
fast and reliable
anyway.
But I think, building a reliable, distributed control system (that
avoids it, that the kite falls
down to the earth) will be nevertheless possible.
In the moment, we have just four degrees of freedom in our system. But
this number will increase,
when we start to implement automated launch and retrieval. And than we
might need a faster
message transport system.
Regards:
Uwe
www.kitepower.eu
On 28.02.2011 21:21, Peter Soetens wrote:
> On Mon, Feb 28, 2011 at 8:59 PM, Uwe Fechner <u [dot] fechner [..] ...> wrote:
>> Hello,
>>
>> I want to build a distributed kite control system.
>>
>> We have at least two control-computers, one for the winch and one for
>> the kite.
>>
>> If we link them with corba, is it realistic to reach a latency of less
>> then 50 ms,
>> that will not be a exceeded more than once per month?
>> (Kind of soft real-time?)
>>
>> We can keep the load on both computers below 50% all the time, and the
>> network load below 10%.
>>
>> One of the computers will be a core duo with 2,4 GHz, one an Atom with
>> 1,6 Ghz,
>> both with Linux and Xenomai.
>>
>> Perhaps someone did already latency measurement for a similar configuration.
> I think you will be fine. First of all, regarding your real-time
> threads, they can read/write ports without switching out of the
> real-time mode, since there is a decoupling buffer between the
> component's thread and the CORBA threads. Next is your communication
> itself. I don't see an immediate concern, but it's still not
> guaranteed because of the non-realtime threading in CORBA :-),
> especially on the Atom, which has less reserve. What is the size of
> your data ?
>
> We have closed 100Hz loops over a Corba network a few years ago.
>
> In case you consider using the ROS (or yarp) transport, the same
> principles apply: your thread will stay real-time and the transport
> will do it's best effort.
>
> Peter
Any experiences with CORBA latency?
On Mon, 28 Feb 2011, Uwe Fechner wrote:
> Hello,
>
> I want to build a distributed kite control system.
>
> We have at least two control-computers, one for the winch and one for
> the kite.
>
> If we link them with corba, is it realistic to reach a latency of less
> then 50 ms,
> that will not be a exceeded more than once per month?
> (Kind of soft real-time?)
>
> We can keep the load on both computers below 50% all the time, and the
> network load below 10%.
>
> One of the computers will be a core duo with 2,4 GHz, one an Atom with
> 1,6 Ghz,
> both with Linux and Xenomai.
>
> Perhaps someone did already latency measurement for a similar configuration.
About five years or so ago, Peter Soetens and myself have been in a
European project in which Orocos and CORBA have been extensively tested for
hard realtime. Via the "collocation" primitive in (some) CORBA
implementations, we could close a control loop within 1ms, but only for
in-same-process threads. At that time, we had to patch the TAO
implementation to support collocation under RTAI Linux; I do not know the
state of the CORBA practice at this moment...
Anyway, realtime-readiness is in the first place a property of the
_implementation_, and not of the standard. The CORBA standard _is_ ready
for hard realtime; most of its implementations are not...
Here are some references:
<http://www.cs.wustl.edu/~schmidt/corba-research-realtime.html>
Herman