Time precision

[Massimo Pegorer - Stage <pegorer@tvdsp2.vim.tlt.alcatel.it>]

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