Repository navigation
SB3: system total power limit at 25 watts, including display backlight #117
Description
This is observed by using s-tui to continuously monitor the power consumption, core frequency and utilization while compiling the kernel.
Running a "cold start", the system power peaks at 40 watts, and then drops to 25 watts (could be a thermal trip point, or a "long time power limit"?), where the CPU package draws 16 watts, resulting in all-core frequency at 1.6GHz. Core temperature stabilizes at 71C.
Curiously, I lowered the screen brightness to 5%, and the CPU package starts to draw more power (20+ watts) and all-core frequency goes up to 2.0GHz. Core temperature stabilizes at 78C.
So this does not solely look like a thermal throttle -- but where does that 25W limit come from?
Activity
qzed commentedon Feb 18, 2022
Could be some total system limit for sustained power imposed by firmware. Did you try changing the performance mode?
yatli commentedon Feb 18, 2022
I don't have "performance mode" -- there's no
/sys/bus/surface_aggregator/devices/01:03:01:00:01/perf_mode.I did try all the profiles -- no difference it seems.
qzed commentedon Feb 18, 2022
Yeah sorry, meant platform profiles (those and performance modes are the same).
yatli commentedon Feb 18, 2022
Edit: see below.
After some more experiment with a stress tool I find it's thermal-related and not bound to a sustained loaded time. The peak power could sustain for 2 seconds, 5 seconds and so on.And the power limit kicks in when the core goes over 90C degrees.I'll see if I can work out a thermald configuration for this model.
yatli commentedon Feb 18, 2022
Just feel this is funny that I should share the story with you guys :D
yatli commentedon Feb 18, 2022
Have to reopen this because thermald/rapl is not effective against this problem. It's like a power budget, not thermal throttle -- the same 25 watts can well push the core to 80C (dimmed screen) but a thermal limit at 70C (like ~20 watts in total) already triggers the power limit!
yatli commentedon Feb 18, 2022
btw, the fan is not as fast (loud) as in Windows. A profile configuration issue?
yatli commentedon Feb 18, 2022
So, is there a way I can intercept SAM messages under windows?
qzed commentedon Feb 18, 2022
AFAIK the fan is entirely controlled by SAM, and the only influence we or Windows can have on that is the platform profile/performance mode. Try setting that to "best performance".
Yes, although it requires a bit of configuration and the dumps are not easily readable (you're of course welcome to write a better parser for that). There's an overview on how to do that here: https://github.com/linux-surface/surface-aggregator-module/wiki/Development. A script for transforming the output into json files is here. Documentation on the commands we know so far is here. An overall documentation on the protocol can be found at https://www.kernel.org/doc/html/latest/driver-api/surface_aggregator/ssh.html.
yatli commentedon Feb 18, 2022
Here are the two related entries when I toggle between Better Performance vs. Best Performance:
{"ctrl": {"type": 128, "len": 12, "pad": 0, "seq": 42}, "cmd": {"type": 128, "tc": 3, "outgoing": 1, "incoming": 0, "iid": 0, "rqid_lo": 83, "rqid_hi": 3, "cid": 3}, "payload": [3, 0, 0, 0]} {"ctrl": {"type": 128, "len": 12, "pad": 0, "seq": 46}, "cmd": {"type": 128, "tc": 3, "outgoing": 1, "incoming": 0, "iid": 0, "rqid_lo": 87, "rqid_hi": 3, "cid": 3}, "payload": [4, 0, 0, 0]}...which matches the documented values.
le32 though?
yatli commentedon Feb 18, 2022
Just checked the module. le32 indeed no problem.
qzed commentedon Feb 18, 2022
Yeah, le32 is correct.
qzed commentedon Feb 18, 2022
All multi-byte values in the protocol are little-endian.
38 remaining items
qzed commentedon Mar 11, 2022
Well, as far as I can tell there's no way to control the fans other than setting the profile, which controls the fan curve. At least on my SB2, the dGPU fan behaves similarly with the profiles. Did you monitor temperatures when comparing by any chance?
yatli commentedon Mar 11, 2022
Yeah I keep s-tui around for monitoring temperature -- not as good as ThrottleStop on Windows though because I don't see hardware throttle "reasons".
On turbo max, it ramps up quickly to 100C. Then the power limit kicks in, temperature drops back to 80C.
Depending on the cooling capacity (determined by fan speed), the temperature will then either go up or down.
yatli commentedon Mar 22, 2022
Update -- I'm seeing another kind of throttling.
Yesterday I put it in sleep-then-hibernate but the battery is drained to 0%.
On boot today, I see very slow screen update in GRUB, and when the system boots up, I see the cores are throttled down to 200MHz, BAT at 0%.
Interestingly, as BAT goes up (lucky it still does!), the throttling decreases. Now I'm at BAT=18% and the throttling goes up to 900MHz all core.
That reminds me of the "original theory" you had -- it doesn't think it's plugged in so it schedules power limits as if it's on battery.
qzed commentedon Apr 28, 2022
I wonder if something similar can also be observed on other non-Surface devices. Could be some Intel related thing?
fsdax: force clear dirty mark if CoW
fsdax: force clear dirty mark if CoW
net: stmmac: remove unneeded stmmac_poll_controller
net: stmmac: remove unneeded stmmac_poll_controller
wifi: wilc1000: prevent use-after-free on vif when cleaning up all in…
ksmbd: validate ipc response length before dereferencing its fields
ksmbd: validate ipc response length before dereferencing its fields
Merge branch 'bpf-arm64-fix-the-exception-callback-s-frame-pointer'
ksmbd: validate ipc response length before dereferencing its fields
ksmbd: validate ipc response length before dereferencing its fields