[Ns-developers] Different Clocks

Gustavo Carneiro gjcarneiro at gmail.com
Wed Mar 21 04:44:54 PDT 2012


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

>
> 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.
>

Ah, ok, then you are definitely talking about clock drift, and not clock
offset.  Clock drift means that the offset between two clocks varies over
time.

In this case you have to tweak the value of Simulator::Schedule.  Doing
this transparently for a whole node I guess is not possible unless you
modify the ns-3 scheduler itself.  Note also that you can create a new
SimulatorImpl subclass to do this, and enable it as default, (for instance
with a --SimulatorImplementationType=ns3::MySimulatorImpl command-line
option).  There is a 'context' uint32_t parameter that can be used to
identify the node; you can use this to apply a per-node drift value.


>
> 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
>
>



-- 
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