Re: [ns] time resolution in Gbps bandwidth

[Haobo Yu <haoboy@ISI.EDU>]

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