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

Wed Jan 21 20:34:58 CET 2009

On Wed, Jan 21, 2009 at 04:16:12PM +0100, Tobias Oetiker wrote:

> could you supply a little script doing
> 
> 
> rrdtool create ...
> rrdtool update ...
> rrdtool update  ...
> rrdtool update ...
> rrdtool update ...
> rrdtool graph ...
> 
> so that I can try to recreate this problem ...
> 
> it is important that you use absolute timestamps in your example or
> things will shift ... why testing ...

First, thanks for looking into this!

It's not necessary to update the rrd after creating it, to recreate the
problem. These are the exact commands I used:

rrdtool create example.rrd -s 1213398000  -s 900 DS:iops:DERIVE:1800:0:U RRA:AVERAGE:0.5:1:35136
rrdtool graph -w 800 -h 200 -s 1213398000 -e 1230678000  try.png DEF:iops=example.rrd:iops:AVERAGE LINE:iops#00FF00:iops
rrdtool graph -w 800 -h 200 -s 1213398001 -e 1230678000  try.png DEF:iops=example.rrd:iops:AVERAGE LINE:iops#00FF00:iops
rrdtool graph -w 800 -h 200 -s 1213398000 -e 1230678001  try.png DEF:iops=example.rrd:iops:AVERAGE LINE:iops#00FF00:iops

The graph commands are all exactly the same, with the exception that the
start and end are changed.

The create worked fine. The first graph also worked fine, it produced a
nice graph (of course, without any line since there's no data in the .rrd.)
The second graph failed, and the third worked again.

Adding "-j" to the failing graph command caused it to work:

rrdtool graph -j -w 800 -h 200 -s 1213398001 -e 1230678000  try.png DEF:iops=example.rrd:iops:AVERAGE LINE:iops#00FF00:iops

This produced an 800x200 empty graph (just white).

Would you like me to perform more tests?

> Today Jurjen Oskam wrote:
> 
> > 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,
> >
> 
> -- 
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900
> 
> _______________________________________________
> rrd-users mailing list
> rrd-users at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

-- 
Jurjen Oskam

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