cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Kernel/scheduler affecting "raspivid" behaviour?

Mon Jul 24, 2017 10:00 am

I have a somewhat strange observation.

I originally developed my aerial robot application (still nowhere near flying) on a Pi 3 with the 4.9.35 kernel. Then, after discovering that Pi4J had problems with that kernel, I downgraded to 4.4.45.

I have two processes reporting FPS (frames per second) in my code. One is the video grabber (it acquires frames and motion vectors from "raspivid"). The other is the video observer (it performs analysis on the frames and motion vectors and deals with object tracking).

I observe that under the 4.4 kernel, my software's frame rate is unstable at best, and sometimes it deadlocks (meaning there is a weakness in my code, which I have to address separately). However, the same code under a 4.9 kernel runs in predictable and stable manner. I am inclined to blame the Linux task scheduler, but don't know better. Fortunately it's the newer kernel which is behaving well, but that makes debugging my deadlock issue harder, as it only happens with the old kernel.

Does anyone know, did Linux change scheduler behaviour between 4.4 and 4.9? Or maybe something has changed in how standard output or error streams are buffered?

P.S. Application is written in Java. JRE is HotSpot (Oracle) 1.8, and in "/boot/config.txt", I have "force_turbo=1".

Example with 4.4 kernel:

Code: Select all

VidObs running @ 18.656716417910445 fps.
Grabber running @ 24.715768660405338 fps.
Grabber running @ 24.70966147763776 vps.
VidObs running @ 25.025025025025027 fps.
VidObs running @ 43.2152117545376 fps.
Grabber running @ 31.86743148502231 fps.
Grabber running @ 31.86743148502231 vps.
VidObs running @ 30.120481927710845 fps.
VidObs running @ 30.01200480192077 fps.
Grabber running @ 27.654867256637168 fps.
Grabber running @ 27.654867256637168 vps.
VidObs running @ 23.08402585410896 fps.
VidObs running @ 35.587188612099645 fps.
Grabber running @ 25.94706798131811 fps.
Grabber running @ 25.94706798131811 vps.
VidObs running @ 24.213075060532688 fps.
VidObs running @ 32.32062055591467 fps.
Grabber running @ 39.58828186856691 fps.
Grabber running @ 39.603960396039604 vps.
VidObs running @ 49.21259842519685 fps.
VidObs running @ 25.906735751295336 fps.
Example with 4.9 kernel:

Code: Select all

VidObs running @ 30.084235860409148 fps.
Grabber running @ 30.003000300030003 fps.
Grabber running @ 30.01200480192077 vps.
VidObs running @ 31.308703819661865 fps.
VidObs running @ 29.97601918465228 fps.
Grabber running @ 30.02101471029721 fps.
Grabber running @ 30.02101471029721 vps.
VidObs running @ 30.03003003003003 fps.
VidObs running @ 30.01200480192077 fps.
Grabber running @ 30.003000300030003 fps.
Grabber running @ 30.01200480192077 vps.
VidObs running @ 29.958058717795087 fps.
VidObs running @ 30.048076923076923 fps.
Grabber running @ 30.003000300030003 fps.
Grabber running @ 29.994001199760046 vps.
VidObs running @ 30.01200480192077 fps.
VidObs running @ 29.97601918465228 fps.
Grabber running @ 30.01200480192077 fps.
Grabber running @ 30.01200480192077 vps.
VidObs running @ 30.03003003003003 fps.
VidObs running @ 30.01200480192077 fps.
Grabber running @ 30.01200480192077 fps.
Grabber running @ 30.01200480192077 vps.
VidObs running @ 29.97601918465228 fps.

User avatar
savageautomate
Posts: 225
Joined: Thu Aug 16, 2012 3:20 pm
Location: USA
Contact: Website

Re: Kernel/scheduler affecting "raspivid" behaviour?

Sat Aug 05, 2017 2:45 pm

FYI ... you should be able to run your code using the Pi4J libraries on kernel 4.8 and later using Pi4J 1.2-SNAPSHOT builds.
See this thread for more details:
https://github.com/Pi4J/pi4j/issues/349

Thanks, Robert
Robert Savage | Follow me @savageautomate
http://www.pi4j.com | http://www.pislices.com
http://www.savagehomeautomation.com

cpunk
Posts: 80
Joined: Thu Jun 29, 2017 12:39 pm

Re: Kernel/scheduler affecting "raspivid" behaviour?

Sat Aug 05, 2017 7:02 pm

Thank you. :)

For me, it was a fortunate mishap, as due to swapping kernels back and forth trying to figure things out, I found and patched a juicy bug in my own video analysis code. :)

Return to “Camera board”