Ιntel(R) Celeron(R) N4500

[lampra1]

| Intel(R) Celeron(R) N4500 @ 1.10GHz | 2800/2800 MHz | 5.13 | Impish x86_64/amd64 | 5810 | 675730 | 783850 | 8120 | 8340 | - | http://ix.io/3HKQ |

[ThomasKaiser]

Thank you. The output is a little bit surprising. Can you please provide results of the following (as root of course):

cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
cat /sys/devices/system/cpu/cpufreq/policy1/scaling_available_frequencies
ls -laR /sys/devices/system/cpu/cpufreq/policy0

I need to prepare v0.8.8 to address this. And it would be great if you can lower your temperatures a little bit since I would like to add results made with v0.8.8 then. If /usr/sbin/powertop --auto-tune won't do the job at least some ventilation cooling down the enclosure?

[lampra1]

It seems that there are only two frequencies. When v0.8.8 is available, please let me know, and I will run the test. I will try powertop --auto-tune or some "homemade" cooling solution.

root@brix:~# ls -laR /sys/devices/system/cpu/cpufreq/policy0
/sys/devices/system/cpu/cpufreq/policy0:
total 0

drwxr-xr-x 2 root root    0 Δεκ  12 00:02 .
drwxr-xr-x 4 root root    0 Δεκ  12 00:02 ..
-r--r--r-- 1 root root 4096 Δεκ  12 12:27 affected_cpus
-r--r--r-- 1 root root 4096 Δεκ  12 12:27 base_frequency
-r--r--r-- 1 root root 4096 Δεκ  12 00:02 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Δεκ  12 00:02 cpuinfo_min_freq
-r--r--r-- 1 root root 4096 Δεκ  12 12:27 cpuinfo_transition_latency
-r--r--r-- 1 root root 4096 Δεκ  12 12:27 energy_performance_available_preferences
-rw-r--r-- 1 root root 4096 Δεκ  11 22:05 energy_performance_preference
-r--r--r-- 1 root root 4096 Δεκ  12 12:27 related_cpus
-r--r--r-- 1 root root 4096 Δεκ  12 12:27 scaling_available_governors
-r--r--r-- 1 root root 4096 Δεκ  12 00:02 scaling_cur_freq
-r--r--r-- 1 root root 4096 Δεκ  12 12:27 scaling_driver
-rw-r--r-- 1 root root 4096 Δεκ  12 00:11 scaling_governor
-rw-r--r-- 1 root root 4096 Δεκ  12 00:11 scaling_max_freq
-rw-r--r-- 1 root root 4096 Δεκ  12 00:11 scaling_min_freq
-rw-r--r-- 1 root root 4096 Δεκ  12 12:27 scaling_setspeed
root@brix:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies: No such file or directory
root@brix:~# cat /sys/devices/system/cpu/cpufreq/policy1/scaling_available_frequencies
cat: /sys/devices/system/cpu/cpufreq/policy1/scaling_available_frequencies: No such file or directory
root@brix:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor 
powersave
root@brix:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq 
800000
root@brix:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 
2800000
root@brix:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed 
<unsupported>

[ThomasKaiser]

Thank you, now I see. It's all about Intel P-States and as such scaling_available_frequencies is missing.

I prepared v0.8.8 already but I'll look a bit deeper into (and try to do a kernel update to be able to test around) since it's worth the efforts to include this stuff into output.

[ThomasKaiser]

Here we go: https://github.com/ThomasKaiser/sbc-bench/commit/004fa59ebeeb15dc945836edc535f0792aa0503c

I did not manage to get Intel P-States working on our N5100 (neither intel_pstate=hwp_broken_firmware nor intel_pstate=active in kernel cmdline did the trick). Need to talk to the colleague who is near the PC from time to time since he's the one fiddling around in UEFI settings if needed.

[lampra1]

For these results, I used an external fan. Let me know if the latest stable kernel 5.15.7 is suitable for the test. If so, I will install it and provide results.

| Intel(R) Celeron(R) N4500 @ 1.10GHz | 2800/2800 MHz MHz | 5.13 | Impish x86_64/amd64 | 6270 | 673840 | 783600 | 8160 | 8380 | - | http://ix.io/3HTp |

[ThomasKaiser]

Kernel doesn't really matter. But based on the memory performance I would assume you have 2 DIMMs in the Brix? Anyway, I just commited a new version that should also report DIMM information if present. Looks like this for my single channel N5100:

Locator: Controller0-ChannelA
Bank Locator: BANK 0
Type: DDR4
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Volatile Size: 8 GB
Locator: Controller0-ChannelB-DIMM0
Bank Locator: BANK 1
Type: Unknown
Speed: Unknown
Configured Memory Speed: Unknown
Volatile Size: None

(will be appended to bottom of results). Would be great if you can give the new version a try since comparing N4500 with N5100 is really interesting wrt memory config / performance.

[lampra1]

This is one so-dimm (KINGSTON KF429S17IB/8 FURY IMPACT 8GB SO-DIMM DDR4 2933MHZ) on the one available bank. Info provided below. I will re-run the script later tonight, and I will provide the results here.

root@brix:~# dmidecode -t memory
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x003C, DMI type 16, 23 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: None
    Maximum Capacity: 16 GB
    Error Information Handle: Not Provided
    Number Of Devices: 1

Handle 0x0048, DMI type 17, 100 bytes
Memory Device
    Array Handle: 0x003C
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 8 GB
    Form Factor: SODIMM
    Set: None
    Locator: Controller0-ChannelA
    Bank Locator: BANK 0
    Type: DDR4
    Type Detail: Synchronous
    Speed: 2933 MT/s
    Manufacturer: Kingston
    Serial Number: XXXXXXXX
    Asset Tag: XXXXXXXXXX
    Part Number: KF2933C17S4/8G      
    Rank: 1
    Configured Memory Speed: 2933 MT/s
    Minimum Voltage: 1.2 V
    Maximum Voltage: 1.2 V
    Configured Voltage: 1.2 V
    Memory Technology: DRAM
    Memory Operating Mode Capability: Volatile memory
    Firmware Version: Not Specified
    Module Manufacturer ID: Bank 2, Hex 0x98
    Module Product ID: Unknown
    Memory Subsystem Controller Manufacturer ID: Unknown
    Memory Subsystem Controller Product ID: Unknown
    Non-Volatile Size: None
    Volatile Size: 8 GB
    Cache Size: None
    Logical Size: None

[lampra1]

Again, results using external fan:

| Intel(R) Celeron(R) N4500 @ 1.10GHz | 2800/2800 MHz | 5.13 | Impish x86_64/amd64 | 6300 | 663550 | 783840 | 8100 | 8350 | - | http://ix.io/3HUU |

[ThomasKaiser]

I added the last result to the list. What's a bit troubling with your box are the configured/real thermals. Prior to the benchmark it reads

Package id 0:  +50.0 C  (high = +105.0 C, crit = +105.0 C)

And the 1st trip point to reduce clockspeeds seems to be already at 55°C. In your case I would try to find the relevant settings and relax trip point configuration a bit.

[ThomasKaiser]

BTW: I'm still wondering why our Jasper Lake box doesn't support intel_pstate driver. We changed a bit in UEFI settings and maybe that's the culprit:

Can you please show your UEFI settings? UEFI Vendor string is different but since it's same "BIOS version" I would assume our "ASUS UEFI" is just a rebranded AMI...

[lampra1]

Will do later this afternoon.

And the 1st trip point to reduce clockspeeds seems to be already at 55°C. In your case I would try to find the relevant settings and relax trip point configuration a bit.

Any pointers on how to find these settings?

[ThomasKaiser]

Any pointers on how to find these settings?

Unfortunately not. I'm pretty much clueless when it comes to running Linux w/o a virtualization layer on x86 (I spent too much time on ARM with Linux close to hardware within the last decade).

Yesterday I stumbled accross throttled which might have some pointers (like trying to disable/mask thermald) but haven't looked into it deeply so all I could provide are my usual 'brute force' attempts when exploring such stuff:

find /sys -name "*trip*"
find /sys -name "*thermal*"

(and so on).

[lampra1]

Can you please show your UEFI settings?

I am not really familiar with intel terminology, so here are two photos. Is this what you needed? First the menu Second the cpu submenu. All options are either enabled or disabled

[lampra1]

find /sys -name "*trip*"

I will probably do some tests one day with these trip points:

root@brix:~# find /sys -name "*trip*"
/sys/kernel/tracing/events/thermal/thermal_zone_trip
/sys/kernel/debug/tracing/events/thermal/thermal_zone_trip
/sys/devices/virtual/thermal/thermal_zone0/trip_point_5_temp
/sys/devices/virtual/thermal/thermal_zone0/cdev2_trip_point
/sys/devices/virtual/thermal/thermal_zone0/trip_point_3_type
/sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_2_type
/sys/devices/virtual/thermal/thermal_zone0/cdev0_trip_point
/sys/devices/virtual/thermal/thermal_zone0/trip_point_3_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_1_type
/sys/devices/virtual/thermal/thermal_zone0/cdev3_trip_point
/sys/devices/virtual/thermal/thermal_zone0/trip_point_2_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_0_type
/sys/devices/virtual/thermal/thermal_zone0/cdev1_trip_point
/sys/devices/virtual/thermal/thermal_zone0/trip_point_1_temp
/sys/devices/virtual/thermal/thermal_zone0/trip_point_5_type
/sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp
/sys/devices/virtual/thermal/thermal_zone0/cdev4_trip_point
/sys/devices/virtual/thermal/thermal_zone0/trip_point_4_type
/sys/devices/virtual/thermal/thermal_zone1/trip_point_1_type
/sys/devices/virtual/thermal/thermal_zone1/trip_point_0_type
/sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp
/sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp
root@brix:~# cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp
119000
root@brix:~# cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_1_temp
71000
root@brix:~# cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_2_temp
55000
root@brix:~# cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_3_temp
50000
root@brix:~# cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp
45000
root@brix:~# cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_5_temp
40000

[ThomasKaiser]

BTW: today we did an UEFI update from 0802 to 0803. Now C and P states are working out of the box: Intel P-state driver initializing, HWP enabled.

Performance remains the same while idle consumption of the whole box (PSU included) dropped from slightly above 3.4W to slightly below 2.4W. :)