Thu 28 May 2009 08:30:07 PM UTC, comment #14:
Ok guys,
After small discussion with Pierre and some rough testing
we would say that TAR, TARA, NER, NERA may not
be "timestamp" event like UAV or SI thus we can advance
in time "below the lookahead" but after current time.
I've just checked-in the fix (as suggested by Michael)
in CVS HEAD.
Done for: TAR, TARA, NER, NERA.
Please update and check if it works for you.
We would need a regression test case for this in HLA TestSuite
thus I maintain the bug as "in progress" until we have one.
|
Thu 28 May 2009 09:16:29 AM UTC, comment #13:
OK then,
I think the previous "non-working" patch wasn't working
because the zero-lookahead code from Pierre was broken
at that time.
It was broken because of me :-(
Thus it appears that the non working patch *seems
to be working* now that zero lookahead is un-broken.
Concerning the lack of performance, I suggest you
open another bug/feature entry and/or discuss this
issue on the ML.
It would be interesting to know thenumber of messages
sent/received by your federate, please copy paste
CERTI message summary found at the end of each federate
run.
Something like:
RTIA: Statistics (processed messages)
List of federate initiated services
--------------------------------------------------
1 Message::CLOSE_CONNEXION (MSG#1)
1 Message::JOIN_FEDERATION_EXECUTION (MSG#4)
1 Message::RESIGN_FEDERATION_EXECUTION (MSG#5)
1 Message::SYNCHRONIZATION_POINT_ACHIEVED (MSG#10)
1 Message::PUBLISH_OBJECT_CLASS (MSG#28)
1 Message::PUBLISH_INTERACTION_CLASS (MSG#30)
1 Message::SUBSCRIBE_OBJECT_CLASS_ATTRIBUTES (MSG#32)
1 Message::SUBSCRIBE_INTERACTION_CLASS (MSG#34)
1 Message::REGISTER_OBJECT_INSTANCE (MSG#40)
3388 Message::UPDATE_ATTRIBUTE_VALUES (MSG#41)
22 Message::SEND_INTERACTION (MSG#44)
1 Message::DELETE_OBJECT_INSTANCE (MSG#46)
1 Message::ENABLE_TIME_REGULATION (MSG#80)
1 Message::DISABLE_TIME_REGULATION (MSG#81)
1 Message::ENABLE_TIME_CONSTRAINED (MSG#82)
1 Message::DISABLE_TIME_CONSTRAINED (MSG#83)
3389 Message::QUERY_FEDERATE_TIME (MSG#85)
3388 Message::TIME_ADVANCE_REQUEST (MSG#91)
2 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
3 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
1 Message::GET_INTERACTION_CLASS_HANDLE (MSG#116)
3 Message::GET_PARAMETER_HANDLE (MSG#118)
1 Message::GET_OBJECT_CLASS (MSG#127)
40555 Message::TICK_REQUEST (MSG#141)
10223 Message::TICK_REQUEST_NEXT (MSG#142)
List of RTI initiated services
--------------------------------------------------
6776 NetworkMessage::MESSAGE_NULL (MSG#2)
4 NetworkMessage::SET_TIME_REGULATING (MSG#7)
1 NetworkMessage::TIME_REGULATION_ENABLED (MSG#9)
1 NetworkMessage::TIME_CONSTRAINED_ENABLED (MSG#10)
1 NetworkMessage::ANNOUNCE_SYNCHRONIZATION_POINT (MSG#13)
1 NetworkMessage::FEDERATION_SYNCHRONIZED (MSG#15)
2 NetworkMessage::DISCOVER_OBJECT (MSG#43)
6776 NetworkMessage::REFLECT_ATTRIBUTE_VALUES (MSG#45)
55 NetworkMessage::RECEIVE_INTERACTION (MSG#47)
2 NetworkMessage::REMOVE_OBJECT (MSG#49)
40 NetworkMessage::GET_FED_FILE (MSG#84)
Number of Federate messages : 60989
Number of RTIG messages : 13659
|
Thu 28 May 2009 07:17:02 AM UTC, comment #12:
Hi Eric and Christian,
for us it helped to remove some lines from TimeManagement.cc .
As we are just using nextEventRequest to advance time, we removed the following test from the appropriate function:
if( heure_logique < _heure_courante + _lookahead_courant)
e = e_InvalidFederationTime;
The same test is also included in function timeAdvanceRequest, so my suggestion would be to remove both.
I think this was also included in adele's (non-working) patch.
Our test case executes now, just need to check if the results are reasonable.
Btw, at the moment CERTI seems to lack performance in respect to DMSO RTI, when using time sync mechanisms.
Yesterday, i did some short measurements and got the following results for our test case:
Test 1: Lookahead=0.5 -> DMSO 175 s, CERTI 1200s
Test 2: Lookahead=5 -> DMSO 103s, CERTI 161s
regards,
Michael
|
Wed 27 May 2009 05:27:21 PM UTC, comment #11:
Hi Michael and Christian,
Don't know where Martin (aka adele) did stop concerning this bug.
Since he won't be back before beginning of june.
If you are in a hurry, do not hesitate to provide a patch
I'll review it.
If you can please give us a test case to be added to HLA Tests Suite such that we can be sure not to break this in the
future.
|
Mon 25 May 2009 08:15:17 AM UTC, comment #10:
Hello,
I also need a solution for this bug because I'm currently working on a discrete event scheduler based on CERTI.
So if I can help let me know. Since Adele is in vacation perhaps anybody else have some information about the progress and the problems concerned to this bug.
|
Wed 20 May 2009 07:07:55 AM UTC, comment #9:
Status is "In Progress",
Adele should work on this, but he is currently on vacation.
(returns something like in the beginning of June)
However may be you want to give it a try yourself?
|
Wed 20 May 2009 06:54:37 AM UTC, comment #8:
Hello,
i'm very interested in a fix for this bug.
What's the status?
kind regards,
Michael
|
Fri 13 Mar 2009 03:24:48 PM UTC, comment #7:
do not test this patch.
(file #17675)
|
Tue 10 Mar 2009 05:52:08 PM UTC, comment #6:
Hi Steffen,
You have right. The InvalidFederationTime exception is thrown
when the time requested to advance is less or equal to
(the last granted time + current lookahead) The exception
is thrown when a TAR is invoqued as well.
Fix asap. Thanks.
|
Fri 06 Mar 2009 09:53:58 AM UTC, comment #5:
HI Steffen,
Martin (Adele) will try to do it.
The bug is assigned to him.
|
Thu 05 Mar 2009 06:54:13 PM UTC, comment #4:
Yes, SLX is Windows only, therefore it is the Windows version of CERTI we are using. Let me know the outcome of the developer meeting...
|
Thu 05 Mar 2009 03:45:20 PM UTC, comment #3:
Hi Steffen,
Thank you for registering it will be easier
for you (and us) to track follow-up.
We have devel' meeting tomorrow, I'll ask
if someone may try to reproduce your problem
and hopefully fix it.
If not I may ask you to try to produce a C++ test case.
Could you tell us if your problem occurs with CERTI
on Windows or Unix/Linux?
It looks like SLX is windows only,
if it is this one:
http://www.wolverinesoftware.com/SLXFAQs.htm?
|
Thu 05 Mar 2009 01:12:25 PM UTC, comment #2:
Eric,
we cannot easily provide a C++ testcase for that, as we are using a discrete event simulation tool (SLX) which is connected to CERTI through a wrapper.
If it would help to speed up fixing the problem, I could ask a member of my group to create a testcase in C++, but that would take time, too.
Steffen
P.S. Sorry for posting anonymously before, have registered now...
|
Fri 06 Feb 2009 09:38:23 PM UTC, comment #1:
ACK,
Will try to look into that soon.
Do you have a ready to use C++ testcase for that bug?
Sidenote:
You should open a Savannah account (which is free)
and login before submitting a bug report.
This way you'll get automatic e-mail follow-up.
|
Thu 05 Feb 2009 01:55:29 PM UTC, original submission:
Problem Description:
When issuing a nextEventRequest call with a time stamp which is smaller than the last grantTime received via timeAdvanceGrant plus the current lookahead, the exception "InvalidFederationTime" is thrown. This is not a correct behaviour.
Example:
Assume Lookahead 0.5;
Issue nextEventRequest to 100.000;
Receive timeAdvanceGrant for 100.000;
Issue nextEventRequest to 100.2;
-> Throws exception "InvalidFederationTime".
|