Experimental Physics and
Industrial Control System
| 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> | 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> |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: GNU/Linux and GigE camera settings for high-throughput with ADAravis |
| From: | Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "Henrique F. Simoes" <henrique.simoes at lnls.br> |
| Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
| Date: | Fri, 12 Jan 2024 03:26:01 +0000 |
Actually, I just remembered that Bayer to RGB conversion is currently supported in NDPluginColorConvert,
so you can use it with ADAravis. That implementation is not highly optimized, and has been benchmarked at about 60 MPixels/s. You camera can do over 100 MPixels/s in Bayer mode, so it probably won't work at the full 23 frame/s. But it should work at 12
frames/s.
The implementation of Bayer to RGB is more optimized in the vendor libraries ADVimba
and ADSpinnaker, and can run a higher frame rates.
Mark
From: Henrique F. Simoes <henrique.simoes at lnls.br>
Sent: Thursday, January 11, 2024 12:05 PM To: Mark Rivers <rivers at cars.uchicago.edu> Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov> Subject: Re: GNU/Linux and GigE camera settings for high-throughput with ADAravis From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Wednesday, January 10, 2024 11:05 AM To: tech-talk at aps.anl.gov; Henrique F. Simoes Subject: Re: GNU/Linux and GigE camera settings for high-throughput with ADAravis > Hi Enrique, > > As James said, you should increase net.core.rmem_default, not just net.core.rmem_max. This is documented in the ADGenICam documentation > https://areadetector.github.io/master/ADGenICam/ADGenICam.html#linux-usb-and-gige-system-settings Thank you and James for highlighting this! It turns out to be the missing piece in the deployment machine. After rerunning with this setting, I could then achieve 7.4Hz lossless acquisition (~500k images). > Here are some suggestions: > > * Is the camera on a network with other devices, or a dedicated NIC on the Linux machine? If on a shared network how many switches between the camera and IOC machine? If there are shared links other network traffic could be the problem. A dedicated NIC is often a good solution. For those tests, I was using a dedicated NIC, with the camera traffic going through a single switch before reaching the IOC machine. No links should be shared, as far as I know, even though the switch itself is not dedicated. In a final setup, though, we will run two IOCs in the same machine for two cameras of the same model. But I'm not expecting both of them to operate at full throughput. Having a single one operate at its limit makes me more confident that the result we will observe is close to the maximum possible. > * You can try using ADVimba rather than ADAravis. It may have more optimized network handling. In the beginning, I ran an ADVimba IOC with this camera, but its failure rate was way higher than with ADAravis. I came to the point of single frame acquisitions not working (as the first frame would frequently drop). That was before I realized the issues I was noticing were only due to the network performance. > * If you use ADVimba you can make the camera run in color mode at the full 23 frames/s. You do that by using Bayer mode to read the camera, and do the conversion to RGB in the IOC, rather than on the camera. This reduces the network traffic by a factor of 3. That's a nice option to reduce traffic for color cameras. In terms of reducing network traffic, I've already used ROI (also described as AOI by some manufacturers) cropping done on the camera. Binning is another option, even though I haven't tested it yet. All of them reduce in some level the amount of information provided, and depend on the specific usage, though. > ADAravis does not currently support this option. Converting Bayer to RGB is (conceptually) general enough to be refactored (at least) to ADGenICam, isn't it? Best regards, Henrique F. Simões > Mark Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente. Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately. |
- References:
- GNU/Linux and GigE camera settings for high-throughput with ADAravis Henrique F. Simoes via Tech-talk
- Re: GNU/Linux and GigE camera settings for high-throughput with ADAravis Mark Rivers via Tech-talk
- Re: GNU/Linux and GigE camera settings for high-throughput with ADAravis Henrique F. Simoes via Tech-talk
- Navigate by Date:
- Prev: Re: GNU/Linux and GigE camera settings for high-throughput with ADAravis Mark Rivers via Tech-talk
- Next: autosave - Normative Types support? Gabriel Fedel via Tech-talk
- 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: Re: GNU/Linux and GigE camera settings for high-throughput with ADAravis Mark Rivers via Tech-talk
- Next: Re: quadEM-R7-0 ParamValNotDefined Rong Huang via Tech-talk
- 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>
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·