Further Exploring The Intel Tiger Lake Core i7-1165G7 Performance On Ubuntu Linux

[birdie]

M@GOid you should definitely join forces with Volta as this would be quite a company. He even said I'd stolen a message from LKML and turned it into a bug report. I would love to know what he's talking about. Perhaps he could tell this himself as he's continuously insluting me, calling me an NVIDIA/Microsoft/proproprietary software fan - perhaps he knows me better than I do. It's funny to hear considering I don't remember the last time I used Windows.

[Clive McCarthy]

The compute performance data is interesting, but this is a laptop. It has limited screen space but folds up nicely. It isn't BIG IRON. Many of the benchmark tests seem pertinent for serious workstations but not for any dinky laptop. We know that Torvalds has moved to an AMD based workstation. Video rendering clearly benefits from multi-threading. But a laptop isn't a workstation.

Games on a cheap laptop? -- fine, for budget conscious gamers. Email & web browsing, is trivial. Battery life is vital.

Horses for courses.

[Guest]

The results aren't 'wrong' at all, that is the performance currently seen on Ubuntu 20.04 LTS as found when installing Ubuntu 20.04 LTS or even out-of-the-box with Dell's own system image.

Can you set all schedulers to performance, and disable thermald? thermald's aim is to keep operating temperature low and comfortable, so of course it's going to hamper performance. Yes I know Ubuntu's default is to keep it on, but then they're aiming to make it work well for normal users who don't know much about hardware and software.

We can't get an actual comparison between CPUs, with stuff like that in the way.

[arQon]

That's a pretty huge change in the power cap, with obvious results, regardless of the exact piece not being pinned down yet.

the MT degredation is odd, but not unheard of, and again looks like a (full-die) power cap: it's just surprising that it ends up as a couple hundred MHz lower than before rather than a couple hundred higher.

[M@GOid]

I won't reply to your posts any longer because you chose to insult me.

Your word means nothing to me, since you broke it shortly after posting this

Also, we wish we could include you and a selected few other extraordinaires on a block list, but unfortunately that forum function isn't working, so every new post of yours is the forever question of "what Birdie is bellyaching now...".

Want a piece of advice kid? If you want to have normal conversations with other people on the forum, change the attitude of your posts. Every single one is a complain about some random thing. You love complaining so much, that when you don't find something to complain about, you start to making stuff up, like some child searching for attention. And that is when you got yourself on these useless forum fights, where people shows why you are wrong and wishing you are not here, doing nothing but trash talking in the discussion. Remember, is never too late to change yourself.

[schmidtbag]

Remember, is never too late to change yourself.

People who are quick ridicule everything but themselves are the least likely to change.

[nuhamind2]

Looking closely now, I came into conclusion that the MT perf regression is caused by the mismatch between boosting strategy and the workload time. If , say, the MT benchmark is short that it can be finished on one boost period, then I believe 20.10 will show better result than 20.04. Thus, to extract maximum MT performance, if the task took long time, the cpu should be set to run at certain frequency that is kept relatively constant for the duration of the task.

[random_engineer]

The power/performance and thermals are related to intel-RAPL, which is a firmware-based thermal mgmt strategy/system.

Archwiki for the previous spec of this laptop calls out using a tool called 'throttled':

https://wiki.archlinux.org/index.php/Dell_XPS_13_(9300)#Power_Management

Throttled doesn't have support for this CPU (yet, I'm looking into it), there is a 'static workaround' that works for some laptops. The distinction is whether or not the EC overrites these values often or not. It appears it does not on the 9310 (from my testing).

You can find the static workaround here:

https://github.com/erpalma/throttled#static-fix

WARNING: if you use the default settings, your CPU will consume 44W, which will make it hit 100*C very quickly and overall cause way too much heat.

Instead, change all '44000000' to '28000000' - which is 28 Watts, which is the 'TDP-up' TDP of this CPU (https://ark.intel.com/content/www/us...-with-ipu.html)
My laptop maxed out at about 88*C, which is acceptable to me in a laptop.

I like to use 's-tui' (as mentioned in the throttled README), it makes the relationships between power/temp/CPU Freq very apparent.

I just tested the kernel build, but my result is here:

https://openbenchmarking.org/result/2011016-FI-KBUILDTHR34

I got 186.4 seconds, compare this to the other tested configurations:

https://www.phoronix.com/scan.php?page=article&item=intel-tigerlake-linux&num=4

and

https://www.phoronix.com/scan.php?page=article&item=intel-weekend-tiger&num=3

I noticed there was a new TGL laptop showing up at openbenchmark.org: https://openbenchmarking.org/result/...FI-GALP5INTE08
It's score is 168 on the 5.4 kernel build test. It seems better configured out of the box.

A selection of results (I ran in 20.10, other results are from 20.04)
Kernel 5.4 compile time (seconds, less is better):
Ryzen 7 4700U : 161.50
'fixed' i7-1165g7 : 186.4
Ryzen 5 5600U : 200.77
Default i7-1165g7 : 209.92

Here's what I used to get the 186.4 result (This isn't done yet, you may not need to modify all these values):
#!/bin/bash
echo "Applying Fix..."
# MSR
# PL1
echo 28000000 | sudo tee /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw # 28 watt
echo 28000000 | sudo tee /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_time_window_us # 28 sec
# PL2
echo 28000000 | sudo tee /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_1_power_limit_uw # 44 watt
echo 2440 | sudo tee /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_1_time_window_us # 0.00244 sec

# MCHBAR
# PL1
echo 28000000 | sudo tee /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_0_power_limit_uw # 44 watt
# ^ Only required change on a ASUS Zenbook UX430UNR
echo 28000000 | sudo tee /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_0_time_window_us # 28 sec
# PL2
echo 28000000 | sudo tee /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_1_power_limit_uw # 44 watt
echo 2440 | sudo tee /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_1_time_window_us # 0.00244 sec
echo "done!"

[random_engineer]

I couldn't figure out how to edit my last post - but I have more data.

Comparing thermald master to what comes stock on Ubuntu 20.10:
Stock:

https://openbenchmarking.org/result/2011028-FI-KBUILDTHE80

2 runs on master (heat soaked for the slower run):

https://openbenchmarking.org/result/2011021-FI-KBUILDTHE08

I cloned the master branch for thermald, and launched it:
sudo systemctl stop thermald
sudo ./thermald --no-daemon --dbus-enable --adaptive

Then re-ran the benchmark for the results above. The new thermald allows the CPU to jump to 100*C, and pulls power much less aggressively.
It also doesn't show the behavior of the stock thermald: Limiting the SOC to 15W after an initial 'surge'.

It looks like a thermald update may help this.