Describe the issue:
We experience a lot of grab failures even at moderate data rate. It turned out that even setting net.core.rmem_default and net.core.rmem_max does not change the SocketBufferSize of 64k.
grab_params = camera.GetStreamGrabberNodeMap()
if grab_params is not None:
node = grab_params.GetNode("SocketBufferSize")
old_val = node.GetValue()
max_val = node.GetMax()
node.SetValue(max_val)
logger.info(f"Stream SocketBufferSize (KB): {old_val} -> {node.GetValue()} (max={max_val})")
gives
INFO - Stream SocketBufferSize (KB): 64 -> 64 (max=64)
However
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as s:
s.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 2**30)
effective = s.getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF)
# kernel doubles the requested value, so effective == 2 * rmem_max
# we return the raw value to request (rmem_max), kernel will double it again
rmem_max = effective // 2
logger.info(f"Probed rmem_max={rmem_max} (kernel reported {effective})")
return rmem_max
gives
Probed rmem_max=33554432 (kernel reported 67108864)
Also with ss I confirmed that the pylon socket is only created with 64k buffer size. Manually overriding the socketbuffer (via /proc/self/fd) to larger size solves the problem and the grab fails go away.
I believe it is a pylon bug that the receive socket buffer size is only 64k. Also that the SocketBufferSize.Max is only 64k and not the net.core.rmem_max is also a bug.
Even though I have to admit that the value of net.core.rmem_max is not available inside of a container. However one can probe the kernel indirectly for rmem_max by just opening a socket with a super large buffer request (see above).
Reproduce the code example:
grab_params = camera.GetStreamGrabberNodeMap()
if grab_params is not None:
node = grab_params.GetNode("SocketBufferSize")
old_val = node.GetValue()
max_val = node.GetMax()
node.SetValue(max_val)
logger.info(f"Stream SocketBufferSize (KB): {old_val} -> {node.GetValue()} (max={max_val})")
Error message:
Is your camera operational in Basler pylon viewer on your platform
Yes
Hardware setup & camera model(s) used
python3 -c "from pypylon import pylon; print(pylon.GetPylonVersion())"
[11, 3, 0, 928]
Runtime information:
Python 3.11.6 (main, Nov 29 2023, 04:47:02) [GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, pypylon.pylon, platform
>>> print(f'python: {sys.version}')
python: 3.11.6 (main, Nov 29 2023, 04:47:02) [GCC 10.2.1 20210110]
>>> print(f'platform: {sys.platform}/{platform.machine()}/{platform.release()}')
platform: linux/x86_64/6.1.111-cip29-rt15+ind1
>>> print(f'pypylon: {pypylon.pylon.__version__} / {".".join([str(i) for i in pypylon.pylon.GetPylonVersion()])}')
pypylon: 26.02.1 / 11.3.0.928
Describe the issue:
We experience a lot of grab failures even at moderate data rate. It turned out that even setting net.core.rmem_default and net.core.rmem_max does not change the SocketBufferSize of 64k.
gives
However
gives
Also with
ssI confirmed that the pylon socket is only created with 64k buffer size. Manually overriding the socketbuffer (via /proc/self/fd) to larger size solves the problem and the grab fails go away.I believe it is a pylon bug that the receive socket buffer size is only 64k. Also that the SocketBufferSize.Max is only 64k and not the net.core.rmem_max is also a bug.
Even though I have to admit that the value of
net.core.rmem_maxis not available inside of a container. However one can probe the kernel indirectly for rmem_max by just opening a socket with a super large buffer request (see above).Reproduce the code example:
Error message:
Is your camera operational in Basler pylon viewer on your platform
Yes
Hardware setup & camera model(s) used
Runtime information: