Re: [ns] time resolution in Gbps bandwidth

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

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