You can also set records to scan on a soft "EVENT" and then have a task (e.g. a sequence program) that causes the Event record to process at a higher rate. This is all standard EPICS with no driver development.
Ned
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Manoussakis, Adamandios via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, December 9, 2020 03:46 PM
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: RE: Faster Scan Rates possible?
Thanks Mark, I will look into the I/O intr support and how we might be able to implement it.
-----Original Message-----
From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Wednesday, December 9, 2020 1:43 PM
To: Manoussakis, Adamandios <manoussakis1 at llnl.gov>
Subject: Re: Faster Scan Rates possible?
I have never changed the scan rates, so I am not sure about the priorities.
Note that increasing the periodic scan rates is not necessarily the best way to process records more quickly. Another way is to have the device support or driver support SCAN=I/O Intr. That is the approach that most drivers I have written use.
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Manoussakis, Adamandios via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, December 9, 2020 3:36 PM
To: EPICS tech-talk
Subject: RE: Faster Scan Rates possible?
Also mark just to make sure I understood Passive,Event,IO Intr are always at the top and do not have any priority assigned due to being event driven and then the next menuScans are from slowest to fastest which are assigned also lower to highest priority 10s
being lowest priority and .1 second being highest priority assigned?
menu(menuScan) {
choice(menuScanPassive,"Passive")
choice(menuScanEvent,"Event")
choice(menuScanI_O_Intr,"I/O Intr")
choice(menuScan10_second,"10 second")
choice(menuScan5_second,"5 second")
choice(menuScan2_second,"2 second")
choice(menuScan1_second,"1 second")
choice(menuScan_5_second,".5 second")
choice(menuScan_2_second,".2 second")
choice(menuScan_1_second,".1 second")
}
From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Manoussakis, Adamandios via Tech-talk
Sent: Wednesday, December 9, 2020 1:33 PM
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: RE: Faster Scan Rates possible?
Thanks Mark/Andrew for the insigh, is there any rule of thumb for how fast you can setup a SCAN rate in that dbd file for any current line of CPU (assuming more cores would help with threading and higher clock speeds). Is it safe to say go to .01 .001 on current
gen cpu hardware?
From: Johnson, Andrew N. <anj at anl.gov<mailto:anj at anl.gov>>
Sent: Wednesday, December 9, 2020 1:21 PM
To: Manoussakis, Adamandios <manoussakis1 at llnl.gov<mailto:manoussakis1 at llnl.gov>>
Cc: EPICS tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>
Subject: Re: Faster Scan Rates possible?
Hi,
On Dec 9, 2020, at 3:14 PM, Manoussakis, Adamandios via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>> wrote:
I have been looking at older posts and have seen talk of increasing the scan rate from the default (I think) .1seconds but no definitive guide on how to? On a standard linux distro without RT_PREEMPT, is it possible to push to say .01 or faster scan rates?
Also I wanted to know does camonitor only update as fast as the scan rate limit, .1seconds currently?
There is no internal connection between CA monitor rates and the DB scan rates, it very much depends on your CPU, your IOC application and the clients you have connected as to how fast you would be able to run a periodic scan thread that sends out monitors.
Note that the IOC's CA server can and does throw away monitor updates if the clients can't keep up, so don't design your systems assuming that your clients will always get every monitor if you're running at high speeds.
HTH,
- Andrew
--
Complexity comes for free, simplicity you have to work for.
|