bugCERTI - Bugs: bug #55543, ...

 
 

bug #55543: CERTI_USE_NULL_PRIME_MESSAGE_PROTOCOL causes federation to stall

Submitter:  Clément Michel <cmichel>
Submitted:  Tue 22 Jan 2019 01:37:41 PM UTC
   
 
Category:  CERTI Severity:  * 3 - Normal
Item Group:  Software error Status:  In Progress
Privacy:  Public Assigned to:  cmichel
Open/Closed:  Open Release:  * GIT-master
Reproducibility:  Every Time Fixed Release:  * Unknown
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 01 Mar 2019 08:40:08 AM UTC, comment #2: 

Hello,

I have investigated and I have to implement a different handling of lookahead for NMP protocol. This was causing the stall using your special way to use NER algorithm. I don't have time to do it now but it is on my "to-do" list.

Did you get a chance to retry it with your new NER implementation in your app?

JbCh <jb_ch>
Group administrator
Thu 24 Jan 2019 11:07:03 PM UTC, comment #1: 

Hello,

I checked your code and you are using the NER in a strange way.
You are using the NER to mimic time stepped federate (which should use TAR) by forcing the federate to stay in a while loop until it reaches the "time_step". Then you send the UAV ("updateObject(next_step)").

So I guess at some point the time-stamping protocol is reaching a state similar to the mixture of TAR/NER which (as discussed) can be a corner case. I believe that there is an issue with the handling of timestamp that must be fixed to properly support TAR and NER and avoid corner case.

However, the way you are using NER looks inconsistent to me. Basically you are just loading the RTI with additional NULL MESSAGE (time creep in NER) for the exact same behaviour as the TAR. I don't see the benefit of this execution scheme.

I will have a look on my side on the time-stamping within the algorithm.


JbCh <jb_ch>
Group administrator
Tue 22 Jan 2019 01:37:41 PM UTC, original submission:  

I am currently working on the br_dev_distancematrix branch (with HEAD at c692894e30 as of me writing this bug report) and found a difference in behavior in a federation, depending on if the Null Prime Message Protocol is used or not.

The test program used spawns 5 federates. Fed0 publishes Object0, Fed1 subscribes to Object0 and publish Object1, etc.
Fed0 have a lookahead of 5, Fed1 a lookahead of 4, etc until Fed4 with a lookahead of 1.

When using NER without NPMP, the federation executes and finishes. When using NER with NPMP, the execution does not yield a result as it never finishes.

Steps to reproduce :

  1. Checkout the br_dev_distancematrix branch at revision c692894e30
  2. On file test/DistanceMatrixTesting/FederateUnit.cc, change line 122 from


step();

to

stepNER();

  1. Compile and install CERTI without NPMP
  2. Source the certi_env.sh file, launch the RTIG and run the newly installed


$CERTI_HOME/bin/distanceMatrixTesting

5 federates are launched, and after a few seconds the execution completes.

  1. Compile and install CERTI with NPMP
  2. Source the certi_env.sh file, launch the RTIG and run


$CERTI_HOME/bin/distanceMatrixTesting

5 federates are launched, but the execution never finishes.

Clément Michel <cmichel>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jb_ch (Posted a comment)
  • -email is unavailable- added by cmichel (Submitted the item)
  •  

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-01 jb_ch Assigned tojb_ch cmichel
    2019-01-24 jb_ch CategoryNone CERTI
        StatusNone In Progress
        Assigned toNone jb_ch
        ReleaseUnknown GIT-master

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code