Re: [ns] time resolution in Gbps bandwidth

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

Hi, Haobo,

I just noted that you're using namtrace, not trace.  I have
checked the trace's format() in trace.cc, just found that trace's
precision is only 6 digits!  Why?  That means when I use
1000Mbps as bandwidth as well as the packet rate, the transmission
time is only in order of 1e-9, and all transmission time will
be igored in trace files?

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