Hi Max,
My two cents:
If possible, could you please send also the main() function, so
I can check what update rate I get on my machine?
Besides the byte counters you sent, each federate (RTIA) should
at the end print “RTIA: Statistics (processed messages)”. This list
shows number of messages sent/received by RTIA. One of the lines is
Message::TICK_REQUEST. These numbers should have reasonable values, none should
be extremely high.
I don’t recommend using the parameter-less non-blocking
tick() function. Especially when used in the main loop the tick() generates
extreme overhead. Each tick() invocation generates one TICK_REQUEST message.
If you just wait for a federate service (callback) invocation,
you may want to use the tick(p1, p2) function. The function will wait for a
callback for p1 seconds and then invokes one or more incoming callbacks, for up
to p2 seconds. If you do nothing but tick-ing, there is no need for the tick()
to finish and restart again. You may thus even use
std::numeric_limits<double>::infinity() as p1 and p2. In that case the
tick() will be blocked until some callback comes, so the tick-ing overhead will
be minimized.
Please let me know if it helped.
Best Regards,
Petr
From:
address@hidden
[mailto:address@hidden On
Behalf Of ?????? ??????
Sent: Friday, April 10, 2009 11:01 AM
To: CERTI development discussions
Subject: Re: [certi-dev] Speed of attributes updates beetwen two
federates with time managenment enabled
> On which OS do you run
(Windows, Linux, Solaris etc...,)
Vista 32bit SP1
Intel DualCore 3.0GHz 2Gb RAM .....
>Are your two federates on the same OS or is your simulation
"heterogeneous"
> i.e. one on Windows XP 32bits and the other on Linux AMD64 or ...
try Vista+vista, Vista+XP, XP+Kubintu = updates is about 15-20 updates
per second (100mbit network)
> Which version of CERTI do you use?
certi-3.3.1-Source
> If the load is high then check the amount of
Message::TICK_REQUEST (see below)
How get Message::TICK_REQUEST?
> B) Federation information
> What is the lookahead of the time-regulating federate?
federateLookahead = 1.0;
> Does the two federates exchange data i.e.
one is posting UAV for the other but does the second post UAV
for the first too?
Yes.
>C) More tests
> Can you run the federation on the same machine?
Ok. 25-30 updates per second
> Each federates should print out statistics at the end of the run
would you be able to send us those statistics?
RTIG:
TCP Socket 184 : total = 30824b sent
TCP Socket 184 : total = 3851b received
UDP Socket 128 : total =
0b sent
UDP Socket 128 : total =
0b received
TCP Socket(RecevoirTCP) : No error
RTIG dropping client connection 172.
TCP Socket 172 : total = 112614b sent
TCP Socket 172 : total = 142891b received
UDP Socket 128 : total =
0b sent
UDP Socket 128 : total =
0b received
>May be you can send us your test code (2 federates
+ Fed File) which
exhibits this performance and we may try to run your federation
in our context?
OK.... federate->updateFederateTime() call in main loop (
<= 60 calls per second)
8 апреля 2009 г. 14:26 пользователь Eric Noulard <address@hidden> написал:
2009/4/8 Максим Гаммер <address@hidden>:
> Hello,
>
> there are two federates, one is time-regulating and another is ither
> time-constrained or without time management at all. The speed of attribute
> updates is about 15-20 updates per second (100mbit network).
This seems slow, but performance heavily depends on many
parameters.
What kind of performance do you seek?
Thus could you gives us more informations:
A) OS Version / Hardware info
- On which OS do you run (Windows, Linux, Solaris etc...,)
- Are your two federates on the same OS or is your simulation
"heterogeneous"
i.e. one on Windows XP 32bits and the other on Linux AMD64 or ...
- Which version of CERTI do you use?
3.3.0, 3.3.1, CVS etc...
Did you compiled CERTI yourself? If yes what was the compiler?
- What kind of machine do you use ? (processor, memory, etc...)
In any case how is the load of the two machines during the test?
If the load is high then check the amount of
Message::TICK_REQUEST (see below)
B) Federation information
- What is the lookahead of the time-regulating federate?
- What is the amount of data exchange for each UAV?
- Does the two federates exchange data i.e.
one is posting UAV for the other but does the second post UAV
for the first too?
C) More tests
- Can you run the federation on the same machine?
- Each federates should print out statistics at the end of the run
would you be able to send us those statistics?
In particular you should have an amount of
NetworkMessage::MESSAGE_NULL
not too bigger than the amount of
NetworkMessage::REFLECT_ATTRIBUTE_VALUES
The number of Message::TICK_REQUEST and
Message::TICK_REQUEST_NEXT should be in the same
order (may be twice as big) as NetworkMessage::REFLECT_ATTRIBUTE_VALUES.
If this is not the case then something may be done to improve
performance.
- May be you can send us your test code (2 federates + Fed File) which
exhibits this performance and we may try to run your federation
in our context?
> Is it normal or I'm doing somethis wrong?
Cannot tell :-)
I'll be off network for a while, so I may be unable to answer :-(
Either someone else will answer to you (Petr, Pierre, Christian, Martin?)
or I'll come back to you in a week or so.
--
Erk
--
CERTI-Devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/certi-devel