On Tue, Jul 17, 2012 at 01:57:49PM -0700, Soo-Hyun Yoo wrote:
> Hello,
>
> Has anyone benchmarked Orocos Ports and EventPorts for speed?
>
> We tried to do so on a Zotac ZBOX nettop with an Intel Atom processor,
> running a PREEMPT_RT kernel, with the code posted here:
> http://code.google.com/p/atrias/source/browse/#svn%2Fbranches%2Forocepti...
> . We deploy 100 components, where each component passes a timestamp
> (of type suseconds_t) to the next component's EventPort. We give each
> component real-time priority from the command line with "chrt -pa 99
> $PID", where $PID is the process ID of the deployer.
>
> With this code, we determined that each port-to-port data transfer
> takes about 17 microseconds.

> Does this sound like a reasonable number?

Yes, it will be in this order of magnitude, but probably could be
somewhat better. I once determined an average of 16us (50us
worst-case) for two transfers (request->response) using xenomai. See
this [1], 4.2.

Markus

[1] https://lwn.net/images/conf/rtlws-2011/paper.05.html

On Tue, Jul 17, 2012 at 10:57 PM, Soo-Hyun Yoo <yoos117 [..] ...> wrote:

> Hello,
>
> Has anyone benchmarked Orocos Ports and EventPorts for speed?
>
> We tried to do so on a Zotac ZBOX nettop with an Intel Atom processor,
> running a PREEMPT_RT kernel, with the code posted here:
>
> http://code.google.com/p/atrias/source/browse/#svn%2Fbranches%2Forocepti...
> . We deploy 100 components, where each component passes a timestamp
> (of type suseconds_t) to the next component's EventPort. We give each
> component real-time priority from the command line with "chrt -pa 99
> $PID", where $PID is the process ID of the deployer.
>
> With this code, we determined that each port-to-port data transfer
> takes about 17 microseconds.
>
> Does this sound like a reasonable number?
>

The major delay here is (probably) caused by the context switching of the
threads/kernel + the call back mechanism, not by the port copying data.

> Can the ConnPolicy, etc, be configured in any way to reduce the latency?
>

Yes, use a UNSYNC lock_policy type. This is the most efficient port
implementation, not thread-safe.

But you should only use it if both components (reader+writer) run in the
same thread. Otherwise,
there's no way to guarantee that both do not read/write at the same time.

Peter