Hi Kevin, the structure is
HHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHH RRA1-DS1DS2DS3DS4DS5... RRA1-DS1DS2DS3DS4DS5... RRA1-DS1DS2DS3DS4DS5... RRA1-DS1DS2DS3DS4DS5... RRA1-DS1DS2DS3DS4DS5... RRA1-DS1DS2DS3DS4DS5... RRA1-DS1DS2DS3DS4DS5... RRA1-DS1DS2DS3DS4DS5... RRA2-DS1DS2DS3DS4DS5... RRA2-DS1DS2DS3DS4DS5... RRA2-DS1DS2DS3DS4DS5... RRA2-DS1DS2DS3DS4DS5... RRA2-DS1DS2DS3DS4DS5... RRA2-DS1DS2DS3DS4DS5... RRA2-DS1DS2DS3DS4DS5... RRA2-DS1DS2DS3DS4DS5... the only thing that is not interleaved which might be, is the 2h max and average array ... > My current solution is a perl wrapper around the RRDs lib to write to CSV > files and a cron job to update the RRDs hourly or when grapher is run. > reducing the caching requirement to 110Meg to do the real time updates. > I see this is similar to RRD Accelerator but uses files directly not via > sockets. When is 1.3 due? 1.3 is due when it is done :-) regarding the accellerator, I have not started working on it yet, and I am wondering if maybe a mmaped file as communication 'platform' may be better siuted. it would have the advantage, that it could be synced to disk, makeing it crash resistant ... cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten http://it.oetiker.ch [EMAIL PROTECTED] ++41 62 213 9902 _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
