Hello, to justify the switch from interactive/ondemand to performance as default cpufreq governor the following 2 year old sources are cited again and again:
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00492.html https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00678.html http://www.cubieforums.com/index.php/topic,1413.msg8745.html#msg8745 Unfortunately they miss the dvfs settings used ‹ it seems all cpufreq operating points shared the same voltage. Using recent Allwinner SoCs with 3.4 kernel and reasonable dvfs settings (adjusting core voltage depending on CPU clockspeed) it's obvious that it makes a difference at which clockspeed the CPU idles since different voltages lead to different consumption levels. I have no multimeter that would be precise enough so I rely on the thermal sensors in the 2 SoCs I used to show the difference the clockspeed makes depending on dvfs settings. I let a script walk through scaling_available_frequencies while being idle and monitored temperature and in A83T's case also Vcore voltage. The conclusion is obvious: What happens when switching between performance and interactive/performance depends largely on the *voltage settings* defined in the dvfs table. This is a H3 with 'sane' dvfs settings on the left side and the commonly used overvolted/overclocked settings the Orange Pi manufacturer chose to advertise the H3 as being a '1.6 Ghz SoC': http://kaiser-edv.de/tmp/h3vOAh/H3.png (on the left adjusted/sane settings, on the right after a reboot at 19:15 the overvolted/overclocked 'defaults' every OS image for H3 boards is using ‹ this is where the heat problems origin from the H3 is blamed for) With sane settings the difference in idle temperature is 3°C (41°C at 480 Mhz and 44°C at 1200 Mhz), with 'default settings' (only two operating points defined at the upper limit), the difference is 6°C (45°C at 480 Mhz and 51°C at 1536 Mhz). Both dvfs tables as reference below [1] [2] Since the A83T is accompanied by a PMU (AXP813) it's possible to monitor Vcore voltage through sysfs. Here the core voltage is adjusted between 820mV at 480 Mhz and 1080mV at 1800 Mhz [3] and this results in a difference of 4°C when being idle: http://kaiser-edv.de/tmp/h3vOAh/A83T.png It's obvious that consumption (SoC temperature) depends more on core voltage than clock speed and therefore the switch to performance as default governor seems like a waste of energy. A more sane approach would be to stay with ondemand/interactive and adjust scaling_min_freq to the operating point with the lowest voltage defined in the dvfs table (since then no further saving can be achieved when clocking lower). While I understand that switching to performance seemed like a good idea 2 years ago (OS images with fantasy governor and scaling_min_freq at 60 Mhz in the wild) I doubt that it's still right when keeping voltage settings in the dvfs table in mind. Best regards, Thomas [1] Overvolted/overclocked default dvfs settings Xunlong (Orange Pi manufacturer) used to promote the H3 as being able to clock up to 1.6 Ghz: extremity_freq = 1536000000 LV1_freq = 1536000000 LV1_volt = 1500 LV2_freq = 1200000000 LV2_volt = 1300 [2] Attempt to define 'normal' dvfs settings for H3. Adjusting voltage between 980mV at 480 Mhz and 1240mV at 1200 Mhz: extremity_freq = 1296000000 max_freq = 1200000000 min_freq = 480000000 LV_count = 7 LV1_freq = 1296000000 LV1_volt = 1320 LV2_freq = 1200000000 LV2_volt = 1240 LV3_freq = 1104000000 LV3_volt = 1180 LV4_freq = 1008000000 LV4_volt = 1140 LV5_freq = 960000000 LV5_volt = 1080 LV6_freq = 816000000 LV6_volt = 1020 LV7_freq = 480000000 LV7_volt = 980 [3] A83T dvfs settings: 820mV at 480 Mhz and 1080mV at 1800 Mhz [dvfs_table] vf_table_count = 3 [vf_table0] ;little L_max_freq = 2016000000 L_boot_freq = 1800000000 L_min_freq = 480000000 L_LV_count = 8 L_LV1_freq = 2016000000 L_LV1_volt = 1080 L_LV2_freq = 1800000000 L_LV2_volt = 1000 L_LV3_freq = 1608000000 L_LV3_volt = 920 L_LV4_freq = 1200000000 L_LV4_volt = 840 L_LV5_freq = 0 L_LV5_volt = 840 L_LV6_freq = 0 L_LV6_volt = 840 L_LV7_freq = 0 L_LV7_volt = 840 L_LV8_freq = 0 L_LV8_volt = 840 ;big B_max_freq = 2016000000 B_boot_freq = 1800000000 B_min_freq = 480000000 B_LV_count = 8 B_LV1_freq = 2016000000 B_LV1_volt = 1080 B_LV2_freq = 1800000000 B_LV2_volt = 1000 B_LV3_freq = 1608000000 B_LV3_volt = 920 B_LV4_freq = 1200000000 B_LV4_volt = 840 B_LV5_freq = 0 B_LV5_volt = 840 B_LV6_freq = 0 B_LV6_volt = 840 B_LV7_freq = 0 B_LV7_volt = 840 B_LV8_freq = 0 B_LV8_volt = 840 [vf_table1] ;little L_max_freq = 2016000000 L_boot_freq = 1800000000 L_min_freq = 480000000 L_LV_count = 8 L_LV1_freq = 2016000000 L_LV1_volt = 1080 L_LV2_freq = 1800000000 L_LV2_volt = 1000 L_LV3_freq = 1608000000 L_LV3_volt = 920 L_LV4_freq = 1200000000 L_LV4_volt = 840 L_LV5_freq = 480000000 L_LV5_volt = 820 L_LV6_freq = 0 L_LV6_volt = 820 L_LV7_freq = 0 L_LV7_volt = 820 L_LV8_freq = 0 L_LV8_volt = 820 ;big ;big B_max_freq = 2016000000 B_boot_freq = 1800000000 B_min_freq = 480000000 B_LV_count = 8 B_LV1_freq = 2016000000 B_LV1_volt = 1080 B_LV2_freq = 1800000000 B_LV2_volt = 1000 B_LV3_freq = 1608000000 B_LV3_volt = 920 B_LV4_freq = 1200000000 B_LV4_volt = 840 B_LV5_freq = 480000000 B_LV5_volt = 820 B_LV6_freq = 0 B_LV6_volt = 820 B_LV7_freq = 0 B_LV7_volt = 820 B_LV8_freq = 0 B_LV8_volt = 820 [vf_table2] ;little L_max_freq = 2208000000 L_min_freq = 480000000 L_LV_count = 8 L_LV1_freq = 2208000000 L_LV1_volt = 1080 L_LV2_freq = 2016000000 L_LV2_volt = 1000 L_LV3_freq = 1800000000 L_LV3_volt = 920 L_LV4_freq = 1368000000 L_LV4_volt = 840 L_LV5_freq = 0 L_LV5_volt = 840 L_LV6_freq = 0 L_LV6_volt = 840 L_LV7_freq = 0 L_LV7_volt = 840 L_LV8_freq = 0 L_LV8_volt = 840 ;big B_max_freq = 2208000000 B_min_freq = 480000000 B_LV_count = 8 B_LV1_freq = 2208000000 B_LV1_volt = 1080 B_LV2_freq = 2016000000 B_LV2_volt = 1000 B_LV3_freq = 1800000000 B_LV3_volt = 920 B_LV4_freq = 1368000000 B_LV4_volt = 840 B_LV5_freq = 0 B_LV5_volt = 840 B_LV6_freq = 0 B_LV6_volt = 840 B_LV7_freq = 0 B_LV7_volt = 840 B_LV8_freq = 0 B_LV8_volt = 840 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
