This is something that I am fairly certain that I can do using existing relevance & actionscript, so I guess this is more of documenting an idea that I plan to implement rather than a true Enhancement request.
I am frequently in the middle of testing BigFix content, and often wish that the BESClient was more aggressive. This often leads me to set the client settings to be very aggressive on my testing machines, but this has a very negative affect on battery life of my laptop. It occurs to me that the BESClient settings could automatically become more aggressive when the FixletDebugger.exe or QnA.app are running on the system, and the settings could automatically be reduced when on battery. In general, through open actions, the BESClient itself could manage this, and other behaviors similar to this app: http://www.controlplaneapp.com/
Possible states:
Normal: On AC Power (plugged of power level) Reduced: On Battery Power (laptop or desktop UPS) (not plugged of power level) Aggressive: FixletDebugger or QnA currently running
plugged of power level
not plugged of power level
state of current system interval of power history
state of current monitor interval of power history
exists names whose(it starts with "FixletDebugger" OR it starts with "QnA") of processes
So are you looking for power inspectors? The functionality that chooses the right PowerSaveTimeout based on power is exposed in relevance. When your power lowers if you are on one of the sleep modes, the sleep times increase as your power drops.
For FixletDebugger or QnA, they ignore those settings anyway so they run at full speed.
Q: power level
A: full battery power plugged in
Q: full of power level
A: True
Q: normal of power level
A: False
Q: low of power level
A: False
Q: plugged of power level
A: True
Q: ups of power level
A: False
I actually wasn’t looking for power inspectors because I was pretty sure I could figure out something that would work using WMI or IOREG, but if those inspectors you just listed work well, that could be perfect.
I am basically documenting something that I plan to do, hoping that if anyone has something similar already, or tips, like these power level inspectors, they’ll add it here.
As for the FixletDebugger & QnA, I don’t mean to say I would be adjusting how the FixletDebugger or QnA work themselves. I mean that I would adjust the way the BESClient works based upon the fact of QnA/FixletDebugger running on the system as a signal that the person currently logged into that system is doing BigFix related testing and may desire that the BESClient go into an aggressive mode to enable testing to happen much more quickly.
Often I will have the QnA/FixletDebugger open on a system when I am testing things through the console. I will write something in the client tools, then put it in the console, then go back and forth until I get something working… then close QnA/FixletDebugger.
When QnA/FixletDebugger is open I may want CommandPolling to happen every 5 min, and I may want the Max CPU of the client to be 25% or so, and I may want the Report_MinimumInterval to be every 30 seconds… but when QnA/FixletDebugger are closed, I may want CommandPolling to be once an hour, Max CPU to be under 5%, and Report_MinimumInterval to be every 5 min, etc…
Does it only take affect on battery power, or does it also take
affect when the laptop is plugged in?
How is CommandPolling affected when PowerSave is enabled?
Is the EvalLoop paused during Client Sleep with PowerSave?
What happens when the Client comes out of sleep? 1 full EvalLoop, then back to sleep? What about any open actions that may have become relevant that the client already has?
Since you want to crank up (or down?) the reporting interval, you might also want to make sure your workstation is reporting to your Primary BES Server rather than a Relay.
That is an interesting idea, that reporting directly to the root is better for developing content rapidly. I think this wouldn’t help much in our environment because our console refresh interval is so long(5min?), getting the reports slightly faster is not much of a benefit.
It takes affect in all conditions.
CommandPolling is essentially paused while the sleep event is done. The timers don’t stop though so if you sleep for 10 mins the time is included in the command poll time
There is no background evaluation during sleep.
When the client comes out of sleep it starts doing its job. If it can get through a complete evaluation cycle without ANYTHING changing then it can go to sleep but if actions become relevant it will process them etc. Active actions prevent the client from sleeping.
Additionally opening the client ui will make the client wake up as well.
Thanks for the clarification. I am definitely getting a good idea of how PowerSave works.
If the client is sleeping, and it should have polled for commands while it was asleep, will it just defer the poll for commands until it wakes, and do it then? or would it miss polling for commands completely for that cycle?
Any time based event (including Polling) is just seeing if the minimum time has happened. So if you have polling set to every 10 mins and you slept for 60 mins, as soon as it came to the polling point in the client loop it would do the polling as the minimum time has elapsed.