[collectd] Collectd plugin for Madwifi and some questions

[Sebastian Harl]

Hi Ondrej,

On Thu, Jul 16, 2009 at 07:47:23AM +0200, Florian Forster wrote:
> On Thu, Jul 16, 2009 at 01:29:34AM +0200, Ondrej Zajicek wrote:
> > For example CPU plugin uses plugin_instance to specify CPU, but
> > Interface plugin uses type_instance to specify interface. That seems
> > to be inconsistent (from my point of view).
> 
> That's basically a known bug [...]

Maybe, we should even document that in the manpage ...

> > In the madwifi plugin, there are two levels of a hierarchy - first,
> > several network interfaces, second, several stations connected to that
> > interface. And for each station we have several statistics (RX, TX,
> > RSSI, ...). So a natural idea is to specify an interface name in
> > plugin_instance and station MAC address in type_instance. Is that a
> > good idea?
> 
> That's sounds good to me.

You could also think about using <interface>-<station> (note that '-' is
allowed in the plugin / type _instances_ - think of it as some kind of
list element separator) as plugin instance. I'm currently not sure about
what makes more sense to me - maybe someone else has a comment about
that ;-)

> > 2) There are many different types of rx/tx errors exported as separate
> > counters from Madwifi. The plugin collects them separately. That would
> > lead to many data streams (~ 200 per interface), most of them full of
> > zeroes. Therefore i submit these counters only if they are non-zero.
> > Is that a good idea?
> 
> That's what we do in the MySQL plugin, but I have to admit I'm not a big
> fan anymore.

Ack.

> > 3) Besides of these counters, there are RSSI (received signal strength
> > indicator) for each station, but this value is updated only when a
> > packet is received from that station. I think that RSSI value should
> > not be submitted if there is no received packed from last RSSI
> > submission. It is correct to do such irregular data submission?
> 
> Yes, that'd be okay by me, but it may cause problems with RRDtool's
> consolidation.

... which might confuse users. Anyway, imho, there are two ways to look
at this situation: a) if the value has not been updated, it did not
change, so the old value should still be used or b) we don't know the
RSSI if the value has not been updated (the important point being that
RSSI _is_ subject to change in the meantime), so the value should be
considered unknown, i.e. it should not be submitted. Are you able to
tell if the value has been updated or do you simply get the same value
no matter if it happened to stay the same or if no packet has been
received?

What do you think about submitting the latest RSSI value (in case it did
not change in the meantime) for x (something like 3-5 should be fine)
intervals. This would make sure that we don't end up having unknown data
in the (e.g.) RRD files but still honors the fact that there might be
intervals with unknown data.

Anyway, whatever solution you decide to implement, the behavior should
be documented in the manpage.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090716/789fa3eb/attachment.pgp