EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: monitoring a very large number of channels
From: Ralph Lange <[email protected]>
To: Patrick Thomas <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Fri, 30 Jul 2010 10:01:13 -0400
Patrick,

interesting question - I would answer with a determined: it all depends.

There are a number of resource limitations that you could bump into when using Channel Access. Which one of those will be the first thing you hit, depends on many factors of your setup, not just the number of channels.

Here are a few limitations I can think of, ordered by guessed likelihood of causing trouble (descending):

Network bandwidth
Depends mainly on the type of data you are monitoring. If you are monitoring live color images at 30fps, a few channels will take all your available bandwidth even on a fast network, and you're screwed. If you are monitoring integers that update once every 10 seconds, without timestamps or alarm status, it will take a few 100,000 channels to put a noticable load on the same network. Unless you are on a 9600 baud modem line.


File descriptors
CA uses one TCP per client/IOC combination. Depending on your system configuration, one client trying to connect to more than 1024 IOCs could hit a limit, without even subscribing to a single channel.


Threads
On Linux, every thread counts against the maximum number of processes on the system. CA uses two threads per TCP circuit. Depending on your kernel configuration (cat /proc/sys/kernel/threads-max) and the other stuff running on your client machine, you might hit that limit by connecting to a large number of IOCs (again independent from number of channels).


Memory
CA allocates memory for each connection, and (much less) for each subscription. Its CPU usage depends on the amount of data it processes. If you enforce memory or CPU time limits on your client, you might hit those.


Numerical limits
CA uses unsigned 32 bit channel identifiers. So there there is a hard limit of ~4.3 billion channels per client. Which probably is still two or three orders of magnitude more than the largest existing EPICS systems.


For a usual client in a usual system, (e.g. the Channel Archiver or camonitor), the limiting factor will be bandwidth of their output (i.e.writing to disk or printing on your terminal) rather than any CA related limits.
As Bob pointed out, running archive engines that connect to a few 10,000 channels is possible and common with larger installations.
How fast you can actually archive depends one the data size, the machine, the disks, the storage format, ..... should be in the order of between 5,000 and 15,000 updates/sec (double plus timestamp and status).


Good luck and do not worry!
Ralph


On 30.07.2010 05:51, Patrick Thomas wrote:
Hi,

I was wondering what the limiting factor is with regards to placing monitors on a large number of channels. For example, how many channels can camonitor or channel archiver watch?

Thank you,
Patrick

References:
monitoring a very large number of channels Patrick Thomas

Navigate by Date:
Prev: RE: monitoring a very large number of channels Dalesio, Leo
Next: archive server discussion james.rowland
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: monitoring a very large number of channels Dalesio, Leo
Next: sample gas analysis peter.leicester
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·