[rrd-users] Re: Consolidation over Weeks

[Alex van den Bogaerdt]

> I'm trying to consolidate data for a week period, and I would
> like my week period to start on monday.
> But RRDTool seems to consolidate data on weeks that 
> start on thursday (and not monday). I guess that this is because of
> some algorithm based on 1970-01-01 (which was a thursday).
> 
> Can anyone confirm or not confirm this ?

Almost entirely true.  More specific:

The unix-epoch is januari 1st, 1970, 00:00 UTC.  For me, in Holland, this
means that it's januari 1st, 1970, 01:00 local time.  I guess you're from
France so it is the same for you.

The number of seconds since the epoch is zero for the epoch itself,
this is the number 0.  All boundaries, no matter what size the interval
is, will be calculated from that number 0.

Time to start perl:

[alex at home ~]$ perl -e 'use POSIX; print ctime(0)'
Thu Jan  1 01:00:00 1970

Yup, it's a thursday.  If your interval is a week, all boundaries will
be on thursday, 01:00 local time.

> Is there a workaround to my problem ?

The problem has been discussed in the past, I think it was on the
developers list but I'm not sure.  That discussion was about the time
offset, but the problem is the same.  Look it up if you like.

The outcome was (IIRC) that you shouldn't use these large intervals if
you don't like the current behaviour.  If you can live with the fact that
the boundaries are at 01:00 local time, use an interval of 86400 seconds
(which is a day).  If you can't live with that, use an interval of 3600
as this gives you the desired boundary on monday, 00:00 local time.
You will also have other boundaries that you would prefer not to have,
it will cost you disk space and processing time.

There's an additional problem with intervals of a week: does the week
start on sunday or monday?  This has always been a point of discussion.
You say it should start on monday.  Others say it is sunday.  RRDtool
would have to support both.


A modification of RRDtool would be very hard, if not near impossible.
It is doable in theory but IMHO this is hardly worth the effort and the
problems that will most certainly be introduced (slower code, bugs) do
not outweigh the benefits.  Also, daylight saving time will prove to be
a hard nut to crack.

The current code compares the time with (time%interval)==0.  This zero
has to be changed into another number (4*86400 - 3600 in your case).
This has to be done for every statement where the comparison is made,
if one is missed, a bug is introduced.  This will lead to a long and
difficult traject of releases, problem reports, bug fixes, releases...

HTH,
-- 
   __________________________________________________________________
 / 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