Odroid-C4 Thermal Stress Tests

[hominoid]

Thermal tests were conducted with the Odorid-C4 on debian 10 kernel 4.9.218(@meveric’s image) and Ubuntu 20.04 kernel 5.7.0-RC4(@tobetter’s image). Both OS images are early release versions running on pre-release kernels. The same build of Cpuminer 1.4 for VRM was used to thermally stress both systems in benchmark mode with huge pages enabled.

Code: Select all

hominoid@odroid-c4:[~/veriumMiner]: ./cpuminer --version

 Verium Miner forked from cpuminer 1.4 {fireworm} by fireworm@github **
              credits to tpruvot et al. & effectsToCause et al. **

 built with GCC 9.3.0 the May  4 2020
 compiled for ARM NEON
 config features: ARMV8 NEON

libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3 jansson/2.12

All tests were conducted with an ambient air temperature between 71F(21.66C)-72F(22.22C) and Performance governor. The Odroid-C4 was tested in the OEM case with the top off. Since I don’t have a 12v SmartPower2, my bench power supply operating at 12v was used to determine power utilization as accurately as possible by multiple observations.
-
Odroid C4 1.8Ghz Test

Odroid-C4_1.8Ghz.png (172.28 KiB) Viewed 1787 times

Power usage for 1.8Ghz_debian_10_4.89.218+
12v @ .344A +-.025 4.13W
idle cool down .152A +-.002A 1.82W

Power usage for 1.8Ghz Ubuntu 20.04 5.7.0-RC4
12v @ .280A +-.025 3.36W (.321A-.260A, 3.85W-3.12W)
idle cool down .110A +-.004A 1.32W
-
Odroid C4 1.91Ghz Test

Odroid-C4_1.91Ghz.png (182.56 KiB) Viewed 1787 times

Power usage for 1.91Ghz debian 10 4.9.218+
12v @ .375A +-.25 4.5W (.401A-.346A, 4.81W-4.15W)
idle cool down .150A-.155A (1.8W-1.86W)

Power usage for 1.91Ghz Ubuntu 20.04 5.7.0-RC4
12v @ .305A +-.025 3.66W Typical(.340A-.270A, 4.08W-3.24W)
idle cool down .152A +-.002A 1.82W
-
Odroid C4 2.02Ghz Test

Odroid-C4_2.02Ghz.png (182.27 KiB) Viewed 1489 times

Power usage for 2.02Ghz debian 10 4.9.218+
12v @ .431A-.256A 5.17W-3.07W typical(.409A-.378A, 4.91W-4.54W @ 510H/m)
Throttling 1.8Ghz-1.9Ghz typical(3.58A-3.88A, 4.3W-4.66W @ 468H/m)

Power usage for 2.02Ghz Ubuntu 20.04 5.7.0-RC4
Ambient Temp 71F or 21.66C
Power 12v @ .375A +-.025 4.50W (.383A-.302A,4.6W-3.62W) (.409A-.323A,4.91W-3.88W) (.424A-.335A,5.09W-4.02W)
cool down .116A +-.003A 1.39W
-
Odroid C4 2.10Ghz Passive and Active Cooling Test

Odroid-C4_2.10Ghz.png (155.33 KiB) Viewed 1489 times

Power usage for 2.10Ghz Ubuntu 20.04 5.7.0-RC4 Passive Cooling
Ambient Temp 69F or 20.55C
Power 12v @ .375A +-.025 4.50W start(.398A-.320A,4.78W-3.843W) 4min(.397A-.355A,4.76W-4.26W) 20min(.462A-.366A,5.54W-4.39W) 24min(hang)
cool down .106A +-.002A 1.27W idle(.109A-.104A,1.31W-1.25W)

Power usage for 2.10Ghz Ubuntu 20.04 5.7.0-RC4 Active Cooling 40mm USB Fan
Ambient Temp 69F or 20.55C
Power 12v @ .375A +-.025 4.50W (.409A-.336A,4.91W-4.03W) (.397A-.355A,4.76W-4.26W) (.380A-.360A,4.56W-4.32W)
cool down with 40mm usb fan .140A +-.003A 1.68W No fan idle(.109A-.104A,1.31W-1.25W)

The passive 2.1Ghz Test on kernel 5.7.0-RC4 did not complete. A few minutes after the 20 minute power reading the system became unresponsive requiring a cold boot. I also ran an actively cooled test at 2.10Ghz using the same kernel and a 40mm USB fan. It completed with the temperature never exceeding 39C.

Summary
Kernel 5.7.0-RC4 consistently ran cooler, consumed less power and outperformed kernel 4.9.218+. Kernel 4.9.218+ also had some peculiar behavior as evident by the down clocking to 1Ghz right after the thermal load was stopped and the cool down period started. It should have held the set frequency like kernel 5.4.0-RC4. All tests on kernel 4.9.218+ exhibited this behavior.
The thermal and operational performance of the Odroid-C4 is very impressive. It delivers considerable processing power with low energy consumption. For this workload, it passively delivers slightly better performance then an actively cooled Odroid-XU4 while only using approximately 25-30% of the energy, and still runs considerably cooler. IMO, the thermal characteristics are on par with the Odroid-N2.

Test data files, gplot scripts and charts
[Update with aditional tests]

odroid-c4_vrm_tests.zip

(823.33 KiB) Downloaded 7 times

gplot script use: gnuplot -c script.gpl chart.png freq_data.csv hash_data.txt

e.g. gnuplot -c Test7_1.8Ghz_ubuntu_20.04_5.7.RC4.gpl Test7_1.8Ghz_ubuntu_20.04_5.7.RC4.png Test7_1.8Ghz_ubuntu_20.04_5.7.RC4.csv Test7_1.8Ghz_ubuntu_20.04_5.7.RC4.txt

[nl.smart]

Nice job, congratulation.

[rooted]

@hominoid Did you happen to notice any strangeness with the performance?

[hominoid]

The 5.7.0-RC4 kernel was very stable as far as I could tell. It performed consistently and as I would have expected. The 4.9.212 kernel was not as consistent as it should have been. You can see what I'm talking about by comparing the hash rate between the 1.91Ghz and 2.02Ghz tests. The 1.91Ghz test is wandering around at the beginning before it starts to throttle, the 2.02Ghz does not. These tests were run in benchmark mode so there is no stratum server or network to causes latency. There is also the drop to the minimum frequency when the load came off the cores during every test. If you look at the data It was oscillating between maximum and minimum frequency regardless of the temperature.

Code: Select all

2020-05-06 22:24:23,1.91,1.91,1.91,1.91,74,73
2020-05-06 22:24:25,1.91,1.91,1.91,1.91,74,73
2020-05-06 22:24:27,1.70,1.70,1.70,1.70,73,73
2020-05-06 22:24:29,1.91,1.91,1.91,1.91,67,68
2020-05-06 22:24:31,1.00,1.00,1.00,1.00,64,65
2020-05-06 22:24:33,1.00,1.00,1.00,1.00,63,64
2020-05-06 22:24:35,1.00,1.00,1.00,1.00,63,64
2020-05-06 22:24:37,1.00,1.00,1.00,1.00,63,64
2020-05-06 22:24:39,1.00,1.00,1.00,1.00,62,63
2020-05-06 22:24:41,1.00,1.00,1.00,1.00,62,63
2020-05-06 22:24:43,1.00,1.00,1.00,1.00,62,63
2020-05-06 22:24:45,1.00,1.00,1.00,1.00,62,63
2020-05-06 22:24:47,1.00,1.00,1.00,1.00,62,62
2020-05-06 22:24:49,1.91,1.91,1.91,1.91,62,63
2020-05-06 22:24:51,1.00,1.00,1.00,1.00,61,62
2020-05-06 22:24:53,1.00,1.00,1.00,1.00,61,62
2020-05-06 22:24:55,1.00,1.00,1.00,1.00,61,62
2020-05-06 22:24:57,1.91,1.91,1.91,1.91,61,62
2020-05-06 22:24:59,1.00,1.00,1.00,1.00,61,62
2020-05-06 22:25:01,1.00,1.00,1.00,1.00,60,61
2020-05-06 22:25:03,1.00,1.00,1.00,1.00,60,61
2020-05-06 22:25:05,1.91,1.91,1.91,1.91,61,62
2020-05-06 22:25:07,1.00,1.00,1.00,1.00,60,61
2020-05-06 22:25:09,1.91,1.91,1.91,1.91,60,61
2020-05-06 22:25:11,1.00,1.00,1.00,1.00,60,61
2020-05-06 22:25:13,1.00,1.00,1.00,1.00,60,61
2020-05-06 22:25:15,1.00,1.00,1.00,1.00,60,61
2020-05-06 22:25:17,1.91,1.91,1.91,1.91,60,61
2020-05-06 22:25:19,1.00,1.00,1.00,1.00,59,61
2020-05-06 22:25:21,1.91,1.91,1.91,1.91,60,60
2020-05-06 22:25:23,1.91,1.91,1.91,1.91,60,60
2020-05-06 22:25:25,1.91,1.91,1.91,1.91,59,60
2020-05-06 22:25:27,1.91,1.91,1.91,1.91,59,60
2020-05-06 22:25:29,1.91,1.91,1.91,1.91,59,60
2020-05-06 22:25:31,1.91,1.91,1.91,1.91,59,60
2020-05-06 22:25:33,1.91,1.91,1.91,1.91,59,60
2020-05-06 22:25:35,1.91,1.91,1.91,1.91,59,60
2020-05-06 22:25:37,1.91,1.91,1.91,1.91,59,59
2020-05-06 22:25:39,1.91,1.91,1.91,1.91,59,59
2020-05-06 22:25:41,1.91,1.91,1.91,1.91,59,59

On the 1.8Ghz test there are a couple of minor anomaly, a little variability in the beginning hash rate and at the end of the test. Like I mentioned in the OP, 4.9.218 ran hotter and consumed a considerable amount more power imo. With that said, the overall performance during these tests was about what I would have expected. For a reference I recently compiled the vrm cpuminer for the N2 and it did 547H/m without huge pages and 651H/m with transparent huge pages. The XU4 will do about 420-450 in a similar configuration. Keep in mind this is just running a thread on each core, so not necessarily the maximum hash rate once other optimizations are implemented. So the answer to your question is yes, but since these are pre-release kernels I wasn't expecting perfection either...just yet

[EDIT]
For what it's worth, this is a htop from the 2.02Ghz 4.9.218 Debian 10 test, Test2_2.02Ghz_debian_10_4.9.218+ in the attached data set. Unfortunately I don't have one for the 1.91Ghz test.

Odroid-C4_2.02Ghz_debian10_htop.png (166.7 KiB) Viewed 1640 times

[tobetter]

@hominoid, thank you for your great analysis and kindly request to test another CPU frequencies with the 5.7.0-rc4 kernel.

I've attached two DTB files to enable CPU frequencies up to 2.016GHz and 2.100GHz with Linux kernel 5.7-rc4. You can simply replace a DTB file to /boot/dtbs/5.7.0-odroid-arm64/meson64_odroidc4.dtb. With the 2.016GHz DTB, ODROID-C4 would be stable...I think...while 2.100GHz DTB would be not. I've observed that many ODROID-C4 just hanged with 2.100GHz + 'performance' CPU governor in 4.9 kernel.

This is the change regarding the CPU frequencies with the attached DTB, it may need to tune the voltages.

Code: Select all

diff --git a/arch/arm64/boot/dts/amlogic/meson64_odroidc4.dts b/arch/arm64/boot/dts/amlogic/meson64_odroidc4.dts
index 9b2c191620b9..b52eff354153 100644
--- a/arch/arm64/boot/dts/amlogic/meson64_odroidc4.dts
+++ b/arch/arm64/boot/dts/amlogic/meson64_odroidc4.dts
@@ -10,3 +10,14 @@
 / {
        model = "Hardkernel ODROID-C4";
 };
+
+&cpu_opp_table {
+       opp-2016000000 {
+               opp-hz = /bits/ 64 <2016000000>;
+               opp-microvolt = <1000000>;
+       };
+       opp-2100000000 {
+               opp-hz = /bits/ 64 <2100000000>;
+               opp-microvolt = <1022000>;
+       };
+};

[hominoid]

Looking good so far!

Code: Select all

hominoid@odroid-c4:[~]: uname -a
Linux odroid-c4 5.7.0-odroid-arm64 #1 SMP PREEMPT Ubuntu 5.7.0-rc4-202005041714~focal (2020-05-04) aarch64 aarch64 aarch64 GNU/Linux
hominoid@odroid-c4:[~]: odroid-cpu-control -l
CPU0: governor ondemand	current 2.10GHz	min 1.00GHz [100.00MHz]	max 2.10GHz [2.10GHz] 	
CPU1: governor ondemand	current 2.10GHz	min 1.00GHz [100.00MHz]	max 2.10GHz [2.10GHz] 	
CPU2: governor ondemand	current 2.10GHz	min 1.00GHz [100.00MHz]	max 2.10GHz [2.10GHz] 	
CPU3: governor ondemand	current 2.10GHz	min 1.00GHz [100.00MHz]	max 2.10GHz [2.10GHz] 	

[rooted]

What is the hash rate of the C4?

[hominoid]

I ran the 5.7.0-RC4 2.02Ghz last night and got around 504 H/m, and 1.91Ghz was at about 472 H/m. I'll be running the 2.1Ghz this morning. I'll post charts and the data a little later today.

[rooted]

I use performance when testing, like to take the governor out of the equation.

It's hard to believe the C4 outperforms the XU4 in mining, it's certainly slow compiling the kernel. Wonder why it does well at some tasks but poorly at others.

[hominoid]

I use performance when testing, like to take the governor out of the equation.

It's hard to believe the C4 outperforms the XU4 in mining, it's certainly slow compiling the kernel. Wonder why it does well at some tasks but poorly at others.

I used a performance governor for all tests. I'm only answering because that is not my question in my post. I hope it was @tobetter or one of the other moderators. I don't think my account was hacked.

What is really great for the C4 is that it does it at such low power. I think my estimates above in the 25%-30% power of an XU4 are going to be real close. It also comes really close at 2.02Ghz to the performance of 531H/m of the N1. I suspect that the performance differences between different workloads is related to in order vs out of order designs as mentioned in the other thread. As always, test your specific use and don't make assumptions based on clock speed or other criteria without verification of performance.

[tobetter]

I use performance when testing, like to take the governor out of the equation.

It's hard to believe the C4 outperforms the XU4 in mining, it's certainly slow compiling the kernel. Wonder why it does well at some tasks but poorly at others.

I used a performance governor for all tests. I'm only answering because that is not my question in my post. I hope it was @tobetter or one of the other moderators. I don't think my account was hacked.

What is really great for the C4 is that it does it at such low power. I think my estimates above in the 25%-30% power of an XU4 are going to be real close. It also comes really close at 2.02Ghz to the performance of 531H/m of the N1. I suspect that it is related to in order vs out of order designs as mentioned in the other thread. As always, test your specific use and don't make assumptions based on clock speed or other criteria without verification of performance.

Sorry, @hominoid...I realize that I've edited your post by mistake since I've changed my permission in the forum. Your account is not hacked. Really sorry about that.

@rooted, sorry to make a confusion.

[hominoid]

No problem, because of the question I thought it was you. @rooted wasn't aware of what transpired so I was just bring it to his attention. Very nice on the 2.02Ghz kernel 5.7 test and I'll take 2.1Ghz actively cooled as well.

[tobetter]

No problem, because of the question I thought it was you. @rooted wasn't aware of what transpired so I was just bring it to his attention. Very nice on the 2.02Ghz kernel 5.7 test and I'll take 2.1Ghz actively cooled as well.

Thanks. For sure, running at 2.02GHz on ODROID-C4 would be fine although thermal throttling happens. I am considering to merge the patch to support 2.0/2.1GHz, but concerning some board would not boot or hang with 2.1GHz.

[hominoid]

I was going to ask you to consider at least the 2.02Ghz with the default set to 1.91Ghz on boot; would be my preference. As long as it is posted that 2.1Ghz is for the silicon lottery winners with active cooling and the daring who live on the edge; I would consider making it available too.

[hominoid]

For comparison, here is a XU4Q running the cpuminer test in a similar configuration as the C4 tests.
Ubuntu 18.04 kernel 5.4.3, performance governor, in the case bottom with no case top, 40mm USB Fan. A SmartPower2 was used to capture energy usage.

Cpuminer ran with a single 1-way thread on all 8 cores. The 1.9Ghz test ran about 423H/m before throttling and 1.8Ghz was sustainable at 400H/m even though it faded towards the end of the test. It averaged about 12+ watts which gives the XU4 a 33.33 hash per watt efficiency. The Odroid C4 produced 461H/m using approximately 3.36 watts at 1.8Ghz for 137.2 hash per watt or more than 4 times as many hash per watt than the XU4 in this example.
.

C4vsXU4.png (375.16 KiB) Viewed 1006 times

odroid-xu4_test_data.zip

(355.47 KiB) Downloaded 1 time

[odroid]

Nice conclusion. 33 hash per watt vs 137 hash per watt
C4 has four times higher energy efficiency.

[hami]

What thermal throttle value is set up in the kernel 5.7.0.rc (Ubuntu 20.04), if it is set up? Must be higher then 75 degC in kernel 4.9.(debian buster) as nicely seen in the test for 2 GHz.

[tobetter]

What thermal throttle value is set up in the kernel 5.7.0.rc (Ubuntu 20.04), if it is set up? Must be higher then 75 degC in kernel 4.9.(debian buster) as nicely seen in the test for 2 GHz.

Where did you get the kernel for Debian Buster? @meveric or Armbian?

[hami]

What thermal throttle value is set up in the kernel 5.7.0.rc (Ubuntu 20.04), if it is set up? Must be higher then 75 degC in kernel 4.9.(debian buster) as nicely seen in the test for 2 GHz.

Where did you get the kernel for Debian Buster? @meveric or Armbian?

Me, nowhere. I just reacted on the results of the first post (viewtopic.php?p=291720#p291720), where is mentioned @meveric’s image (uses HK LTS kernel - and HK mentioned thermal throttling point on the page https://www.hardkernel.com/shop/odroid-c4/).

[tobetter]

What thermal throttle value is set up in the kernel 5.7.0.rc (Ubuntu 20.04), if it is set up? Must be higher then 75 degC in kernel 4.9.(debian buster) as nicely seen in the test for 2 GHz.

Where did you get the kernel for Debian Buster? @meveric or Armbian?

Me, nowhere. I just reacted on the results of the first post (viewtopic.php?p=291720#p291720), where is mentioned @meveric’s image (uses HK LTS kernel - and HK mentioned thermal throttling point on the page https://www.hardkernel.com/shop/odroid-c4/).

I see...I was just curious since there are many kernel variants.

[hominoid]

What thermal throttle value is set up in the kernel 5.7.0.rc (Ubuntu 20.04), if it is set up? Must be higher then 75 degC in kernel 4.9.(debian buster) as nicely seen in the test for 2 GHz.

Looking at the 2.1Ghz passive test I assumed it to be 80C but I do not know for sure.

[tobetter]

What thermal throttle value is set up in the kernel 5.7.0.rc (Ubuntu 20.04), if it is set up? Must be higher then 75 degC in kernel 4.9.(debian buster) as nicely seen in the test for 2 GHz.

Looking at the 2.1Ghz passive test I assumed it to be 80C but I do not know for sure.

New kernel 5.7-rc5 package with additional CPU frequencies are uploaded.
viewtopic.php?f=202&t=38557&p=292091#p292091

EDIT: I wonder this change affect your result.
https://github.com/tobetter/linux/commi ... 962499R289

[hominoid]

EDIT: I wonder this change affect your result.
https://github.com/tobetter/linux/commi ... 962499R289

It looks like it would for the 2.02Ghz and 2.1Ghz tests but it won't when I change it.

[tobetter]

EDIT: I wonder this change affect your result.
https://github.com/tobetter/linux/commi ... 962499R289

It looks like it would for the 2.02Ghz and 2.1Ghz tests but it won't when I change it.

So when are you going to check if you are a sillicon lottery winner? Wish you are not waiting for another patch for 2.2.

[hominoid]

So when are you going to check if you are a sillicon lottery winner? Wish you are not waiting for another patch for 2.2.

I was actually left wondering how the Odroid-C2 would compare after looking at the Odroid-XU4Q so I setup a similar test for the C2.

Armbian-Debian 10 kernel 5.4.38, performance governor, in the case with no case top, passive, ambient temp 70F(21.11C), a SmartPower2 to capture energy usage.

The Odroid-C2 running at 1.54Ghz averaged 359H/m at 5 watts which gives the C2 a 71.8 hash per watt efficiency. The Odroid C4 produced 397H/m using approximately 2.71 watts at 1.50Ghz for 146.49 hash per watt or 2 times as many hash per watt then the C2. That's a nice improvement while running much cooler.
.

C4vsC2.png (240.99 KiB) Viewed 1156 times

odroid-c2_test_data.zip

(223.98 KiB) Downloaded 1 time

[hexdump]

with what optimizations is your test compiled - generic armv8 or optimized for cortex-a55? i'm asking as i have seen situations (vcvrack software modular synthesizer, so mostly dsp code running on the cpu compiled for a53) where the performance of a s905x3 at 1.9ghz was worse than the performance of a s905x2 at 1.8ghz and both were not much better than an odroid c2 (s905) at 1.5ghz - so maybe in some situations compiling for the a55 might help to unleash more potential of the s905x3 as the cpu design seems to be slightly different? but maybe your code mostly uses neon where i'm not sure how much of an effect this has.

best wishes - hexdump

[hominoid]

It was compiled for generic Armv8. I have not noticed much if any difference in past testing with this workload while using other optimizations.

[back2future]

Thx for this insight. From a scientific point of view it would be very interesting how an energy saving platform (especially on varying load/demand/environment situation) based on x64 like the Odroid H2 compares to this in hash per watt?
Me guessing mining on full-time top performance level is one task where ARM socs outperform x64 considering performance/energy_input (and likewise maybe video en-/decoding on newer internal G31 gpu)?

It's unexpected that there is not recognizable increase in hash performance between 1.8 and 1.91GHz on 20.04, but around 0.3W (0.5W) higher power input.

[hominoid]

Thx for this insight. From a scientific point of view it would be very interesting how an energy saving platform (especially on varying load/demand/environment situation) based on x64 like the Odroid H2 compares to this in hash per watt?

Odroid-H2 in a similar setup at 1.90Ghz and 1.5Ghz, Ubuntu 18.04 kernel 5.7.0-rc6+, performance governor and passive cooling. Even though the governor was set to performance, it behaved like the ondemand governor for some reason.

Code: Select all

hominoid@odroid-h2:~/veriumMiner$ ./cpuminer --version

 Verium Miner forked from cpuminer 1.4 {fireworm} by fireworm@github **
              credits to tpruvot et al. & effectsToCause et al. **

 built with GCC 7.5.0 the May 24 2020
 compiled for x64
 config features: x86_64 SSE2 XOP AVX AVX2

libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
jansson/2.11 

.

odroid-h2.png (219.79 KiB) Viewed 403 times

.
Odroid-H2 Ubuntu 18.04 5.7.0-rc6+ @ 1.90Ghz
Ambient Temp 75F or 23.88C
Power 15v @ .652A +-.025 9.7875W
idle(.218A-.204A,3.27W-3.06W)
3Min(.715A-.595A,10.725W-8.925W)
30Min(.705A-.602A,10.575W-9.03W)
60Min(.710A-.605A,10.65W-9.075W)
cool down .217A +-.0025A 3.255W (.222A-.211A,3.33W-3.16W)

701H/m @ 9.7875W = 71.62H/watt @ 1.90Ghz

Odroid-H2 Ubuntu 18.04 5.7.0-rc6+ @ 1.50Ghz
Ambient Temp 75F or 23.88C
Power 15v @ .545A +-.025 8.175W
idle(.214A-.203A,3.21W-3.04W)
3Min(.574A-.500A,8.61W-7.5W)
30Min(.586A-.509A,8.79W-7.635W)
60Min(.575A-.509A,8.625W-7.635W)
cool down .215A +-.0005A 3.225W (.220A-.209A,3.3W-3.135W)

576H/m @ 8.175W = 70.46H/watt @ 1.5Ghz
.

odroid-h2_test_data.zip

(246.03 KiB) Downloaded 3 times

[back2future]

[ Thx, seems Xu4 active cooling device, about 4.4K/W (53K/12W), and
H2's passive heat sink, about 4.6K/W (45K/9.78W), share almost comparable heat transfers capabilities (from sensor) to ambient.
(Soldered) C4 seems having a 7.99°C/W 'Package junction-to-pcb thermal resistance in nature convection', ranging (passive to actively supported convection) between 12.3-3.3K/W.
N2 levels out at about 7.17K/W (38K/5.3W). ]