[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Time precision




Yuri,

If you change the distribution, make sure that you regenerate the test
outputs, because otherwise it keeps complaining that the differences
between the test result and the test output due to floating-point
formatting are not significant in most tests.

Pablo 


On 22 Jun 1999, Yuri Pryadkin wrote:

> It's been fixed.  Thanks!
> 
>  -Yuri
> 
> Pablo Molinero Fernandez <[email protected]> writes:
> 
> > Hi Massimo,
> > 
> > I agree with you. I think that in the next ns release they should maintain
> > the precission of the traces throughout the simulation. It is a simple
> > matter of changing lines 255 and 276 in ns-2/ns-2/trace.cc from:
> > 
> > sprintf(wrk_, "%c %g %d %d %s %d %s %d %s%s %s%s %d %d",
> > 
> > to:
> > 
> > sprintf(wrk_, "%c %.9g %d %d %s %d %s %d %s%s %s%s %d %d",
> > 
> > or:
> > 
> > sprintf(wrk_, "%c %.9f %d %d %s %d %s %d %s%s %s%s %d %d",
> > 
> > Pablo
> > 
> > On Tue, 15 Jun 1999, Massimo Pegorer - Stage wrote:
> > 
> > > Running some simulations I've noticed that time in ns output files is
> > > always given with the six most significant digits, and this fact gives
> > > me some problems in postprocessing these files because of the rounding;
> > > for example, when the time goes beyond 100 seconds, fractions of msec
> > > are lost:
> > > 
> > > [...]
> > > - 99.9961 0 1 cbr 1000 ------- 0 0.0 1.0 19803 19803
> > > r 99.9962 0 1 cbr 1000 ------- 0 0.0 1.0 19801 19801
> > > r 100.001 0 1 cbr 1000 ------- 0 0.0 1.0 19802 19802
> > > + 100.003 0 1 cbr 1000 ------- 0 0.0 1.0 19804 19804
> > > [...]
> > > 
> > > This has curious consequences for nam, too. For absurde, if you have a
> > > cbr flow with 5ms interval time between packets (interval_=0.005) and it
> > > starts at 1000, packets #0 and #1 will have the same start-time (1000)
> > > and nam will visualize only packet #1 and not #0!
> > > 
> > > + 1000 0 1 cbr 1000 ------- 0 0.0 1.0 0 0
> > > - 1000 0 1 cbr 1000 ------- 0 0.0 1.0 0 0
> > > + 1000 0 1 cbr 1000 ------- 0 0.0 1.0 1 1
> > > - 1000 0 1 cbr 1000 ------- 0 0.0 1.0 1 1
> > > + 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 2 2
> > > - 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 2 2
> > > r 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 0 0
> > > + 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 3 3
> > > - 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 3 3
> > > r 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 1 1
> > > r 1000.02 0 1 cbr 1000 ------- 0 0.0 1.0 2 2
> > > [...]
> > > 
> > > I think this depends on sprintf %g default precisions (in
> > > Trace::format), but in my opinion it would be more useful to have always
> > > time with the same format and with six digits after the decimal-point
> > > (microsec), such as with %f.
> > > I hope not to have annoyed you with tedious questions. Thanks for
> > > suggest.
> > > 
> > > max
> > > 
> > > 
> > > --
> > > Massimo Pegorer, student
> > > Dipartimento di Elettronica e Informatica
> > > Universita' degli Studi di Padova
> > > Padova - ITALIA
> > > 
> > > 
> > 
> > -------------------------------------------------
> > Pablo Molinero Fern�ndez
> > (650) 497-7490 (home)
> > (650) 723-1414 (office)
> > http://www.stanford.edu/~molinero
> > Snail-mail:  Gates Building 3A, Room 342
> >              Stanford, CA 94305-9030	  	
> 

-------------------------------------------------
Pablo Molinero Fern�ndez
(650) 497-7490 (home)
(650) 723-1414 (office)
http://www.stanford.edu/~molinero
Snail-mail:  Gates Building 3A, Room 342
             Stanford, CA 94305-9030