It makes sense!
Thanks!

Have to tested it? Is it ok now? The worst thing that can happen there is to overflow RRDR *r. Have you checked it does not overflow after this patch?

ok. I traced it and I don't think we should merge this.

Let me explain why:

When netdata is reducing metrics, it tries to return always the same boundaries. So, when you say you want 10s averages, it will always return points starting at a unix timestamp % 10 = 0.

Let's see why this is needed. I will show you the error case.

Assume we have 5 points:

At 00:04 you ask for 2 points for 4 seconds in the past. So group = 2. netdata would return:

A second later the chart is to be refreshed, and makes again the same request at 00:05. These are the points that would have been returned:

Wait a moment! The chart was shifted just one point and it changed value! Point 2 was 3.5 and when shifted to point 1 is 2.5 !

If you see this in a chart is a mess. The charts change shape constantly.

For this reason, netdata always aligns the data it returns to the group.

When you request points=1, netdata understands that you need 1 point for the whole database, so group = 3600. Then it tries to find the starting point which would be timestamp % 3600 = 0 Within a database of 3600 seconds, there is one such point for sure. Then it tries to find the average of 3600 points. But, most probably it will not find 3600 of them (for just 1 out of 3600 seconds this query will return something).

So, the proper way to query the database is to also set at least after. If you say:

http://netdata.firehol.org/api/v1/data?chart=system.cpu&points=1&after=-10&options=seconds

it returns 1 point for the last complete 10-second duration (it starts at timestamp % 10 = 0). Check it. It will return one new value every 10 seconds, and the timestamp will always end with zero. Similarly if you say points=1&after=-5 it will always return timestamps ending with 0 or 5.

So, I don't think we should merge this.

I should also add that even after this PR, the returned value will be misleading. The returned value will not be the average of the 3600 points. It will be the average of 1 up to 3600 points depending on the time you asked for it.

I am thinking of adding an option to the API for disabling this alignment for the specific request. This can be useful if you really want to get misaligned data: #316 #205