[mrtg-developers] Idea for alternative MRTG scheduler

[S Shipway]

The reason I thought the scheduling interval should be multiplied by 0.9 was to allow 10% of the interval free at the end for the last targets to complete.  Obviously this assumes that no target will take >10% of the time, which would be 30s in a normal 5min interval.  The other possibility is to make the window completely sliding; so it doesnt matter if the poll overruns the interval, it just gets stored into the next interval.  This would probably not work so well with the existing scheduler, though.

You could think of the existing Forks: directive as an indicator of the maximum polling rate; the problem is if this is not high enough to handle the number of defined targets, the system won't automatically increase it (but maybe it could?  If the polling cycle doesnt complete within the interval, automatically increase Forks: by one until it reaches some other defined limit?)

I did write an alternative scheduler for MRTG using shellscript that used this algorithm; the disadvantage was that it respawned MRTG for each cfg file individually, so it was not efficient with resources, and still had the problem of individual targets within a single cfg file having to schedule together.

Steve

Steve Shipway
University of Auckland ITS
UNIX Systems Design Lead
s.shipway at auckland.ac.nz<mailto:s.shipway at auckland.ac.nz>
Ph: +64 9 373 7599 ext 86487


-- 
View this message in context: http://mrtg-mailinglists.795376.n2.nabble.com/Idea-for-alternative-MRTG-scheduler-tp5843836p5844683.html
Sent from the MRTG Developers Mailinglist mailing list archive at Nabble.com.