Re: Increasing scan rate to 10 kHz

[Evgeniy <tikh@triumf.ca>]

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