Use 'performance' CPU frequency scaling governor instead of 'ondemand'

[lps-rocks]

What were you doing?

1. Use new webcam stack on hardwired network
2. Watch video / video will have uneven frame time spacings without dropping frames
3. Get annoyed by laggy video

What did you expect to happen?

Smooth Video playback

What happened instead?

Inconsistant interframe timings.

Did the same happen when running OctoPrint in safe mode?

No since I can't use the new video stack in Safe mode.

Version of OctoPi

OctoPi 1.0.0

Printer model & used firmware incl. version

N/A

Screenshot(s)/video(s) showing the problem:

https://i.hexhost.net/0decc46e-478c-497b-a27e-ed2ab4df8dbb.jpg

I have read the FAQ. (Yes)

Resolution

Changing the CPU frequency scaling governor from 'ondemand' (the default on the base OS that OctoPi is built on) to 'performance' resolved the isues. This tells me the scaling governor 'ondemand' takes too long to transition CPU states when processing video frames.

I opened this under the OctoPi project since this isn't something that 'camera-streamer' can resolve due to it being an OS level configuration item that needs to be changed.

[ayufan]

Per.: OctoPrint/OctoPi-UpToDate#6 (comment)

I would refrain from saying that we should change OctoPi governor. I think we should stay with ondemand, but tune gpu_freq and alike to force specific clock. It will be more power efficient, and will remove re-encoding stuttering.

The performance forces fixed clock on gpu.

[lps-rocks]

Per.: OctoPrint/OctoPi-UpToDate#6 (comment)

I would refrain from saying that we should change OctoPi governor. I think we should stay with ondemand, but tune gpu_freq and alike to force specific clock. It will be more power efficient, and will remove re-encoding stuttering.

The performance forces fixed clock on gpu.

If you can find an alternative solution that resolves the problem, then yeah, I think that's a viable solution, however, as of right now this is the only method that provides results.

[ayufan]

@lps-rocks I think you should try forcing gpu_freq=500 (for RPI4B). This will have the same outcome on frame stability AFAIK. Forcing performance governor is pretty harsh due to thermal impact, and power usage. Forcing GPU, ISP, H264 clock is more like a binary switch: it is on only when is used.

[lps-rocks]

@lps-rocks I think you should try forcing gpu_freq=500 (for RPI4B). This will have the same outcome on frame stability AFAIK. Forcing performance governor is pretty harsh due to thermal impact, and power usage. Forcing GPU, ISP, H264 clock is more like a binary switch: it is on only when is used.

That doesn't force a static clock speed. It sets the maximum frequency the GPU blocks will run at, it's still subject to frequency scaling. Right now, you're just throwing solutions at a wall to see what sticks without understanding the underlying technology. If you're going to criticize a working solution, understand it before denouncing it.

I'm currently running with gpu_freq=750 and arm_freq=2000.

https://github.com/raspberrypi/documentation/blob/develop/documentation/asciidoc/computers/config_txt/overclocking.adoc

https://forums.raspberrypi.com//viewtopic.php?p=169726#p169726

force_turbo=1 would basically do the same thing as enabling the performance governor.

[ayufan]

Right now, you're just throwing solutions at a wall to see what sticks without understanding the underlying technology

I opened this under the OctoPi project since this isn't something that 'camera-streamer' can resolve due to it being an OS level configuration item that needs to be changed.

I'm just saying that proposing performance governor is always bad. Forcing performance governor is not a solution, it is a workaround.

I did not yet test myself gpu_freq due to testing other stuff, but that with gpu_min_freq should do the trick. I see frequency fluctuations on GPU core, and this is to some extent expected.

[lps-rocks]

Right now, you're just throwing solutions at a wall to see what sticks without understanding the underlying technology

I opened this under the OctoPi project since this isn't something that 'camera-streamer' can resolve due to it being an OS level configuration item that needs to be changed.

I'm just saying that proposing performance governor is always bad. Forcing performance governor is not a solution, it is a workaround.

Claiming something is 'always' bad, is a terrible justification for shouting something down without empirical evidence that it's always bad. The performance governor can be enabled wherever latency sensitive applications exist because state transitions can take enough time to cause delays in processing. It's also generally best when you need significant varying degrees of performance in a very short time period, which is the case with video.

I did not yet test myself gpu_freq due to testing other stuff, but that with gpu_min_freq should do the trick. I see frequency fluctuations on GPU core, and this is to some extent expected.

You're making an assumption that it's the GPU core that's the bottleneck when down scaling, and not necessarily the arm cores.

Let's test these things before making claims and assumptions - You've wasted enough time trying to justify an untested position.

[ayufan]

Let's test these things before making claims and assumptions - You've wasted enough time trying to justify an untested position.

Here you are:

I just briefly tested this /boot/config.txt RPI4B:

[pi4]
h264_freq_min=500
isp_freq_min=500
v3d_freq_min=500
core_freq_min=500

It solves frame drops on USB cam in my limited testing when using ondemand governor. It is stable 25fps, with most of time CPU happily scaling between 300-1500MHz and significantly better re-encoding latency for processed frames:

Statistics: [  CAMERA 25 FPS/ 0 D/ 12ms/ 79ms/S/Q0:O0:C1] [ DECODER 25 FPS/ 0 D/ 33ms/ 20ms/S/Q1:O0:C0] [   VIDEO 25 FPS/ 0 D/ 53ms/ 19ms/S/Q0:O1:C1]

[lps-rocks]

Can you test the inter-frame latency consistency? That was the issue I was seeing was inconsistent interframe timings as well as drops.

[ayufan]

Do you have anything that would analyze pts of h264 stream?

[ayufan]

There's still improvement to be made in camera-streamer to set pts to capture time instead of emit time of frames.

[guysoft]

If there is anything I can ask people to test it might help to narrow down the issue.