[rrd-users] Re: How to save and graph NON-averages
don.baarda at baesystems.com
Tue Sep 26 02:35:26 MEST 2000
> -----Original Message-----
> From: Alex van den Bogaerdt [SMTP:alex at slot.hollandcasino.nl]
> Sent: Tuesday, September 26, 2000 10:03 AM
> To: don.baarda at baesystems.com
> Cc: rrd-users at list.ee.ethz.ch
> Subject: Re: [rrd-users] Re: How to save and graph NON-averages
> BAARDA, Don wrote:
> > AFAIK, the "time" used in rrd is just an integer (standard Unix time
> > type) that is not used in any special way. This (should) mean that you
> > use any scaled "time" type as long as you are consistent. For example,
> > your case you could use a count of the number of days since your
> > start date, and increment the "time" by one each day. This would allow
> > to enter a single sample per day with no "normalising" and accumulate on
> > boundaries of your choice (by picking your preferred start date).
> It is, indeed, just an integer.
> What happens if you divide an integer by another integer? You get a
> result and a remainder. If you (well, not just you) decide to store
> data in an RRA which has a resolution of 86400 seconds, RRDtool will
> divide every time stamp it receives by 86400. If the remainder is not
> zero, that means that a portion of the value is valid for the previous
> interval and a portion of the value is valid for the current interval.
I've had a quick look at the code and it does indeed use
(current_time % step) to determine all interval boundaries. If you really
want fine alignment of interval boundaries for large step values all these
calculations would need to be changed to ((current_time - start_time) %
As long as step is small relative to your alignment requirements,
this limitation is not a problem. It's only a problem when you want to align
your interval boundaries to a finer resolution than your step setting.
> It was exactly this what the original poster didn't want to happen.
> Therefore, he has to make sure the remainder is zero. That can only be
> the case if the time stamp is an exact multiply of 86400 (or any other
> interval choosen).
Or, he can invent his own integer timescale, where 0 is 00:00
(localtime) of the first Monday of the year 2000, and increments by 1 each
day. He then can make an RRA with a resolution of 1 day and record samples
once every day with a timestame that is an exact multiple of 1 (that hence
always have a remainder of zero after division by the step). He can also
accumulate days into weeks where the week is aligned exactly to Mon 00:00:00
-> Sun 00:00:00 localtime (ignoring daylight savings).
Of course, if he does this, all times are no longer standard unix
times, so all the usual time <-> datestring conversions will be wrong and
will need to be worked around. Probably the hassle of working around this
out-weighs the benefits of a localtime week-aligned timescale, but at least
the rrd core is (I believe) capable of doing this.
> > WARNING: I vaguely recall that someone posted that rrd has problems
> > with dates before some time after 1970. I don't know why this would be
> > case, but if true, you would probably have to add some starting offset
> > your "timescale" when using this technique.
> The time and date used in RRDtool is related closely, no: very closely,
> to the unix epoch. It is January 1st, 1970, 00:00 ---->UTC<----
> Snippet from the man page of time(2):
> time returns the time since 00:00:00 GMT, January 1, 1970,
> measured in seconds.
> (I'm used to say UTC, as GMT means BST for some people when it's summer).
> Tobi decided, probably for good reasons, not to accept negative times.
> I can only guess at this but my guess is that it has to do with overflow
> detection or with problems on certain platforms.
> If negative times are not allowed, the first possible time in an RRD is
> exactly januari 1st, 1970, 00:00 UTC.
I (possibly incorrectly) thought that there was another limitation
that meant times before about 1979 or something wouldn't work. I don't see
why, so probably I dreamed it, but I remember thinking at the time that it
> You can have intervals of 3600 seconds. This makes it possible to have
> interval boundaries at both 19700101 16:00 UTC and 19700102 16:00 UTC.
> However, this also gives you 23 (and not 24!) extra intervals per day.
> It will increase the size of your database (considerably) so if you don't
> need to, don't do it. It is however perfectly legal to do so and for
> people who want to see *their* midnight and not midnight on UTC time, it
> is the only way. If this would be done otherwise, daylight saving will
> <insert four or five letter word here> up the averages.
Once again, I could be wrong, but I thought there was no requirement
to have an RRA in a RRD that has steps=1 if you don't want to. This means
you can have step=3600, a DS with heartbeat>86400, and a single RRA with
steps=24, to give you hourly resolution, daily sampling, and only store 1
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-users-request at list.ee.ethz.ch?subject=help
More information about the rrd-users