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

 
 

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

Submitter:  Eric NOULARD <erk>
Submitted:  Sun 04 Oct 2009 03:54:10 PM UTC
   
 
Category:  CERTI Severity:  * 4 - Important
Item Group:  HLA compliance error Status:  In Progress
Privacy:  Public Assigned to:  erk
Open/Closed:  Open Release:  * GIT-master
Reproducibility:  None Fixed Release:  * Unknown
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 22 Aug 2018 12:41:16 PM UTC, comment #7: 

Taking over

JbCh <jb_ch>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator

 

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

Attach Files:
   
   
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
  • -email is unavailable- added by jb_ch (Posted a comment)
  • -email is unavailable- added by frohlich (Posted a comment)
  • -email is unavailable- added by erk (Comments wanted)
  • -email is unavailable- added by erk (Comments wanted)
  • -email is unavailable- added by erk (As pirmary reporter on the ML)
  • -email is unavailable- added by erk (Submitted the item)
  •  

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-22 jb_ch ReleaseCVS GIT-master
    2009-10-21 erk Attached File- Added late-arriving-erk2.patch, #18911
    2009-10-16 erk Severity3 - Normal 4 - Important
        Fixed ReleaseNextRelease Unknown
    2009-10-12 erk StatusNone In Progress
        Assigned toNone erk
        Fixed ReleaseUnknown NextRelease
    2009-10-09 erk Dependencies- patch #6937 is dependent
    2009-10-04 erk Carbon-Copy- Added siron
        Carbon-Copy- Added adele
    2009-10-04 erk Attached File- Added late-arriving.diff, #18813
    2009-10-04 erk Carbon-Copy- Added frohlich

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code