[rrd-users] Re: How to save and graph NON-averages

Alex van den Bogaerdt alex at slot.hollandcasino.nl
Mon Sep 25 22:46:30 MEST 2000


Sam Howard wrote:
> 
> When I dump the database, with a steptime=86400 (1 day), I notice that it
> chooses 20:00 (8:pm) as the time, even though I am running the create script
> at 16:00 (4:pm).  As seen by:

It really chooses 00:00 UTC...  It represents it as 20:00 EDT.

> But, here's where it get's weird (and maybe why my values are getting
> "helped")...after a few days, in the database, the time *changes*:
> 
> <!-- 1997-10-25 20:00:00 EDT --> <row><v> NaN </v><v> NaN </v></row>
> <!-- 1997-10-26 19:00:00 EST --> <row><v> NaN </v><v> NaN </v></row>

Again:
20:00 EDT --->  00:00 UTC
19:00 EST --->  00:00 UTC
(I'm now guessing that EDT is EST with daylight saving applied).

> It goes back and forth every so many months!!

Let me guess: april and october, and every time on a sunday.

> I notice that if I reduce the steptime, to anything other than 3600 or 7200,
> that I get time fluctuations...

You should get problems with 7200.  Everything under 3600, provided that
3600 modulo time step is zero, is okay.

> I hate to waste so many records (24 per day) just to work around this...

Just don't look at it as wasting space.  If you have a good reason to
do so, do so.

However, for this particular purpose you can say *you* are wasting space
if *you* choose to use 3600 seconds time steps.  I guess you're only
interested in the yearly archive and therefore want only update once
every day.  Do this at 00:00 UTC and there's no problem.

For any moment in time, you can find the RRDtool boundary by doing an
integer division of the current time, then multiplying the outcome with
the same number.

   [alex at home ~]$ date;date +%s
   Mon Sep 25 22:36:04 MET DST 2000
   969914165
   
   [alex at home ~]$ bc
   bc 1.03 (Nov 2, 1994)
   Copyright (C) 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
   This is free software with ABSOLUTELY NO WARRANTY.
   For details type `warranty'.
   969914165/86400
   11225
   .*86400
   969840000
   
   [alex at home ~]$ perl -e 'use POSIX;print ctime(969840000);'
   Mon Sep 25 02:00:00 2000

This is correct.  Our time is one hour ahead of UTC.  Daylight savings
account for the other hour.

You can update the RRDtool database you currently have if you make sure
that you (a) update on or after 00:00 UTC and (b) perform some math on
the current time.

Warning:  I'm just starting to learn perl.  Others can probably write a
better program to do this but until they share it, here's mine:

perl -e '$x=time();print $x-($x%86400)."\n";'

regards,
-- 
   __________________________________________________________________
 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
+----------------------------------------------------------------------+
| Technical questions sent directly to me will be nuked. Use the list. | 
+----------------------------------------------------------------------+
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |
+----------------------------------------------------------------------+

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi



More information about the rrd-users mailing list