It's better not to change rmem_default, or most sockets in the system will have an increased buffer size. Instead, using setsockopt() will increase the buffer size only for the camera.
Also, a 1 MB buffer may not be enough, since it represents a 8 ms buffer in a 1 Gbps network. It is common for an application to be preempted for dozens of milliseconds under heavy load. I'm currently testing 2 MB for our non-GigE camera server. Our camera, however, does not support packet retransmissions, while the GigE protocol does.
Em 21/04/2016 15:19, "Mark Rivers" < [email protected]> escreveu:
Folks,
I find that people frequently have problems with dropped frames when running GigE cameras on Linux, particularly under heavy CPU loading.
In 2013 I posted a message to tech-talk (http://www.aps.anl.gov/epics/tech-talk/2013/msg02491.php)
about this problem. It contained a link from Tom Cobb to a Point Grey Knowledge Base article with a solution, which involves increasing some system values as follows:
sudo sysctl -w net.core.rmem_max=1048576 net.core.rmem_default=1048576
I found today that the Point Grey link in that message no longer works. However, here is a new link that does work.
http://www.ptgrey.com/KB/10016
Mark
- Replies:
- RE: Dropped frames from GigE cameras on Linux Mark Rivers
- References:
- Dropped frames from GigE cameras on Linux Mark Rivers
- Navigate by Date:
- Prev:
Brookhaven National Laboratory - Job Opening Esposito, Peter J
- Next:
RE: Dropped frames from GigE cameras on Linux Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Dropped frames from GigE cameras on Linux Mark Rivers
- Next:
RE: Dropped frames from GigE cameras on Linux Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
|