| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Dropped frames from GigE cameras on Linux |
| From: | Henrique Almeida <[email protected]> |
| To: | Mark Rivers <[email protected]> |
| Cc: | "[email protected] Talk" <[email protected]> |
| Date: | Sat, 23 Apr 2016 16:08:20 -0300 |
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.
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