EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS base V4
From: Bob Dalesio <[email protected]>
To: Ralph Lange <[email protected]>, Andrew Johnson <[email protected]>, "Kasemir, Kay-Uwe" <[email protected]>
Cc: Marty Kraimer <[email protected]>, Benjamin Franksen <[email protected]>, Eric Norum <[email protected]>, Jeff Hill <[email protected]>, Ned Arnold <[email protected]>, Matej Sekoranja <[email protected]>
Date: Fri, 25 Feb 2005 05:43:38 -0800
Back to the future.......
We had initially had the database so that there was one thread for periodic
scanning and that it used load leveling - that is it would evenly spread 1
second records over 10 .1 second periods.
Marty pointed out then that the use of forward links and passive records
made the load leveling a very difficult problem. Since then, I would add
that there are times that you want to have records of a slower period still
all process at the same time.
Perhaps an alternative would be to specify the base rate for the periodic
scanner.
Use PHAS to set which of the sub-periods to use to process the record
So - if the base scan period is 60 Hz, and you define a 1 second scan
record, PHAS of 30 would be at the halfway point of the 60 Hz scanning.

To bring this back to the functional specifications - the question seems to
be:
Do we need to be able to support "load balancing"

I think that it does not buy us much - but it is nice to give the database
engineer more control.



----- Original Message ----- 
From: "Ralph Lange" <[email protected]>
To: "Andrew Johnson" <[email protected]>
Cc: "Marty Kraimer" <[email protected]>; "Benjamin Franksen"
<[email protected]>; "Eric Norum" <[email protected]>; "Jeff Hill"
<[email protected]>; "Bob Dalesio" <[email protected]>; "Ned Arnold"
<[email protected]>; "Matej Sekoranja" <[email protected]>
Sent: Friday, February 25, 2005 5:07 AM
Subject: Re: EPICS base V4


> I like these ideas.
>
> Does this imply that IOC load is evenly distributed? I.e. that records
> with the same scanPeriod period are processed in a "spread over time"
> manner rather than "en bloc" as in V3?
>
> I would prefer such a spread behaviour, as it really should result in a
> more "elastic" IOC behavior. But: How would overload situations be
> handled (i.e. processing all records with a certain scanPeriod takes
> longer than that period). While the V3 method was inherently stable, it
> might be that this new way requires additional care. (When spread over
> different threads, overload situations may be hard to detect.)
>
> The V3 mechanism of the PHAS field determining the order of processing
> within a scan period does not make sense anymore with your approach,
> right? Will we have to have some kind of replacement for that mechanism,
> or can we urge the user to go to hard links and events (yes: named
> events!) instead?
>
> Ralph
>
>
> Andrew Johnson wrote:
>
> > Proposal for V4:
> >
> > Change the way in which records are executed, allowing the database
> > designer to select which threads perform processing of particular sets
> > of records.
> >
> > In V3 we create a thread for each scan period, plus a number of other
> > threads for callbacks etc. so the thread that a record processes in is
> > vaguely related to its SCAN and PRIO fields.  I propose changing
> > menuScan so it only contains "Passive", "Event", "I/O Interrupt" and
> > "Periodic".  We add another field which is a double called scanPeriod
> > which can be set to any period in seconds (this two-field approach is
> > analagous to "Event" and the old EVNT field).  We use a series of
> > epicsTimerQueues or something similar to cause records to be processed
> > when the relevent time interval has elapsed since they were last run.
> >
> > Now instead of having a thread for each period, we change the PRIO
> > field (whcih is currently only used for Event and I/O Interrupt) into
> > a field called scanThread.  This is a menu field which selects which
> > thread actually does the record processing (executes the
> > epicsTimerQueue), and this allows the database designer much more
> > control over the relative priorities of different parts of the IOC's
> > database.
> >
> > I suspect this would probably increase the number of threads that
> > actually get used, but it makes it possible to partition off different
> > parts of the database so that the highest priority work always gets
> > done even though there's a frequently processed chain going on in some
> > lower priority thread.  We would not need the callback tasks that
> > currently do I/O Interrupt processing, because the interrupt can just
> > add the record into the queue for its regular processing thread.
> >
> > Note that a record which has scan=Passive should still be executed by
> > the thread of whichever record processes it (FLNK, PP link), although
> > we could add another choice ("Triggered") where the record's selected
> > scanThread gets used.  Hmm, that has implications for providing a
> > PV-Get that can cross a thread boundary, making the Getting record
> > wait for the other to return the desired value...  I haven't thought
> > about this part properly yet, it has implications for semaphores and
> > deadlocks.
> >
> > Comments?
> >
> > - Andrew
>



Replies:
Re: EPICS base V4 Ralph Lange
References:
Re: EPICS base V4: iocCore database Marty Kraimer
Re: EPICS base V4: iocCore database Andrew Johnson
Re: EPICS base V4: iocCore database: Booleans Benjamin Franksen
EPICS base V4 Marty Kraimer
Re: EPICS base V4 Andrew Johnson
Re: EPICS base V4 Ralph Lange

Navigate by Date:
Prev: Re: EPICS base V4 Ralph Lange
Next: Re: EPICS base V4 Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS base V4 Ralph Lange
Next: Re: EPICS base V4 Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·