Seeking advice on client idle detection / server shutdown

[epoch1970]

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… EDIT: ah yes, connecting both ends of the pipe (re examining the past to predict what's probably next) means "rewriting history". So there may be use for manipulations after all.

I got to go. I'll be back

HTH