[rrd-users] Date/time-related problem on Windows

Jurjen Oskam jurjen at stupendous.org
Wed Jan 21 15:49:00 CET 2009


Hi everybody,

I've successfully compiled both 1.3.5 and 1.3.6 on Windows, using the
excellent Windows build instructions. Overall, rrdtool works great, but I
ran into a rather strange problem yesterday.

I have found that rrdgraph won't create any graph with a time interval "i"
(in hours) such that 800 < i < 4800. Even an interval of 800 hours and 1
second will not work, nor will an interval of 4800 hours minus 1 second.
It doesn't seem to matter when the interval starts. rrdtool will just exit,
without any error message or anything.

I have also found that this behaviour depends on the size of the graph.
For example:

  # interval of 4800 hours minus one second
  rrdtool graph -w 800 -h 200 -s 1213398001 -e 1230678000 [...]

will fail, while

  # the exact same command, the only difference being the width of the graph
  rrdtool graph -w 400 -h 200 -s 1213398001 -e 1230678000 [...]

will work just fine.

When using the "-j" option without changing anything else (to just create
the graph without any legend or labels on any axis), any interval seems
to work just fine, including intervals that fail without the "-j" option.


Additionally, the result of "rrdtool dump" seems to produce strange
results. Since this might be related to the problem described above, I'll
include it here. In the resulting .xml-file, timestamps are accompanied by
a comment that contains the human-readable form of the timestamp, for
example:

<lastupdate> 1232535607 </lastupdate> <!-- 2009-01-21 12:00:07 W. Europe Standard Time -->

The strange thing is that in the <database> sections of the <rra> section,
every timestamp *except the last one of each <database> section* contains has
a comment with the wrong time (the NaN's are expected, the .rrd isn't
entirely filled up yet):

<!-- 2144-02-27 18:43:16 W. Europe Standard Time / 1200914100 --> <row><v> NaN </v><v> NaN </v></row>
<!-- 2144-02-27 18:58:16 W. Europe Standard Time / 1200915000 --> <row><v> NaN </v><v> NaN </v></row>
<!-- 2144-02-27 19:13:16 W. Europe Standard Time / 1200915900 --> <row><v> NaN </v><v> NaN </v></row>
<!-- 2144-02-27 19:28:16 W. Europe Standard Time / 1200916800 --> <row><v> NaN </v><v> NaN </v></row>
<!-- 2144-02-27 19:43:16 W. Europe Standard Time / 1200917700 --> <row><v> NaN </v><v> NaN </v></row>
	[.... cut here ....]
<!-- 2145-02-27 17:28:16 W. Europe Standard Time / 1232532000 --> <row><v> 3.9914962963e+000 </v><v> 2.4517414815e+001 </v></row>
<!-- 2145-02-27 17:43:16 W. Europe Standard Time / 1232532900 --> <row><v> 1.8820370370e+000 </v><v> 8.6726296296e+000 </v></row>
<!-- 2145-02-27 17:58:16 W. Europe Standard Time / 1232533800 --> <row><v> 2.5388296296e+000 </v><v> 1.5819096296e+001 </v></row>
<!-- 2145-02-27 18:13:16 W. Europe Standard Time / 1232534700 --> <row><v> 1.7552888889e+000 </v><v> 8.0303777778e+000 </v></row>
<!-- 2009-01-21 12:00:00 W. Europe Standard Time / 1232535600 --> <row><v> 5.3664058454e+000 </v><v> 3.6128494101e+001 </v></row>

As you can see, the Unix timestamp is OK, while the human-readable form is
incorrect for all timestamps *except the last one*.



There seems to be a date/time-related problem here. Unfortunately, I'm not
enough of a C-programmer to try and solve this myself. If somebody could
help, it would be much appreciated!



I've put the binary .rrd-file and the resulting .xml file on a Web-page,
in case someone would like to see them:

http://bulk.stupendous.org/FA-7A-0.rrd
http://bulk.stupendous.org/FA-7A-0.xml

The result of rrdtool info is included below:

filename = "FA-7A-0.rrd"
rrd_version = "0003"
step = 900
last_update = 1232535607
ds[iops].type = "DERIVE"
ds[iops].minimal_heartbeat = 2500
ds[iops].min = 0.0000000000e+000
ds[iops].max = NaN
ds[iops].last_ds = "436449"
ds[iops].value = 3.7734739179e+001
ds[iops].unknown_sec = 0
ds[tpkbsec].type = "DERIVE"
ds[tpkbsec].minimal_heartbeat = 2500
ds[tpkbsec].min = 0.0000000000e+000
ds[tpkbsec].max = NaN
ds[tpkbsec].last_ds = "3241511"
ds[tpkbsec].value = 2.5422197558e+002
ds[tpkbsec].unknown_sec = 0
rra[0].cf = "AVERAGE"
rra[0].rows = 35136
rra[0].cur_row = 23810
rra[0].pdp_per_row = 1
rra[0].xff = 5.0000000000e-001
rra[0].cdp_prep[0].value = NaN
rra[0].cdp_prep[0].unknown_datapoints = 0
rra[0].cdp_prep[1].value = NaN
rra[0].cdp_prep[1].unknown_datapoints = 0
rra[1].cf = "AVERAGE"
rra[1].rows = 17568
rra[1].cur_row = 2508
rra[1].pdp_per_row = 4
rra[1].xff = 5.0000000000e-001
rra[1].cdp_prep[0].value = 0.0000000000e+000
rra[1].cdp_prep[0].unknown_datapoints = 0
rra[1].cdp_prep[1].value = 0.0000000000e+000
rra[1].cdp_prep[1].unknown_datapoints = 0

Regards,
-- 
Jurjen Oskam

Savage's Law of Expediency:
        You want it bad, you'll get it bad.



More information about the rrd-users mailing list