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

[BAARDA, Don]

G'day again.

> -----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
> can
> > use any scaled "time" type as long as you are consistent. For example,
> in
> > your case you could use a count of the number of days since your
> preferred
> > start date, and increment the "time" by one each day. This would allow
> you
> > to enter a single sample per day with no "normalising" and accumulate on
> day
> > 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) %
step).

	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
> the
> > case, but if true, you would probably have to add some starting offset
> to
> > 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
was unusual.

> 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
sample/day.

	ABO

--
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