Mac mini M2 (base) inconsistent performance

[Rodeo314]

HandBrake 1.7.2 official build.

Just got a brand new entry-level M2 Mac mini, and getting intermittently (but frequent) abysmal performance.

Code: Select all

for run in 1 2 3 4 5 6 7 8 9; do for src in ToS-4k-1920.mov; do /Applications/HandBrakeCLI -i "$src" --preset "H.265 MKV 1080p30" -o ~/Downloads/"$src-encode-1to9.mkv" 2>> ~/Downloads/"$src-encode-129-log.txt"; done; done

Code: Select all

[06:00:04] work: average encoding speed for job is 20.368988 fps
[08:07:41] work: average encoding speed for job is 2.294528 fps
[10:50:39] work: average encoding speed for job is 1.797639 fps
[12:48:44] work: average encoding speed for job is 2.481411 fps
[13:55:30] work: average encoding speed for job is 4.390096 fps

https://gist.github.com/twalker314/5468 ... 06b02aa5ac

When encoding different sources rather than Tears of Steel in a loop, I've had like a reasonably fast first encode followed by a bunch of slow encodes with an odd quick encode somewhere in the middle.

This is rather annoying, making this brand-new Mini potentially no faster than the late 2012 2.3 GHz quad i7 model it's meant to replace

At least it's silent and uses less electricity, but with encoding that slow it'll take a long time to recoup the purchase price.

I seem to recall a thread about similar issues on an M1-based Mac (mini?) around the time it was originally released, but I couldn't find the thread today.

Not yet sure how to further troubleshoot the issue. Open to suggestions

[Ritsuka]

Maybe the scheduler decides to run it only on the efficiency cores for some reasons, the CPU Activity window in Activity Monitor should display which cores are in use.

Does the same happens when using the GUI?

[Rodeo314]

Of course, it doesn't

Code: Select all

[16:14:56] work: average encoding speed for job is 20.531252 fps
[16:29:16] work: average encoding speed for job is 20.501556 fps
[16:43:37] work: average encoding speed for job is 20.504278 fps
[16:58:02] work: average encoding speed for job is 20.399042 fps
[17:12:20] work: average encoding speed for job is 20.547520 fps
[17:26:38] work: average encoding speed for job is 20.542616 fps
[17:41:00] work: average encoding speed for job is 20.467894 fps
[17:55:19] work: average encoding speed for job is 20.534437 fps
[18:09:40] work: average encoding speed for job is 20.497746 fps

The Mini is intended to eventually be headless and controlled over ssh, so now I need to figure out how to tell macOS to run HandBrakeCLI on the performance cores.

[Ritsuka]

I wonder why the first runs on the right qos class, but the following does not. Could it be the shell fault?
It should be possible to use taskpolicy to launch it and set the correct qos.

[Rodeo314]

Unfortunately I haven't had luck with taskpolicy, playing around with:

Code: Select all

taskpolicy -c utility /Applications/HandBrakeCLI […]
taskpolicy -l 0 -t 0 /Applications/HandBrakeCLI […]
taskpolicy -l 5 -t 5 /Applications/HandBrakeCLI […]

(it seems 0 would be the highest-priority anyway, but I wasn't 100% sure so I tried both)

More or less as soon as I sleep the display, the OS somehow downgrades HandBrakeCLI to a lower priority where it runs at less than 20% of its typical maximum speed

I haven't yet tried takspolicy -B on an already-running HandBrakeCLI but articles like https://eclecticlight.co/2022/01/24/how ... -on-an-m1/ suggest it probably won't work anyway. I'll give it a try just in case when I have more time.

[Rodeo314]

I also tried:

Code: Select all

taskpolicy -a -l 0 -t 0 /Applications/HandBrakeCLI […]
taskpolicy -a /Applications/HandBrakeCLI […]

…to no avail either.

[Rodeo314]

Sigh. Looks like "prevent automatic sleeping when the display is off" did the trick. Going to let it run overnight to make sure it sticks.

Leave it to Apple to have some sort partial-sleep mode where HandBrake can still encode at 1/10th of its normal rate, and also seemingly treat the assertions from hb_system_sleep_prevent differently for HandBrakeCLI vs. the GUI…

[Ritsuka]

The difference is that the GUI starts preventing sleep at the being of the queue, and releases the assertion when all the jobs are done. Instead calling the CLI multiple times means the sleep assertion is released after the CLI exits, and a new one is created again. Probably macOS changes things in the small internal between a CLI run and another.

[Rodeo314]

Ah yes, perhaps as soon as one of the assertion is released, it goes to some less-awake test. killing performance. The CLI can run a queue but creating a queue on another machine and patching the file paths is not practical.

The machine is amazingly silent, which doesn’t help (almost no noise difference between encoding and half-asleep) although that’s a plus in general.

[Rodeo314]

s/test./state, in that first sentence.

[Ritsuka]

You could try to run caffeinate in your script, that should avoid sleep.

[allbundy]

I have had very good experiences with Amphetamine and can therefore recommend it.

https://apps.apple.com/us/app/amphetamine/id937984704

[Rodeo314]

Over ssh?