https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219213
--- Comment #5 from SF <shitma...@hotmail.com> --- After sleeping and reading the stuff from powerd++ over and over again to understand it there is just one problem to my idea and this is responsiveness. I dont know how the load is calculated while the cpu is throttled down to p-state 0, can they still calculated what would be the load if the cpu would run at max. p-state or can they only retrieve the load out of the current clock? -powerd++ sets the clock frequency according to a load target, i.e. it jumps right to the clock rate it will stay in if the load does not change. It will take 4 seconds within my example to push the cpu from p-state 0 to p-state 4, halfing the primary interval to 500ms will get it to 2s but still far too low. Advantage of mine is it will be much more stable and accurate to set the truely needed p-state. Powerd++ will skip high-spikes, always averaging the p-state down to a lower one. It doesn't respond to high-spikes or goes bungee. Both of this doesn't solve this, on server's and for gaming there is circumstances you need the highest p-state to avoid hitting the caps while such spikes occur. You could add an option to boost the cpu to p-state 4 within under 500ms and take the other calculations to make it slowly throttle down after this. This will increase responsiveness under such circumstances but might also cause the cpu to get stuck within a high p-state because of some few spikes each second. Atm i have problems solving this because reacting to high spikes might make the cpu never leave a high p-state. If there is just one high-spike per second which needs the p-state 4 then it is completely unnecessary to make the cpu boosting into this state. Exceptions to this are servers at specific times with users often causing such kind of spikes, there might be reasons to deliver a high quality experience to them. Within games there is also reasons to react onto such spikes but if this is the case the gamer will turn off its power-saving-features. This is something different to having a server, the admin cannot always interact with the machine to fit the current required needs of performance. Adding another option to set-up specific times for enabling the boost-function might be usefull, you could also make the computer watching this over a long period of time like one month to make it decide itself when it is the time to enable the boost. There is no other way solving this dilemma. Increasing responsiveness will always lead to periods with higher p-states then might be needed. The powerd++ solution is faster but cannot react onto spikes, its flattening your performance down. There is no priority's to set and no counters to differ between what is needed, it also only reacts always to one single core which is the core with the highest load. -powerd++ supports taking the average load over more than two samples, this makes it more robust against small load spikes, but sacrifices less responsiveness than just increasing the polling interval would. Because only the oldest and the newest sample are required for calculating the average, this approach does not even cause additional runtime cost! I think powerd++ is something for old and slow cpu's, on a Ryzen R7 1700X i have 16 Cores i need to take care of and there is no problem giving such more complicated calculations to one spare core. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
