Re: [ns] time resolution in Gbps bandwidth

[Bo Wen <bowen@mail.wsu.edu>]

Thanks a lot, Haobo, you are right.  Since timestamp is multiplied
by SAMPLERATE 8000 at the sender, and then is divided by 8000.0
at receiver.  But these two values are not exactly same, so, the error
come from here.

Bo

On Sun, 23 Jul 2000, Haobo Yu wrote:

> if you use your own timestamp then i bet you won't see any difference. For
> instance if you send a timestamp using Agent/Message, then calculate delay
> at receiver you'll get exactly the same value. Timestamp in packet header
> can be used for other purposes so it's risky to use it in your sim.
> 
> On Sun, 23 Jul 2000, Bo  Wen wrote:
> 
> > Date: Sun, 23 Jul 2000 10:51:11 -0700 (PDT)
> > From: Bo  Wen <bowen@mail.wsu.edu>
> > To: Haobo Yu <haoboy@ISI.EDU>
> > Cc: ns-users@ISI.EDU
> > Subject: Re: [ns] time resolution in Gbps bandwidth
> > 
> > Yes, in trace file, the delay obtained exactly matches the value it
> > shouble be.  But when I use my own way to compute the delay of packets,
> > there always have an error.  My way is, at recevier(like Agent/Null), get
> > current time (now()), then substract the time stamp in pakcet header.
> > 
> > I guess the accuracy depends on where you sample time to calculate delay.
> > I once tried to get the current time at TTL checker, but there was also
> > an error.  Trace file is always right, but without using trace, how can I 
> > get accurate delay calculation?
> > 
> > Thanks a lot!
> > 
> > Bo Wen
> > 
> > On Sun, 23 Jul 2000, Haobo Yu wrote:
> > 
> > > I don't know what you used, but if you modify Tcl.cc as I said in a
> > > previous email long time ago, seems to me there should be nothing wrong. 
> > > 
> > > For instance, if you send 210bytes UDP packets on a 1Gbps link with 1ms
> > > delay, this is a piece of nam trace you'll get:
> > > 
> > > + -t 1 -s 0 -d 1 -p cbr -e 210 -c 0 -i 0 -a 0 -x {0.0 1.0 0 ------- null}
> > > - -t 1 -s 0 -d 1 -p cbr -e 210 -c 0 -i 0 -a 0 -x {0.0 1.0 0 ------- null}
> > > h -t 1 -s 0 -d 1 -p cbr -e 210 -c 0 -i 0 -a 0 -x {0.0 1.0 -1 ------- null}
> > > r -t 1.00100168 -s 0 -d 1 -p cbr -e 210 -c 0 -i 0 -a 0 -x {0.0 1.0 0 ------- null}
> > > 
> > > The delay is exactly you'd expect: 1ms + (210*8)/1e9 = 0.00100168s. If
> > > this is not the scenario you referred to, please provide more info.
> > > 
> > > - Haobo
> > > 
> > > On Fri, 21 Jul 2000, Bo  Wen wrote:
> > > 
> > > > Date: Fri, 21 Jul 2000 11:38:32 -0700 (PDT)
> > > > From: Bo  Wen <bowen@mail.wsu.edu>
> > > > To: ns-users@ISI.EDU
> > > > Subject: [ns] time resolution in Gbps bandwidth
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > When I use Gbps as links bandwidth, but I just
> > > > found the total delay of a packet is not exactly equal
> > > > to the sum of propagation delay and transmission delay
> > > > of the packet (I removed the queue delay from links,
> > > > so there is no queuing delay introduced).
> > > > 
> > > > My way to calculate delay is that received time at
> > > > the received substracts the time in time stamp of packet
> > > > header.  With Mbps bandwidth, results look reasonable
> > > > with the acceptable resolution.
> > > > 
> > > > Is that the problem of the resolution of ns scheduler?
> > > > 
> > > > Thanks a lot,
> > > > Bo Wen
> > > > 
> > > > 
> > > > 
> > > 
> > 
> > 
>