[rtg] rtg polling aligned

[Eric Ji]

Atle, Matt and Bill, thanks for the helpful
information.
The trigger for this is that when there are multiple
pollers to poll different devices, and you need compare
the traffic on those interfaces in real time and find
the least or most loaded interfaces to direct traffic
on or off. Also, if the intervals are aligned up
nicely, it's easy to sync rtg with other systems as
their data feeds input. Or maybe even there's an option
to start the first round of polling at aligned time is
helpful than nothing. Any idea or plan on this, or is
there a feature request queue for rtg? I think this is
useful when multiple rtg pollers are used or rtg is
served as a data source.

Thanks,
Eric

-----Original Message-----
From: bill fumerola [mailto:billf at mu.org] 
Sent: Saturday, July 15, 2006 1:09 PM
To: Matt Provost; Eric Ji
Cc: rtg at fireflynetworks.net
Subject: Re: [rtg] rtg polling aligned

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.