I just reboot the hub and still get the same very high numbers.
Since we now only deal in percentages, not absolute values, shouldn't the dividend, the top number, in the fraction of % busy, be calculated on the same basis as the bottom number, the divisor?
It seems as if the hub up time, the divisor, is reset after a hub restart, whereas the app or device time used carries over from before the hub was restarted.
Doesn't seem consistent too me, especially since % is all we have now. @gopher.ny ?
1 Like
I screwed up: hub up time is not busy time. We don't know the hub busy time raw number in the divisor. The conclusion is still the same, far as I can see: The dividend gets set to zero on a hub restart, and the dividend carries over.
Can't say I have thought this through in any great detail... But I could imagine there being some benefit to some device or app stats being carried over after a reboot to allow some analysis when needing restart in safe mode, for example.
That doesn't answer your questions about the interplay between the numbers being used, but it could explain part of why things are handled the way they are for part of the puzzle.
It does not. The performance penalty of doing so would be non-trivial. Also, those numbers are meant to be a guide for finding overly busy apps/drivers, nothing else. They are not precise, and the effort to make them so + resource overhead involved would far exceed the usefulness of having the precision.
2 Likes
Ok, thanks.
I get confused easily, so please excuse any faux pas. 
1 Like
Speaking simply as a developer of a user app, it may be nice for someone writing code to have a way to turn that level of performance analysis on even with the hit. I wouldn't suggest it be easy to activate or for everyone to even thibk of turning it on, but being able to take a dev hub and analyze performance impact of my app vs a baseline could be good, or raw memory numbers. Ofcourse i say that with no idea how hard it may be to implement though 
2 Likes
