Wow, I'm impressed.

Just from reading your documentation, and from my experience I think
these 3 notes may be relevant:
- very often I initialize a pipe with 1s to mean active. Scenario: wol
the server, have some time to start an activity before the system acts
again 
- usually I reinitialize a pipe before suspending or at wake up.
Scenarii: avoid bouncing to sleep (esp. when using multiple pipes),
reset drives spindown pipes at wake-up.
- In my config files I express pipes length in minutes (secs), as it
is natural to do so. I have a bit of code that creates the right amount
of slots given measurement frequency (eg 30-sec runs vs. 2-min. runs, 10
minutes activity pipe -> 20 slots or 5)

Probably less relevant:
- my pipes are summerized as: active/idle (most of the time), ok/alert
(eg case temp.), keep/change state (eg drive spin, which may stop by
itself due to firmware/hdparm conf). 
- In my code I handle the signals on hardware condition with a higher
degree of priority (eg shutdown on over-temperature regardless of any
preference/status)
- Ideal time resolution can vary from one item to another. For example
fan sensors can be momentarily off, and come back correct just the next
second. So you'd want a pipe with a lot of slots to accurately capture
a 5-minute fan failure condition ("fan has died")
Some other times the measurement process can be long/heavy so you don't
want to strain the system or fill the pipe with false alarms if the test
did not return a value in time; for example SB status detection when
connected to mySB.com.
- I've never used anything but push+shift. I don't know if "re-writing
history" (beyond re-init) has a use
- I'm sure of the following case (but never tested it), for player
activity: (recent..old) [1 1 0 0 0 0] is a more meaningful activity
hint than (recent..old) [0 0 0 0 1 1]. That's the endianness thing I
was relating to.
- I've been using a clumsy cascade of pipes with a master one starting
to empty when the global system status turns idle, to add some inertia
to the system. Eg AFP pipe says idle, SB pipe says idle, net pipe
(still) says active (it is longer/less precise), global status voted
for idle (via arbitrary weighted average), hence 5minute "last-chance
pipe" starts emptying (system will stop when this one is empty)
I think you're headed to considering the last x minutes of a larger
pipe and I have the impression this is a solution to that mess.
- I haven't made any progress on the bayesian approach to system
activity prediction, but pipes turned into (long) rings and made
persistent were in my grand plan for world domination…

I got to go. I'll be back :)

HTH


-- 
epoch1970

Daily dose delivered by: 2 SB Classic (fw 130), 1 SB Boom (fw 50) •
SqueezeCenter 7.3.4 (Debian 5.0) with plugins: ContextMenu,
SaverSwitcher by Peter Watkins • Server Power Control by Gordon Harris
•  WeatherTime by Martin Rehfeld • IRBlaster by Gwendesign (Felix) •
FindArt, CDplayer by bpa • BBC iPlayer, SwitchPlayer by Triode •
PowerSave by Jason Holtzapple • TrackStat by Erland Isaksson.
------------------------------------------------------------------------
epoch1970's Profile: http://forums.slimdevices.com/member.php?userid=16711
View this thread: http://forums.slimdevices.com/showthread.php?t=49028

_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix

Reply via email to