[rrd-users] MAX not behaving as I would expect

[Rob Conway]

Karl,

I set my server to UTC and now the max is aligned to midnight as expected.
Thus the data must be stored in UTC and the client provides the time zone
adjustment, as all my past data is now aligned to midnight which is great.

As this is a home server I do not mind changing the time manually a couple
of times a year for DST.

Now I suppose I gotta get a new RRD and reset my step back to 300 so as to
get MAX to 24hrs and not 48 hrs.

thanks



-----Original Message-----
From: Karl Fischer [mailto:rrd-users at ficos.de] 
Sent: Friday, February 06, 2009 1:29 AM
To: Rob Conway
Cc: rrd-users
Subject: Re: [rrd-users] MAX not behaving as I would expect

Rob Conway wrote:
> Thanks karl,
> 
> I forgot I changed the step to 600 from the default of 300.
> 
> I did think that maybe the rrdtool create "start time" may in fact set the
> start for the 24hr max computation ?

No, this only sets the timestamp for the first available bucket in the RRA.
That means you cannot enter any data into a rrd with a timestamp earlier
than start time ...
So if you create a rrd NOW, not (only) for future use but for the import
of historic data, you need to set the start time to some point in the past.
Otherwise rrdtool will refuse the updates.


> As I run a dedicated unbuntu web server I suppose I could change the time
> zone to UTC and just manually set the date/time.  Can someone confirm this
> will fix the MAX daily offset problem. ?  How do other people handle this
?

Well, you can certainly set your server's time to UTC, but then the days
displayed on the server will still not match your (australian) days ...
And if you fake the server time by setting it to UTC timezone and still
set the time manually to match your local time, you would have to reset
that twice a year to match local summer/winter time (that causing other
problems) ...
And you would have no chance to keep the clock accurate with ntp ...

I'd rather set the rra to 1 hour and do the math in rpn ...

- Karl


> -----Original Message-----
> From: Karl Fischer [mailto:rrd-users at ficos.de] 
> Sent: Thursday, February 05, 2009 8:43 PM
> To: Rob Conway
> Subject: Re: [rrd-users] MAX not behaving as I would expect
> 
> Rob Conway wrote:
> 
>> I measure the power used and trend kwh.  At midnight, my read script
>> resets and just feeds into rrrd an ever increasing number (accumulated
>> kwh) throughout the day so as to produce a saw tooth pattern.  Works
>> great, however when I trend the MAX, I 'assumed' I would see the maximum
>> value for the 24 hr period.
>>
>> I think this was the script I used to create the rrd
>>
>> rrdtool create /var/rrd/kw.rrd --start 1167177600 --step 600
>> DS:P1:GAUGE:1300:0:100 RRA:AVERAGE:0.5:1:1440 RRA:AVERAGE:0.5:4:2160
>> RRA:AVERAGE:0.5:12:8760 RRA:MIN:0.5:288:1825 RRA:MAX:0.5:288:1825
>>
>> The trend can be viewed at www.rjconway.homeip.net
>> <http://www.rjconway.homeip.net/>  select [Power] radio button for kwh
>> and redraw, you will see the saw tooth, now select [max] .  It seems to
>> be giving one max value per two days value changing at midday not
>> midnight.
> 
> Rob,
> 
> if you created the rrd that way, you *asked* to have only one MAX (and
MIN)
> value per 288 * 600 s (=172800s =48h =2 days)
> 
> Regarding the change not beeing at midnight (as expected) I've seen the
> same behavior in many cases and I assume this is because rrdtool works
> with whole-numbered divisors on the unix timestamp which is UTC based.
> You are halfway round the globe, so roughly 10-12h off UTC/GMT ...
> A 24h period in rrdtool always seems to be GMT 0:00 to next day GMT 0:00
> 
> rrdtool-specialists: please correct me if I'm wrong.
> 
> BTW: I also thought about 'correcting' this for my timezone, but even if
> I would, it fails at the transition summer<>winter time, since in spring
> there's a 23h day and in autumn it's 25h ...
> 
> So if you want the numbers from midnight to midnight your time, you'll
have
> to define your RRA on an hourly basis and do some smart rpn-calculations
> when graphing ...
> 
> - Karl

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.0.233 / Virus Database: 270.10.18/1935 - Release Date: 02/04/09
16:35:00