[rtg] rtg polling aligned

[bill fumerola]

On Fri, Jul 14, 2006 at 08:39:46PM -0700, Matt Provost wrote:
> There's nothing in the poller now to do this. If you start it from
> cron/at at a particular time it should stay pretty much aligned though I
> would think.

one target stalling/returning in shorter/longer time than previous poll
round and you'd be off. also, if you change the target list and reload
the targets all bets are off.

a couple ideas to implement this: you could use a non-blocking scheduler
thread that spawns a thread (or grabs from a pool) that handles one
target. rtgpoll could get pretty heavy under this design though. i guess
you could also use kqueue(2) with EVFILT_TIMER but that's not portable
and would take serious rototilling of the code. i don't know if libevent
(portable) supports the analogue of EVFILT_TIMER.

either way thread management becomes slightly more complex as you have
to make sure you have threads available when a target's time comes. you
wouldn't want the scheduler thread or the event handling loop to block
for very long (waiting for threads to be returned, allocating more, etc).

i'm not sure why you need it though. as long as you keep track of time
deltas you can derive the same information as if they were consistant.
the contrived worst case scenario would be poll rounds like such: t1+1,
t2+599, t3+1, t4+599, t5+1...  is that what you're seeing?


-- bill

ps.  yrtg tracks stalled/failed targets better and also hashes targets
     across available threads very evenly. increasing threads may help
     quite a bit if there's too much jitter. you don't have to worry
     about all the threads attacking one host; there's a per-host mutex.