NOTICE: Registration may require manual admin activation. After registering visit https://bitsum.com/contact/ to request account activation.
Started by throttling, March 28, 2013, 12:47:10 AM
Quoteadd a drop cpu instructions upon ending throttle to prevent the cpu from trying to catch up on work it wasn't able to do while the cpu was throttled causing it to work harder.
Quote from: Support on March 28, 2013, 10:43:29 PMThe throttling is indeed a neglected feature. I am not a big fan of it. However, in this time of maintenance, I will go ahead and rework the code, and allow it as a watchdog option.
Quote from: BenYeeHua on March 29, 2013, 02:11:53 AM[...] and the priority is not so perfect for that.
Quote from: hanemach_gt on March 29, 2013, 06:13:42 AMI got it like you know better way?http://bitsum.com/docs/pl/faq.htm#slowhttp://bitsum.com/docs/pl/faq.htm#percent_request
Quote from: BenYeeHua on March 29, 2013, 02:08:10 PMWhat I means is, if you has 6-8 process set as "below normal" that don't affect the normal use, how can you make sure the important one get process first?(ya, maybe set it as low.)And I has using some stress test tool, it lost performance after it has been set as "below normal" by Process Lasso, which I saw the power consumption drop nearly 60%, but it still showing 100% CPU usage.I think maybe the cache is losing much when set as "below normal", and cause performance hit?PS:Not enough sleep and don't try the function yet, just point out my error after you has try.
Quote from: BenYeeHua on March 29, 2013, 02:08:10 PMI think maybe the cache is losing much when set as "below normal", and cause performance hit?
Quote from: hanemach_gt on March 29, 2013, 05:03:33 PMI'm not into hardware<->software relations, I just threw what I've known from what Bitsum tells to the end user. It is indeed interesting, now I understand what you wanted to say.I guess you are mistaken in some matter, I am not here to point or either hunt on anyone's errors and show how cool I am, because I am not cool or anything. If you felt offended at any point, I am sorry.
Quote from: Support on March 29, 2013, 05:48:10 PMCould be, though I can't help but think the change in power consumption surely was exacerbated by other factors. The disruption caused by context switches is pretty hefty. Your caches tend get tossed away, and it's generally a very expensive operation. If the change in priority caused a large increase in context switches, then that might explain the situation. Benchmarks and stress tests are unique circumstances though, very few real applications operate the way they do. Of course, that's why ProBalance is set to ignore processes of non-normal priority, so it doesn't much with benchmarks and any other application that has specifically requested its priority class.If you have multiple processes of the same priority class, then, individual thread priorities not withstanding, they should get access to the CPU nearly equally, with some precedence given to the foreground application (by Windows itself in the form of longer time slices). System components and other applications running at a Normal priority will take priority over a 'restrained' process, and thusget the few CPU cycles they need to be responsive. This is why lowering the priorities works so well (instead of trying to raise the priorities of everything else).In general, these days, with ever increasing number of cores, limiting a CPU by % is indeed possible through CPU affinity adjustments, as I mention in the FAQ article hanebach_gt pointed out. If your goal is such, that's definitely the preferred method. You're limited in granularity to 100/num_cores, but no method works better than that.