Experimental Physics and Industrial Control System
|
Thanks, Andrew and Emmanuel for your replies.
I am running Soft IOC on Dell server (64 bit) with eight Intel Xeon
CPUs, each 2.27GHz.
It seems that syntax for dbd file is correct. I found that minimum scan
period for my system is 0.001 seconds. For shorter periods it falls down
to 0.1 second, as Andrew mentioned.
The difference in one CPU usage is only 5% if I run records with scan
0.1 second or 0.001 second. It looks like it is limitation of EPICS, not
hardware. What is the bottleneck for processing of a record on GHz CPUs?
Is it possible to improve it?
Evgeniy
-------- Original Message --------
Hi,
On 11/26/2013 05:20 PM, Evgeniy wrote:
I can easily set scan period to 0.01 second by adding:
choice(menuScan_01_second,".01 second")
in dbd file.
Note that if the IOC's processing of all the records that have
SCAN=.01 second takes longer than 0.01 second to execute, the scan
rate will drop to 10Hz automatically. The code in base/src/db/dbScan.c
enforces this (3.14.12.4 will not be as strict, but does still limit
the processing rate if it takes longer than the scan period to process
all the records on the scan list).
What about adding scan period 0.0001 second?
Similar line:
choice(menuScan_0001_second,".0001 second")
doesn't work.
I'm not surprised; what happens? My guess would be that you get about
10Hz, because the record processing takes longer than 100µs to complete.
CLOCKS_PER_SECOND on my 8-core DELL server is 1000000 (running SL5.4).
What should I do to set scan period to 0.0001 second?
I don't recommend even trying to get a periodic scan thread running at
that kind of rate, try to find a different solution to your problem.
There are other ways to trigger a record to process, the simplest is
to arrange for some code to call post_event(n) which will make all
records that have SCAN=Event and EVNT=n be processed once. However
this trigger still goes through a circular buffer which will limit the
number of times you can queue the event to less than 2000.
I need such short period to quickly fill in the circular buffer of
compress record.
You might want to re-think that; the compress record may not be the
best solution to whatever it is you're trying to do -- maybe you could
create your own record type, starting from the compress record source,
which you can initialize manually to whatever state you want it to be in?
- Andrew
- Replies:
- Re: Increasing scan rate to 10 kHz Eric Norum
- References:
- Increasing scan rate to 10 kHz Evgeniy
- Re: Increasing scan rate to 10 kHz Andrew Johnson
- Navigate by Date:
- Prev:
Re: Error with Asyn and rpcgen Hugo Slepicka
- Next:
Re: Increasing scan rate to 10 kHz Eric Norum
- 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: Increasing scan rate to 10 kHz Andrew Johnson
- Next:
Re: Increasing scan rate to 10 kHz Eric Norum
- 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
|
ANJ, 20 Apr 2015 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|