ARV_BUFFER_STATUS_TIMEOUT how to diagnose?

Hello, again.

After a few seconds of grabbing frames successfully, I am running into the ARV_BUFFER_STATUS_TIMEOUT error. I turned on debug output, and obtained this info:

[GvStream::find_frame_data] Start frame 834
[GvStream::check_frame_completion] Completed frame 834
[GvStream::close_frame] Close frame 834
[GvStream::find_frame_data] Start frame 835
[GvStream::check_frame_completion] Completed frame 835
[GvStream::close_frame] Close frame 835
[GvStream::find_frame_data] Start frame 836
[GvStream::process_packet] Error packet at dt = 34, packet id = 1 frame id = 836
[GvStream::find_frame_data] Start frame 837
[GvStream::find_frame_data] Start frame 838
[GvStream::find_frame_data] Start frame 839
[GvStream::find_frame_data] Start frame 840
[GvStream::process_packet] Error packet at dt = 71, packet id = 1 frame id = 840
[GvStream::find_frame_data] Start frame 841
[GvStream::find_frame_data] Start frame 842
[GvStream::find_frame_data] Start frame 843
[GvStream::process_packet] Error packet at dt = 54, packet id = 1 frame id = 843
[GvStream::find_frame_data] Start frame 844
[GvStream::find_frame_data] Start frame 845
[GvStream::find_frame_data] Start frame 846
[GvStream::find_frame_data] Start frame 847
[GvStream::process_packet] Error packet at dt = 51, packet id = 1 frame id = 847

I have increased the number of buffers, but it does not appear to have had much effect.

Any ideas on what I can try?

Thank you very much.

1 Like

I have the same issue with the latest HEAD as I do with 0.6.0

root@airtop:/opt/aravis/build/tests# ./arv-camera-test
Looking for the first available camera
vendor name           = Teledyne DALSA
model name            = Linea M8192-7um
device id             = 12160074
image width           = 0
image height          = 0
horizontal binning    = 1
vertical binning      = 1
payload               = 1048576 bytes
exposure              = 5 µs
gain                  = 2 dB
gv n_stream channels  = 1
gv current channel    = 0
gv packet delay       = 0 ns
gv packet size        = 9204 bytes
Frame rate = 145 Hz
Frame rate = 117 Hz
Frame rate = 116 Hz
Frame rate = 116 Hz
Frame rate = 118 Hz
Frame rate = 116 Hz
Frame rate = 116 Hz
Frame rate = 106 Hz
Frame rate = 117 Hz
Completed buffers = 1182
Failures          = 102
Underruns         = 0

The first packets are at the full expected frame rate for the camera, but then errors slow it down.

Also worth noting is that I do not seem to have this problem when running the vendor’s own SDK, so there is likely something that we can do to get Aravis working at the desired frame rate.

Hi Ron,

Is this a gigabit camera ? Because with a payload of 1048576 bytes and a 117Hz framerate, we get 116MB/s, which fully fills a gigabit link.

If it is a 10Gb camera on a 10Gb link, you may want to try to increase the socket buffer size (try the -a option of arv-camera-test), enable high priority for the stream receiving thread (--high-priority), real time scheduling (--realtime, but as root), and increase the packet size (run tests/arv-auto-packet-size-test before launching arv-camera-test).

I forgot to mention the packet socket support, which has clearly better performances. It is not available by default though, as the packet socket API needs either root privileges, or special executable attributes.

Increasing the number of buffers is only necessary when the buffer processing latency exceeds the frame acquisition period. A good indicator is the buffer underrun counter.

Of course you are absolutely correct. Not sure where the stats in the version lib come from, but they cannot exceed the physical limits of the host hardware.

Thanks for the sanity check!

Yes, indeed. I am using packet sockets, which is the only reason I can even achieve the stated performance stats. Running docker with the --privileged flag gives those pcap rights.