[collectd] Collectd plugin for Madwifi and some questions

[Ondrej Zajicek]

Hello

I am developing a Collectd plugin for Madwifi (a driver for Atheros wifi
cards). Madwifi driver allows to run wireless cards in AP mode and have
several private ioctls to acquire statistics about stations assciated to
that AP, so standard wireless plugin is completely inadequate in that
case. I have several questions related to Collectd:

1) Are there any guidelines for using plugin_instance and type_instance?
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). 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?

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?

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?

4) A general question, not specific to Madwifi - if i have a slowly
changing counter and i submit its value during each iteration, is it
sent each time to the network, even if the value is the same, or is it
optimized? If it is sent each time, is it a good idea to submit a value
of the counter (in a plugin) only if there is a change?

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- 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/d4d571a3/attachment.pgp