Subject: |
Changing SCAN field dynamically |
From: |
[email protected] (Marty Kraimer) |
Date: |
Tue, 18 Apr 1995 09:15:50 -0500 |
> From [email protected] Fri Apr 14 10:01 CDT 1995
> Date: Fri, 14 Apr 1995 11:01:17 -0400
> From: Sue Witherspoon <[email protected]>
> To: [email protected]
> Content-Type> : > text>
> Content-Length: 1721
>
> Greetings,
> I am having trouble with execution speed after changing the scan
> period.
> I have a lockset that utilizes the following scheme to change the scan
> period.
> ______________________________
> | ________ ____________ |
> | |(magRec)| |(stringout) | |
> | |--------| |------------| |
> | | HSCN |-->|DOL | OUT |->|
> | |--------| |____________|
> ->| SCAN |
> |________|
>
> 'magRec' is a custom record akin to a subroutine record. magRec.HSCN is
> a string field set by the user to dynamically control the scan rate.
>
> Initially, the magRec.SCAN and magRec.HSCN are PASSIVE. When
> magRec.HSCN is set to ".1 second" the magRec.SCAN will change to
> '.1 second'. This all appears to work well, at least for one instance.
> There are many of these locksets on one ioc. When more than on lockset
> are switched to '.1 second' the following results were:
>
> 1 is switched the record processes approximately 10 times a second
> 2 are switched the record processes approximately 7 times a second
> 3 are switched the record processes approximately 4 times a second
> 42 are switched the record processes approximately 1 time in 4 seconds
>
> Additionally, I eliminated the stringout and set the magRec.SCAN to
> ".1 second". Forty-two (42) records processed at 10 times a second, as
> expected.
>
> The ioc remains more that 40% idle during all tests and the scanPeriods
> never seemed to significantly use more CPU. My tools are:
> MVME-167 8Mb memory
> EPICS 3.11.0
> VxWorks 5.1.1
>
> Why does the performance degrade when I change the SCAN field dynamically?
> Thanks in advance.
> _______________________________________________________________________
> Sue Witherspoon
> CEBAF
> [email protected]
> (804)249-7579
>
Consider the situation after magRec has already been changed to .1 second
scanning. The following happens:
1) The scan task starts processing all the records in the .1 second group.
At some point it reaches the first magRec and asks for it to be processed.
2) When the stringout record writes to magRec.SCAN the following happens:
a) magRec is removed from its scan list, i.e. the .1 second list.
b) magRec is added to the .1 secfond scan list at the end.
3) Because the SCAN field of a record can be changed by an arbitrary task
while a record is being processed, the scan task has code to detect
if the scan list was modified while it was processing a record. This code
makes an attempt to do something "reasonable" if this happens.
It turns out that for the case we are looking at the following happens.
It just goes to the next member of the list of records in the .1 second
list. The next pointer is stored in the SPVT field of each record. However, THIS RECORD HAS JUST BEEN PLACED AT THE END OF THE LIST. Thus all the
other magRec records are skipped until the next .1 second interval.
Are you sure of your statistics? I would guess the that 2 records process
every .2 seconds. 3 records every .3 seconds etc.
Let me ask some more questions.
1) Why is the HSCN field necessary. Why cant the user just write to the SCAN
field?
2) In a later message you stated that you tried changing the SCAN field
from within the magRec but did not succeed. This shouild work. You could do
the following.
a) set the HSCN to special type SPC_MOD.
b) In the special routine call dbPut to change the SCAN field.
Note that changing it yourself will not have the desired effect
because it is not removed or placed in the appropriate scan list.
Again this seems unnecessary. Just let the user change the SCAN field.
Marty Kraimer
- Navigate by Date:
- Prev:
Re: your mail Sue Witherspoon
- Next:
Device driver for NOAO instrument Richard Wolff
- 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: your mail Sue Witherspoon
- Next:
Re: Changing SCAN field dynamically Marty Kraimer
- 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
|