[collectd] High-resolution sensors collection...

Alceu Rodrigues de Freitas Junior glasswalk3r at yahoo.com.br
Thu Jun 15 20:03:33 CEST 2017

Hello Bryan,

Here are my thoughts (and not directly related to Collectd itself): Java 
is fast, but the JVM will require a good amount of memory, which you 
might not have plenty your "little SOC".

If the Java program is not running continuosly, starting the JVM 
everytime is not an option for you. C would definitely be a better 
option for it. And also help with memory consumption (you definetely 
don't need OOP or all Java features to get this work done).


Em 15/06/2017 14:27, Bryan Varner escreveu:
> Hi all,
> I have a feeling I know what the answer to this question will be, but I wanted to ask here in case someone has a better or easier idea....
> I have an i2c sensor that I can poll with libsensors (and the appropriate collectd plugin). I'd like to read this value > 60 times a second, then calculate the RMS of the value and log _that_.
> So far, I've tried using the sensors plugin with it's own ridiculously small interval, and a custom filter & read plugin that would cache the values dispatched to it, then when it's read interval hit, would do the calculation on the cached data points and dispatch the result.
> This resulted in the sensor plugin read not being 'fast enough' to get enough samples / interval for the calculation to be anywhere near accurate.
> I have a sneaking suspicion that because my filter / coalesce plugin was in java, the context swaps were just too much for the little SOC (it's a Raspberry Pi Zero W) I'm running all this on.
> So I guess I'm trying to figure out what path to take at this point:
> * Should I bail on the filter / read plugin approach completely and write my own purpose-designed plugin?
>    I'm thinking something that creates a high-priority thread to read the sensor data into a circular memory buffer then on 'read' intervals does the calculation and reports the results?
>    I think this would make more sense, but is there a 'right way' or 'wrong way' to handle threading in a collectd plugin?
> * Or is it possible that the JVM overhead was just too much for the SOC and I should reimplement the filter / coalesce read as a generic C plugin instead of Java?
> * Is there a simpler method I'm just missing?
> Regards,
> -Bryan
> P.S. Yes, I realize I'm trying to aggregate / calculate a value, but that's the value I want reported to my storage backend, the other minute values are really useless without the calculation, and I'd rather calculate the rolling RMS upon collection (and store a meaningful number) rather than calculate it for every reporting cycle later.
> _______________________________________________
> collectd mailing list
> collectd at verplant.org
> https://mailman.verplant.org/listinfo/collectd

More information about the collectd mailing list