5.0 Final: Possible bug in cpu frequency scaling.


Recommended Posts

OK now that is weird.  I went back to ondemand and parity only slowed down to 120 and i can see the cpu's ramping up much more via watch -n.1 'cat /proc/cpuinfo|grep MHz' (awesome command btw :o )

 

As I one by one changed the each core back to performance i could see parity speed incrementally increase.

 

EDIT:

OK so i did my own homework, i get it now.  I played around and it seemed for me these worked best

 

echo -n 25 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo -n 60 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

 

50/50 wasn't any faster, but it seemed to keep the cpu more revved up than it needed to be at idle.

 

I put those lines in my go script.

Link to comment
  • 7 months later...

Just a brief update, 5.05 did allow me to unload the p4_clockmod module but acpi_cpufreq was not compatible with my celeron so no joy. Oh well. I could have sworn ondemand was working with p4_clockmod in bubbaraid but all the searches I do suggest that it is somehow not compatible with my Celeron.

 

 

Link to comment
  • 1 month later...

Just another update. For me the best solution was to buy a used core 2 duo e6700 for $16 (fastest cpu my P5LD2 VM R2.0 would support). This gave me a lower temp, lower power CPU when idle or even running parity checks and more processing power if needed. The frequency scales from 1.6GHz to 2.66GHz using ondemand. Only apps like ffmpeg or mprime would ever need enough CPU to scale it to 2.66GHz.

Link to comment