[tao-users] Multi-core real-time event channel; mt dispatching strategy

[Chao Wang 王超]

TAO VERSION: 2.4.6
ACE VERSION: 6.4.6

HOST MACHINE and OPERATING SYSTEM:

       (event supplier) Pentium Dual-Core 3.2GHz, Ubuntu Linux with
kernel v3.19.0

        (event service) Intel i5-4590 3.3GHz, four-core machine,
Ubuntu Linux with kernel v4.2.0

        (event consumer) Pentium Dual-Core 3.2GHz, Ubuntu Linux with
kernel v3.13.0

THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform- specific
file, simply state which one]:

       #include "ace/config-linux.h"

THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you use a
link to a platform-specific file, simply state which one (unless this isn't
used in this case, e.g., with Microsoft Visual C++)]:

       CPPFLAGS += -std=c++11

       include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU


CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features (used
by MPC when you generate your own makefiles):

    I don't have such a file.

    AREA/CLASS/EXAMPLE AFFECTED:
[What example failed?  What module failed to compile?]

    $TAO_ROOT/orbsvcs/examples/RtEC/Simple

    mt dispatching strategy

    DOES THE PROBLEM AFFECT:
        COMPILATION?  no
        LINKING?   no
        EXECUTION?  yes
[Please indicate whether ACE/TAO, your application, or both are affected.]
     The TAO real-time event service is affected.

    SYNOPSIS:
[Brief description of the problem]

    With the mt dispatching strategy the event service did not respond
to supplier pushes; with the reactive dispatching strategy it worked
fine.

DESCRIPTION: [Detailed description of problem. Don't just say "<blah>
doesn't work, here's a fix," explain what your program does to get to the
<blah> state. ]

 I was doing stress tests for the TAO real-time event service, with
one supplier (on host 1), one event service (on host 2, along with the
naming service), and one consumer (on host 3). I used the example
shipped with the TAO 2.4.6 release:
$TAO_ROOT/orbsvcs/examples/RtEC/Simple , with the following changes:
(1) the supplier ran an infinite loop pushing events without any
sleep. (2) the consumer printed log message every 100,000 events. (3)
the following ec.conf:

static EC_Factory "-ECDispatching mt -ECDispatchingThreads 3
-ECFiltering basic -ECSupplierFiltering per-supplier
-ECProxyConsumerLock thread -ECProxySupplierLock thread
-ECConsumerControl reactive -ECSupplierControl reactive
-ECConsumerControlPeriod 0 -ECSupplierControlPeriod 0
-ECProxyPushSupplierCollection mt:list:immediate
-ECProxyPushConsumerCollection mt:list:immediate"

I saw that the event service did not crash but did not respond to
supplier pushes either. On the supplier host the supplier kept pushing
events, but on the service host (where event service ran) the system
utilization was almost zero. Then I killed everything and switched
back to the original ec.conf (which used the reactive dispatching
strategy), and it worked fined, showing that one CPU core on the
service host reached 100% CPU utilization, and consumer got events.

I tried another case: I collocated supplier, consumer, and the event
service on the same host (The Intel i5-4590 3.3GHz, four-core
machine), then it seemed to work fine for about two to three minutes
(CPU utilization: supplier ~100%, service ~130%, consumer ~66% and got
events), but after that it crashed, printing "ERROR: Supplier
timeout". Again, if I use the original ec.conf then everything works
fine. The original ec.conf is as follows:

static EC_Factory "-ECDispatching reactive -ECFiltering basic
-ECSupplierFiltering per-supplier -ECProxyConsumerLock thread
-ECProxySupplierLock thread -ECConsumerControl reactive
-ECSupplierControl reactive -ECConsumerControlPeriod 50000
-ECSupplierControlPeriod 50000"

Does the real-time event channel support multi-core architecture? How
to configure the event channel to properly utilize all cores?


Thank you,

Chao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/tao-users/attachments/20180214/e1f4ac13/attachment.html>