File:  [ELWIX - Embedded LightWeight unIX -] / embedaddon / bmon / TODO
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Feb 21 22:19:56 2012 UTC (12 years, 3 months ago) by misho
Branches: bmon, MAIN
CVS tags: v2_1_0p0, v2_1_0, HEAD
bmon

    1: bmon TODO/Wishlist 
    2: ==================
    3: 
    4: 1: Differ between interactive and non-interactive output modules
    5: 
    6: 	Currently the timing is done by sleeping in small amounts and
    7: 	check if the next read interval has been reached. The sleep
    8: 	amount gets adjusted to hit the next read interval as accurate
    9: 	as possible.
   10: 
   11: 	This is only needed for interactive output modules. Non-interactive
   12: 	output modules could enforce a timing strategy which would sleep
   13: 	exactly to the next read interval and thus save some cycles.
   14: 
   15: 2: XML Output Modules
   16: 
   17: 	bmon's portability advantages could be used to provide all the
   18: 	architecture specific interface statistics and convert them to
   19: 	a generic XML based interface. There should be interfaces:
   20: 	
   21: 	b) State based
   22: 
   23: 		The current state as it would be outputed by bmon itself
   24: 		written as XML message and overwritten in every output
   25: 		interval (just like the already implemented HTML output).
   26: 		This could be used by 3rd party applications to display
   27: 		the current statistics and rate estimations.
   28: 
   29: 		Problem: Locking
   30: 
   31: 3: SNMP Input Module
   32: 
   33: 	A SNMP input module (secondary) would increase the usefulness
   34: 	in environment with properiatary hardware to which bmon
   35: 	cannot be ported.
   36: 
   37: 	Problems:
   38: 	a) Async nature
   39: 
   40: 		The whole module must be implemented async, this itself is
   41: 		not a problem but the protocol enforces various handshakes
   42: 		required to get the statistics:
   43: 
   44: 		1) Get number of interfaces
   45: 		2) Wait for the result (could be cached)
   46: 		3) Request statistics
   47: 		4) Wait for the result
   48: 	
   49: 	b) Accuracy
   50: 
   51: 		Due to the handshakes required the accuracy can vary depending
   52: 		on current network latency and it is quite hard to adjust it.
   53: 		Other statistical applications using SNMP don't have this problems
   54: 		because they don't require update intervals of <= 1 second.
   55: 
   56: 5: MAPI Input (highly configurable)

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>