Discrepency of cpu MHz via bash and conky

**Edit:** The original question of this post was regarding the "average" cpu MHz as obtained via conky builtins and the command line. A further question was regarding temperatures as reported by conky vs temperatures obtained via the command line. A tertiary question was regarding per core MHz as reported by both methods. 1. The "average" MHz question has been rendered superfluous by my discovery that I'd messed up my conkey.conf file a very long time ago. There is no average cpu MHz variable in the current version of conky, and there might not have ever been. In addition. it's such a transitory measurement, I'm not sure it's actually useful at all - at least for me. 2. @terdon requested a minimal conkyrc file so other people could try to reproduce what I said I was experiencing. So I created one. I'll include it below. But creating it allowed me to see I was seeing what I expected to see - not what was actually there. It turns out that the command I had been using to get the cpu temp - ${hwmon 1 temp 3}, actually is the cpu die teperature plus the Tctl offset for fan control. The actual cpu temp can be obtained with this command: ${exec sensors -f k10temp-pci-00c3 | grep Tccd1 | cut -b 15-21}F. I don't see a way to get the actual cpu temp through conky's builtins. 3. The per core MHz question as reported by conky's builtins, and the command line. This question is still out there, but I think I know whats going, I just haven't proved it yet. At least to myself. I created the requested conky.conf - I don't use a conkyrc file. And running it next to my actual conky was giving me really interesting results. So I created another version, identical to the other, but one being aligned to the middle_left, and the other being aligned to the middle_middle. In these conky.conf files, I'm using both the builtins, and getting the stats from an exec command. Interestingly, all 4 sets of data from these two conky instances will often align very well. Sometimes almost perfectly! That was actually surprising. And the data being reported from my actual conky was almost always in the 3-4 GHz range, while the two test conky's was almost always in the 2 GHz range... So, what I think is going on is my 'production' conky.conf is rather large - with lots and lots going on. and it kicks up the cpu frequency while it's running. And then when the test conky.confs are running, they show lower GHz because they're actually being less demanding. Does this sound reasonable? Here's the test conky.conf: conky.config = { alignment = 'middle_left', background = false, update_interval = 1.5, cpu_avg_samples = 2, out_to_console = false, override_utf8_locale = true, double_buffer = true, text_buffer_size = 8192, own_window = true, own_window_transparent = true, own_window_argb_visual = true, own_window_type = 'normal', own_window_argb_value = 0, own_window_hints = 'undecorated,below,sticky,skip_taskbar,skip_pager', border_inner_margin = 20, border_outer_margin = 0, font = 'monospace:size=10', gap_x = 350, gap_y = 0, minimum_width = 450, minimum_height = 450, draw_borders = false, use_xft = true, xftalpha = 0.8, uppercase = false, maximum_width = 1024, temperature_unit = "fahrenheit", } conky.text = [[ CPU Temp: Conky Builtin 1 3: ${hwmon 1 temp 3}°F Using hwmon: ${exec awk '{print ((($0 / 1000)*1.8)+32) }' < /sys/class/hwmon/hwmon1/temp3_input }°F # Temp of the die plus the Tctl offset for fan control Using sensors Tctl : ${exec sensors -f k10temp-pci-00c3 | grep Tctl | cut -b 15-21}F # Temp of the die itself Using sensors Tccd1: ${exec sensors -f k10temp-pci-00c3 | grep Tccd1 | cut -b 15-21}F Average CPU Frequency: ${exec cat /proc/cpuinfo |grep "cpu MHz"| awk '{sum+=$4;} END{printf "%2.2f", (sum/12)/1000;}'} GHz CPU1: ${freq_g 1} GHz ${goto 170}CPU1: ${exec awk '{printf "%2.2f", ($0)/1000000;}' conky to gather, and display my Linux system stats for a long time. I noticed over a decade ago that the 'average' cpu MHz just copies the first core, it isn't an average of all cores. The command to get the average cpu frequency in conky is: ${freq_g 0}. To get the cores individually, you just use ${freq_g 1} - ${freq_g 12}. In other words, 0 is supposed to be the average, not the first core, and individually, you start counting at 1, through how many cores you have. But 0 and 1 both always display the exact same thing. Checking in bash, I run this command: grep "cpu MHz" corectrl to control the cpu governor, and control the gpu. When I set the cpu to 'performance mode', the frequency of the cpu jumps up accordingly - from the low 2 GHz range, to the low 4 GHz range, as reported by conky. But when I check the output with the above grep command, all the cores are showing that they're running in the low to mid 3 GHz range. I'm not really expecting precision numbers here, just pretty close ballpark numbers. Or, in other words, I expect precision numbers, but they're going to change so many time per second that I expect them to be reported differently. The biggest problem I'm having is that my grep command rarely shows the cpu frequency going above 4 GHz, while conky rarely shows it below 4 GHz - in performance mode. Should I just display the outputs from my grep command in conky, and just accept the two outputs aren't going to jive? ---- I'm having a very similar issue with conky's built in cpu temperature detection. I can display what conky's builtin is reporting, and the results using sensors, and hwmon. The conky builtin is almost always showing the lowest temperature. The other two methods bounce around a lot more, and usually show higher temperatures then conky's builtin. And I mean they might show a ten degree difference, or more, for a long time.