[Ns-developers] Different Clocks

Mike Moreton mjvm_ns at hotmail.com
Wed Mar 21 04:36:07 PDT 2012

I guess you know a lot more about the internals of the scheduler than me - I'd assumed it just added the current delta time to the current time to calculate an expiry time, then used that to insert the event into a list, and took the events off the list in the order they came.  In which case, changing now wouldn't make any difference, unless the scheduler itself used a different value of Now() for each node in which case I don't see how it could work at all.

Real world clock drifts are the sum of a large number of small individual errors.  If you consider a typical crystal with an accuracy of about 50ppm, then a 100ms Wifi beacon period could be out by about 5us.  It's probably not going to cause a problem of itself, but it can cause the beacons to beat over an extended time period.  I'd agree that it's unlikely to make a significant difference over the period of a frame - protocols will be designed with enough margin to handle that sort of thing.

Another issue is that in the simulator if you start two applications at the same time they will stay in lock-step for the entire run, which isn't very realistic.  From the above you can see that after a second of running, it wouldn't be unrealistic to expect the two applications to have slipped by 50us relative to each other.  That's still small, but it is enough to make a difference at the protocol level - it could turn collisions into sequential transmissions.

Date: Wed, 21 Mar 2012 11:02:25 +0000
Subject: Re: [Ns-developers] Different Clocks
From: gjcarneiro at gmail.com
To: mjvm_ns at hotmail.com
CC: ns-developers at isi.edu

On Wed, Mar 21, 2012 at 10:54, Mike Moreton <mjvm_ns at hotmail.com> wrote:

I guess another alternative would be to add a node specific delta for each call to Schedule(), and keep a global time.

The argument to Schedule is a time interval, not an absolute time, so I think you shouldn't mess with Schedule, only with Now, like Lalith said.

You would mess with Schedule if there was a severe time drift, when compared to the time interval values that Schedule handles.  This is very unlikely in the real world.  Only if the Schedule() receives a very large time interval value...

However, I'm not sure what the effect on frame reception would be - you want all nodes to see the frame ending at the same real time.

Sounds like a lot of opportunities to get things wrong!

> From: suresh.lalith at gmail.com

> Date: Wed, 21 Mar 2012 10:30:46 +0100

> Subject: Re: [Ns-developers] Different Clocks

> To: mjvm_ns at hotmail.com

> CC: ns-developers at isi.edu


> On Wed, Mar 21, 2012 at 10:20 AM, Mike Moreton <mjvm_ns at hotmail.com> wrote:

> >

> > One of the problems that real world protocols have to contend with is that different nodes may have slightly different speed clocks - no two crystals are ever exactly the same.  You can get beating effects where everything runs fine for a while, and then at some point suddenly a whole load of things happen at once, and something goes wrong.

> >

> > Is there any way of simulating this with NS?  As fas as I can see NS-3 has one global view of "time".

> >


> I once had a need of simulating an application which runs on many

> nodes that had to have a different 'local time'. I did this by using

> Simulator::Now() - <some delta> as the time within the application. I

> assumed that there was no drift (which isn't a realistic assumption

> either, but sufficed for my small scenario).


> But I don't know any elegant way of doing this through every component

> of the node. You could try modifying the simulator implementation's

> ::Now() method to offset the timestamp by a delta corresponding to

> each node, but expect a significant performance drop. :)



> --

> Lalith Suresh

> www.lalith.in


Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc

"The universe is always one step beyond logic." -- Frank Herbert

More information about the Ns-developers mailing list