Logging Quantum

[GoogleCodeExporter]

Upon startup, quantum is zero. But in the log, all activities until the 
simulation is started are also recorded as zero. 

There should either be (no preference):

-- a setup quantum S0,S1,Sn until the simulation is executed -- then we have 
Q0,Q1,Qn or,
-- the setup is also counted as Quantum

Or, some other solution but having log entries with the "same timestamp" is not 
right.

Original issue reported on code.google.com by dimitoglou@gmail.com on 22 Nov 2010 at 1:52

[GoogleCodeExporter]

There are two items that are being brought to light in this issue.  The how the 
 initialization and startup of the simulation relates to time and multiple 
actions happening in the same time Quantum.

First addressing setup and initialization.

Below is a sample setup and start of a simulation.

Q 0 : INFO: Simulation Speed Set: 5
Q 0 : INFO: New AODV Simulation Created
Q 0 : INFO: Node Added: A
Q 0 : INFO: Node Added: B
Q 0 : INFO: Node Added: C
Q 0 : INFO: Node B moved to X:573 Y:215
Q 0 : INFO: Node C moved to X:638 Y:230
Q 0 : INFO: Simulation Started

All setup messages are recorded with a Quantum of 0 as is the start of the 
simulation.  The first time any node can act is in Quantum 1.  I admit that 
this could be confusing for the end user.  If the community thinks that it 
would be less confusing for the user for the Simulation Started log entry to be 
the first entry in Q1 instead of the last entry in Q0, so be it.

Second, the question about multiple entries with the same time stamp. 

This does happen by design and it is my personal opinion that the design 
attempts to mimic the physical world.  In DARS a time quantum is intentionally 
not given a set unit of time as it relates to the physical world, instead it is 
viewed as a given slice of time in which the network as a whole has a chance to 
react.  

DARS is, for the purposes of this conversation a serial process.  Each node in 
the network is given a chance to act in a given time quantum.  That means that 
there is the potential, and a high likelihood, that two or more nodes will all 
take an action resulting in a log entry.  These entries appear and are 
processed in serial but in the physical world would be happening in parallel.  
To that end, multiple log entires are recorded with the same time Quantum.

It may be possible to add a wall clock time to the start of each log entry to 
lessen the confusion of the end user if that would please the community.

Side note.

As I was writing I would like to point out that although each node is processed 
serially no node can consume the output of another node as input in the same 
time quantum that it was sent.  This prevents a user from manipulating the 
simulator to get a node through the network in fewer time cycles based on the 
order of operations in the simulator. 

Original comment by kre...@gmail.com on 23 Nov 2010 at 12:42

• Changed state: Waiting

[GoogleCodeExporter]

This is a very thoughtful reply, it is appreciated. Very good analysis. 

Let me share some of my thoughts. 

First of all, I think we need to have the setup tasks included in the log. This 
is needed for the replay functionality. So setup activities have to be included 
and they should also be meaningfully timestamped to indicate their order. I 
will leave it up to you how to deal with it. 

Second, for the Q0 point, call me a purist, but logging is a very big deal 
(particularly in distributed systems which is the area I am coming from) but 
for different reasons: dealing with distributed logging, clock synchronization 
etc. 

Those concerns aside (they are not applicable here anyway) lets take as an 
example the following log segment: 

Q 0 : INFO: Node Added: B
Q 0 : INFO: Node B moved to X:573 Y:215
Q 0 : INFO: Node C moved to X:638 Y:230
Q 0 : INFO: Node B moved to X:222 Y:777

Reading this event log, the above states that node B was created, moved, and 
moved again while in between node C was being moved. Besides the reading order 
of the file, there is no timestamp (or what we call event-based) order. 
Timestamps are a critical component of any log. Albeit, for our case the setup 
activities are not that important but this mechanism also does not really 
represent the real world. The above events did not all happen at Q0. So either 
the timestamp is misleading or the events happened at the same exact instance 
(or time step) which of course is not true.

I don't think it is necessary to think of the simulation strictly based on node 
activity. I suggest thinking about it in terms of events, a discrete event 
simulation, which in turn means that the simulation execution is described by 
the timed order of events. And you will probably cringe when you read this but 
we record events with strict timed order because we want to capture now each 
event changes the *state* of the simulation (ATM, vending machine and elevator 
memories anyone???)  :)

I agree that in a simulation with multiple nodes we may have a node sending a 
message while another node is sending a broadcast request (I don't think it is 
possible in this simulation given that the nodes are not individual threads 
---- if I recall correctly a conversation we had at some point), but we strive 
to have things that happen be identifiable as distinct events not from what 
they do (node sending a message vs. another node sending a broadcast) but when 
they do it and this is captured using timestamps with high granularity.  This 
is why (don't know if it was to this team or another) I had mentioned before 
having the 00:43:59.996 format. Even if you start this "clock" during the 
topology setup, there is no question about the ordering of events. 

So, what do we do now? I see three possible solutions but I am open to others:

(a) Use quanta as they are currently used --- but start them upon setup. 
(b) Use a different class of quanta (S) for setup activities and different 
during for simulation execution (Q). 
(c) Use a "00:43:59.996" type timestamp which begins the moment the user 
selects a protocol and is ticking until the cows come home. (Is this what you 
meant by wall clock time?)

Any other ideas? 

PS: Option (a) may be the "lowest picking fruit" but is it is also the most 
coarse solution. Since you mention the community, the term "time step" is much 
more widely understood and used than quantum. 
Option (b) is also not that elegant and may not be obvious as to what the 
different classes mean. This may require explanation with a tooltip etc. Sounds 
like a pain to me!
Nobody will ask a question for using (c), it is what most are accustomed when 
it comes to event logging. But I don't know how easy it is to implement at this 
stage...

I am open to your ideas....

Original comment by dimitoglou@gmail.com on 23 Nov 2010 at 6:34

[GoogleCodeExporter]

Every log gets timestamped now. Closing ticket.

Original comment by memjjay@gmail.com on 1 Dec 2010 at 2:23

• Changed state: Fixed