first of all, thanks a lot for this project. We are currently evaluating using aravis and so far, it looks very promising and especially the interface has been a pleasure to work with.
I am currently experimenting with arv-fake-gv-camera and seing problems with incomplete frames that I have a hard time understanding. I first thought they were due to my implementation, but now I see the same thing in the arv-viewer.
I start the fake camera like this: arv-fake-gv-camera-0.8 -s 42 --gvsp-lost-ratio=0
and observe the following:
the built-in fake camera in the viewer is fast, without any errors
a real TIS camera was performing well, too, without errors (at least as far as I remember, unfortunately I do not have it with me to confirm right now)
the fake camera via the loopback interface accumulates many errors when the frame rate is set to more than roughly 5fps. At 5 fps, it sometimes performs without errors but often also has phases where it the frame rate drops and error count increases.
What’s confusing to me is that I do not see which resource might be maxed out… neither the viewer nor the fake camera are using a significant amount of cpu, bandwith usage on lo, according to bmon, stays rather constant (1.28MiB/s if set to 5fps – interestingly this does not mirror the frame rate drops)
Does anyone have an idea what this might be about, and can maybe point me in a helpful direction?
I don’t understand what is happening here. The number of lost packets is quite high. Fake camera does not support packet resend request for now, which means each missing packet is causing the lost of an image.
On my laptop (Intel® Core™ i5-8365U CPU @ 1.60GHz), I can display a 100Hz 512x512 fake GigEVision camera with 1% of missing images.
I can confirm that there is something wrong with this particular system. When I compare with an old laptop and also try out different combinations of where the fake camera is running and where the viewer, I get the following numbers:
(these values have to be taken with a grain of salt, though, as there seem to be periods where things go relatively well, interrupted by those where they are worse, and I did not sample that systematically)
So the problem seems mostly on the receiving side, although having not only the receiver but also the sender on the new laptop makes things a lot worse, still.
Setting cpu core affinity for the two processes did not help.
I used iperf3 to look at the performance of the loopback device (especially udp packet loss) and that looks perfect even to much higher bandwidths…
I sometimes see phases where the sender reports
[GvFakeCamera::thread] Failed to send frame block 167 for frame 197: Resource temporarily unavailable
but for the majority of failures, the frames seem to get send just fine
Any idea for something I might try? Making sure we can get this stable (or at least understand under which conditions it ends up being unstable) would really be important for us before we decide to use aravis, so I’m willing to spend some time digging into this, but I’m at a bit of a loss with respect to where to start, so any hints are appreciated.