Re: [certi-dev] TAG and transient message

[Eric Noulard]

2015-06-25 21:58 GMT+02:00 David Come <address@hidden>:

Hello,

I indeed used the NULL_MESSAGE_PRIM because I have been told by the original writter that it was needed otherwise the simulation was too slow.
I never asked question about it (maybe I should have).

NULL_PRIME_MESSAGE_PROTOCOL
is an enhancement to CMB (Chandy/Misra/Bryant) NULL Message protocol to avoid time-creep when lookahead is 0 or very small.

It was design mainly for NER/NERA time advance mechanism when 0-lookahead is necessary.

see discussion there:
http://lists.nongnu.org/archive/html/certi-devel/2012-08/msg00000.html
https://savannah.nongnu.org/bugs/index.php?37204
http://lists.nongnu.org/archive/html/certi-devel/2010-10/msg00018.html
http://lists.nongnu.org/archive/html/certi-devel/2010-07/msg00011.html

If your lookahead in non zero. Then NULL PRIME is not necessary.

However time advance may be very slow if lookahead is small

All this is explained in §4 of the SIW paper;
http://download.savannah.gnu.org/releases/certi/papers/11S-SIW-045.pdf

 

I have just tested without it and it is working just fine with the intended behavior.

Then may be there is a bug in the NULL PRIME protocol or may be only in its implementation.

But keep reading, somethings bother me on the application side.

 

I'm using the lastest version of certi (6e7be21f6d6a7997a263be784a61a9603118f4d9), same with Jcerti (d2f82ad25ebbbe301f7414f78fe93d71af1dbeb8).

Here are the full logs I have for another run which exhibits the same behavior when running a CERTI compiled with NULL_MESSAGE_PRIM.
I got the output file logtty with export RTIG=ACDEGIMPRSTWXZ, not sure if it is the right way, couldn't find anything about it in the doc.

There is not so much doc about that beside the code itself.

The letter was meant to "categorize" the message (D = debug, C = Communication, etc... sse more in PrettyDebug.hh)

whereas the name of the env var was about a "portion of service/code" in CERTI, like "RTIG, RTIA, etc..."

In the end the vast majority of logs uses the "D" letter and a specifically named env var.

You may seek for PrettyDebug object instance in the code in order to find all of them.

The ones we are interested in are:

RTIG_NULLMSG set it to D
RTIG_MSG set if to D
(optionnally RTIG set it to D)
RTIA_TM set it to D
RTIA_NULLMSG set it to D

(optionnally RTIA set it to D)

Now concerning the content of A and B, the logs looks OK:

Try to
grep -n -e "NEXT_EVENT" -e "TIME_ADVAN" -e "UPDATE" -e "REFLECT" A

then
grep -n -e "NEXT_EVENT" -e "TIME_ADVAN" -e "UPDATE" -e "REFLECT" B

you'll see that

your application A does:
--> NER(0),
<-- TAG(0) which his weird (not usefull) but OK.

--> UAV(1)

--> NER(100)

<-- RAV(2)

<--TAG(2) which is perfect because you received RAV(2) so the best answer to NER(100) is TAG(2)

-->UAV(3)

-->NER(100)

<--TAG(100)

there is nothing wrong with all that (concerning time advance logic at least)

your application B does:
--> NER(0),
<-- TAG(0) same as for A
--> NER(100)

<-- RAV(1) (coming from A)

<-- TAG(1)

--> UAV(2)

--> UAV(2) two messages with differents attribute set

--> NER(100)

<-- TAG(100)

again there is nothing wrong about the sequence beside the fact that B send two UAV and only one RAV

have been received on the A side.

The logtty does not contain help full information could you redo it with

RTIG_NULLMSG set it to D
RTIG_MSG set if to D
(optionnally RTIG set it to D)
RTIA_TM set it to D
RTIA_NULLMSG set it to D

(optionnally RTIA set it to D)

Moreover, what is wrong in this sequence?

In order to avoid java thread mix in the log may be you can configure log4j to timestamp your log entry.

 

Thanks,
David.

Le 25/06/2015 02:46, Jean-Loup Bussenot a écrit :

Hi David !

Could you give us the commit number of your certi version ?
Do you compile using the NULL_MESSAGE_PRIM ?

According to Eric, you couldn't send a NER(0) after a NER(100)  without receiving a TAG(0)

INFO: Sending message (NEXT_EVENT_REQUEST, NO_EXCEPTION, federation time: 100.0)
INFO: Received message (NEXT_EVENT_REQUEST, NO_EXCEPTION, federation time: null)

INFO: Sending message (NEXT_EVENT_REQUEST, NO_EXCEPTION, federation time: 0.0)
INFO: Received message (NEXT_EVENT_REQUEST, NO_EXCEPTION, federation time: null)

Can you send us the RTIG log with the NULL_MESSAGE print ,

Jean-Loup

--
CERTI-Devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/certi-devel

--

Eric