To sum up, the idea was to set a per-node clock in order to improve
simulations. Time accuracy plays a role in many networking protocols
(optical, RTTM in TCP, TCP veigas etc...) so it's an interesting
parameter to simulate.
My concerns are about the credibility/performance tradeoff of such a
mechanism (I guess that's an inherent question to simulators xD).
Here are a few hints about how clocks may differ:
-take some time before converging (like GPS)
-different resolutions, ie some lock may have a 400ms resolution for instance
Ideally I would like to be able compare a real NTP application with
let's say a modified version of NTP in ns3. I wonder if we could run
real NTP clients as DCE applications in ns3 ?
As for the implementation details I geuss having events to update
clocks would be too coslty, the scheduler could update clocks
according to the minimum resolution, or the current time be computed
from the scheduler time I don't know.
> From: Matt <[hidden email]>
> Subject: [Ns-developers] Addition of per-node clocks in ns3
> To: ns-dev-list list <[hidden email]>
> <[hidden email]>
> Content-Type: text/plain; charset=UTF-8
> As for the implementation details I geuss having events to update
> clocks would be too coslty, the scheduler could update clocks
> according to the minimum resolution, or the current time be computed
> from the scheduler time I don't know.
I gave this a little thought a while ago, also prompted by a question on the users list, and came up with these ideas:
1. Aggregate a default "Clock" to each node. The default clock returns the exact virtual time, just as Now() does.
2. Modify models to consult the node clock, instead of Now(), when they need the time. This is the hard part: identifying when a model needs the Clock, and when it should be allowed to look at Now().
3. Implement your favorite bad clock (drift, skew, etc.), which can then be aggregated in place of the default. Bad clocks should compute their value, based on configuration and Now(), when asked (rather having events just to update the Clock, when no one cares).
4. Implement some clock disciplines to keep things from getting too whacky. This is the poor man's NTP.
The conceptual change for models is that Now() is really like Monte Carlo truth: you are *not* allowed to consult the truth in your analysis, only in *evaluations* of your analysis.
Note that Schedule() already takes the delay to the event, so if a process on node A, which has a Clock of A1:10 at virtual time 1:00, wants something to happen on node B at A1:15, it schedules for delay 0:05, which naturally ends up at virtual time 1:05 at B (with whatever B's notion of Clock happens to be).
All protocol models (which are normally implemented in software) should probably only know Clock; physical models, such as Channels, may need to know Now(), especially to translate between the different Clocks at each end point. However, with clock skew you might also want to allow variations in signaling rate on a channel, since these are ultimately driven by local oscillators (clocks). I haven't thought about how to separate these concerns to keep the work manageable...
Dr. Peter D. Barnes, Jr. Physics Division
Lawrence Livermore National Laboratory Physical and Life Sciences
7000 East Avenue, L-50 email: [hidden email] P. O. Box 808 Voice: (925) 422-3384
Livermore, California 94550 Fax: (925) 423-3371