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: EPICS and EPICS+PVXS internal threading of IOCs |
| From: | Joao Paulo Martins via Tech-talk <tech-talk at aps.anl.gov> |
| To: | EPICS Tech Talk <tech-talk at aps.anl.gov> |
| Date: | Fri, 17 May 2024 15:12:48 +0000 |
|
Hello all, This is a very interesting topic. I have an example and would be nice to get some guidance on how to proceed. Let’s say there are two IOCs running in the same host (which has Linux PREEMPT_RT, btw). The IOC A has a record that gets updated at 10 Hz (via hardware interrupts). The IOC B has a
record that gets updated and fetches its timestamp using the TSEL link (with CPP) mechanism from that 10Hz PV of the IOC A.
Which are the threads (in both IOCs) that I should elevate priority or run in dedicated cores that will improve the determinism of this operation? (not interested in reducing the latency,
but to know that this latency won’t be more than N micro/milliseconds). Thanks in advance (and sorry for deviate from your original question, Dave!) João Paulo Martins From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov> That is more or less the basic setup. Note that there are already network specific threads in this list, which are generated per network interface configured. When EPICS network connections are active, the server(s) on the IOC will usually start one pair of threads per client. If your IOC uses the parallel callback threads functionality (to utilize parallel processing on multiple CPUs), there will be (highly configurable) more instances of the cbLow/cbMedium/cbHigh threads. Many drivers and device support modules start their own threads. ASYN ports often have a thread associated with each port, AreaDetector plugins (as they are implemented as ASYN ports) most often start a thread per plugin. MCoreUtils is a module that you can use to have more control over priorities, scheduling mechanisms and CPU allocation of IOC threads. This is convenient when you're running real-time applications on the same host and want to keep the IOC
from running on your dedicated real-time core(s). (Except maybe for that one device support thread that does the communication between the IOC and the real-time parts...) Cheers, |
- Replies:
- Re: EPICS and EPICS+PVXS internal threading of IOCs Han Lee via Tech-talk
- References:
- EPICS and EPICS+PVXS internal threading of IOCs Dave Bracey via Tech-talk
- Re: EPICS and EPICS+PVXS internal threading of IOCs Mark Rivers via Tech-talk
- Re: EPICS and EPICS+PVXS internal threading of IOCs Ralph Lange via Tech-talk
- Navigate by Date:
- Prev: Re: urldefense.us URLs? Kevin Peterson via Tech-talk
- Next: Re: EPICS and EPICS+PVXS internal threading of IOCs Han Lee 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: EPICS and EPICS+PVXS internal threading of IOCs Ralph Lange via Tech-talk
- Next: Re: EPICS and EPICS+PVXS internal threading of IOCs Han Lee 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 ·