bugCERTI - Bugs: bug #27595, Late arriving federate (re)starts...

 
 

bug #27595: Late arriving federate (re)starts federation from timestamp 0

Submitted by:  Eric NOULARD <erk>
Submitted on:  Sun 04 Oct 2009 03:54:10 PM UTC  
 
Category: CERTISeverity: 4 - Important
Item Group: HLA compliance errorStatus: In Progress
Privacy: PublicAssigned to: Eric NOULARD <erk>
Open/Closed: OpenRelease: CVS
Reproducibility: NoneFixed Release: Unknown

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 17 Nov 2009 07:34:51 AM UTC, comment #6:

Hi,

Well, I just wanted to tell that it works for my testcase. If it is an improvement, I could well imagine to have that better working in more cases than in fewer.

But sure, once you do it right - it just works ... :)

So, if you don't have time to do somethign better it will be better for my use case to have at least that working.

Greetings

Mathias

Mathias Fröhlich <frohlich>
Sun 15 Nov 2009 06:11:02 PM UTC, comment #5:

Not really,

I may apply it but it is not finished.
May work in your case but not in the general case...
I may apply it and leave the bug open for a second round
hopefully definitive fix.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Sun 15 Nov 2009 01:39:29 PM UTC, comment #4:

Eric,

Your current patch works for me as expected.

So I guess that should be applied?

Greetings

Mathias

Mathias Fröhlich <frohlich>
Wed 21 Oct 2009 07:11:46 AM UTC, comment #3:

I'll release CERTI 3.3.3 before fixing that time.
It takes me too much time for delaying the release.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 16 Oct 2009 07:23:35 PM UTC, comment #2:

Hi all,

Ok this one is not that easy to fix.
The patch from Mathias is not enough and I cannot blame him
because as always full message path
Federate --> RTIA --> RTIG --> RTIA --> Federate
has to be checked.
Moreover SetTimeRegulating is not that easy to handle
because the federate may ask to become regulator
in his future. But as said in the HLA document:

"The RTI shall indicate the logical time assigned to the federate through the Time Regulation Enabled † service. The logical time that is assigned shall be greater than or equal to that requested by the federate"

As discussed with Pierre there is no obvious way to ensure
"a distributely safe value", we may do better than the today's

  1. value but the return value may still "freeze" fast-advancing federate (federate that are issuing fast paced TAR message

while Time Regulation Enabled message has not been delivered.

Moreover the Time Regulation Enabled should be considered
as Time Advance Grant by the federate.

This bug is a serious one and deserve clean fix.
I'm not sure it will be in the next release...

Still working on it though :-)

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Sun 04 Oct 2009 03:59:25 PM UTC, comment #1:

Pierre, Martin, Mathias,

The proper bug report is set up.
Please sue the tracker for follow-up comment on the subject.

Last comment on the patch by Mathias:
I have done a patch to rtig to return at least something that is about at the
current logical time of the federation in the timeRegulationEnabled callback.
But I believe that this change is still wrong since it returns the lbts
instead of the federate time if I understand right.
Anyway, I do not really understand the current implementation to its end, so I
have just attached the change that appears to improve the situation as a
discussion base for a correct solution.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Sun 04 Oct 2009 03:54:10 PM UTC, original submission:

The initial report was done by Mathias on the ML:
http://lists.nongnu.org/archive/html/certi-devel/2009-09/msg00004.html

Copy paste from the message follows:

I try to get up two federates both time constrained and time regulating.
One starts up immediately enables time constrained gets 0 as federate time in
the timeConstrainedEnabled callback, past that it calls
enableTimeRegulation(0, 0.1) gets back a federate time of 0.1 in the
timeRegulationEnabled callback. Then classes are subscribed and objects
registered and the regular timeAdvanceRequest/update loop is entered.

At some later time, a second federate joins the federation and executes the
same code as above with a different federate name and so on.
The second federate also gets 0 and 0.1 in the appropriate callbacks.

But then the first federate stops getting timeAdvanceGrant callbacks until the
second federate's federation time has reached the same numeric value than the
federation time of the first federate. Then the time advances again in both
federates.

I would expect that from within the timeRegulationEnabled call I get the
actual minimum logical time I need to become time regulating instead of
stopping the other federates until the new one catches up.
[...]

Eric NOULARD <erk>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #18911:  late-arriving-erk2.patch added by erk (13KiB - text/x-diff - updated patch (not finished))
file #18813:  late-arriving.diff added by erk (5KiB - text/x-diff - Patch from Mathias)

 

Depends on the following items: None found

Digest:
   patch dependencies.

 

Carbon-Copy List
  • -unavailable- added by frohlich (Posted a comment)
  • -unavailable- added by erk (Comments wanted)
  • -unavailable- added by erk (Comments wanted)
  • -unavailable- added by erk (As pirmary reporter on the ML)
  • -unavailable- added by erk (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 21 Oct 2009 07:11:10 AM UTCerkAttached File-=>Added late-arriving-erk2.patch, #18911
    Fri 16 Oct 2009 07:23:35 PM UTCerkFixed ReleaseNextRelease=>Unknown
      Severity3 - Normal=>4 - Important
    Mon 12 Oct 2009 11:11:34 AM UTCerkFixed ReleaseUnknown=>NextRelease
      StatusNone=>In Progress
      Assigned toNone=>erk
    Sun 04 Oct 2009 03:57:58 PM UTCerkCarbon-Copy-=>Added adele
      Carbon-Copy-=>Added siron
    Sun 04 Oct 2009 03:55:55 PM UTCerkAttached File-=>Added late-arriving.diff, #18813
    Sun 04 Oct 2009 03:54:46 PM UTCerkCarbon-Copy-=>Added frohlich

    Back to the top


    Powered by Savane 3.1-cleanup1