[certi-dev] CERTI performance issue

[Eric Noulard]

I'm starting another thread of discussion for this.

2009/5/29 Michael Raab <address@hidden>:
>
> Here some more infos on my experiments:
>
> Setup:
> 3 federates ( discrete event simulations )
> SimulationTime 40000 units
> Lookahead 0.5

How long does this simulation run (elapse time)?
I mean I want to check how many time advancing steps
per second you get.

thus we need:
    3 federates:
        are they all tree time regulating and time constrained?
        I bet they are from the message they send.
    SimulationTime 40000 units
    Lookahead 0.5
        you mean 0.5 unit of time compared to your 40000 unit duration right?
    Elapsed (Wall Clock) Time : ??
    We lack some network topology figures, do each federate run
    on a same machine or are they on separate hosts.
    Where is the RTIG running? Does it shares a host with one or several
    federate?
    If some federate (or the RTIG) are running a the same machine
    it would be interesting to know if this machine is mono-processor/core
    or multi-processor/core.

> rtig:

RTIG stats looks OK.
RTIG has sent 4.9Mio to each Federate
and received 2.5Mio from each of them.

Note the unit shown by RTIG may be misleading
5305663b means 5305663 bytes and not bits.

This makes aggregate sent volume of 14.7 Mio
and 7.5 Mio received.

This may be relatively high figures depending on the elapse time
for this simulation.
What is the speed of your network 100Mb/s?

> rtia (Fed1):
> - crashed after simulation when deleting the rtiAmbassador

This is weird.
Would you be able to update an rerun
in order to see if recently fixed bug
http://savannah.nongnu.org/bugs/?26610
improves this situation.

> rtia (Fed2):
>
> List of federate initiated services
> --------------------------------------------------
>      546 Message::SEND_INTERACTION (MSG#44)
>     2596 Message::NEXT_EVENT_REQUEST (MSG#93)
>    85253 Message::TICK_REQUEST (MSG#141)
>     3692 Message::TICK_REQUEST_NEXT (MSG#142)

As you can see your federate is sending a huge number of tick request.
Which version of tick are you using in your federate?
Is is
RTI::RTIambassador::tick(TickTime minimum, TickTime maximum)
or
RTI::RTIambassador::tick()

The drawback of the former parameter-less tick is that it won't block
thus calling tick() in a tight waiting loop may generate a lot of useless
message.

> List of RTI initiated services
> --------------------------------------------------
>   158687 NetworkMessage::MESSAGE_NULL (MSG#2)
>     1093 NetworkMessage::REFLECT_ATTRIBUTE_VALUES (MSG#45)

You get an even greater volume of NULL Message which would means
you federation has trouble for advancing in time (like with a
zero-lookahead case).

>  Number of Federate messages : 94293
>  Number of RTIG messages : 160112
>
> rtia (Fed3):
>
> List of federate initiated services
> --------------------------------------------------
>     2185 Message::UPDATE_ATTRIBUTE_VALUES (MSG#41)
>     2732 Message::NEXT_EVENT_REQUEST (MSG#93)
>     2188 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
>     2190 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
>    85375 Message::TICK_REQUEST (MSG#141)
>     3280 Message::TICK_REQUEST_NEXT (MSG#142)
>
> List of RTI initiated services
> --------------------------------------------------
>   159965 NetworkMessage::MESSAGE_NULL (MSG#2)
>      546 NetworkMessage::RECEIVE_INTERACTION (MSG#47)
>
>  Number of Federate messages : 97967
>  Number of RTIG messages : 160844

Same remarks as for Fed2, there is too many ticks and far more too
many NULL Message.

May be some more information on the data exchange pattern of those
federate would
help to understand what is happening.

It seems like Fed3 received all 546 SendInteraction (SI) from Fed2.
Fed3 is the one doing UpdateAttributeValues (UAV  -  2185) but Fed2 got
only part of it (RAV - 1093).

Fed1 data exchnage pattern is missing.

It would be interesting to know the size of data send withing UAV.

If your source code may be shared I may try to run the very same setup
on a Linux config in order to see if I get similar figures.

Just a remark savannah.org looks down this morning
at least from my site. It's a very rare event which does not usually last long.
The mailing list usually stay up running.

-- 
Erk