2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 <2005> 2006 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: | Ralph Lange <[email protected]> |
To: | Bob Dalesio <[email protected]> |
Cc: | Andrew Johnson <[email protected]>, "Kasemir, Kay-Uwe" <[email protected]>, 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 15:25:25 +0100 |
Bob Dalesio wrote:
But most probably not *all* records of that slower period, only those who belong to a certain subsystem, right? Hmm ... let's assume that every of these user named and created scanner threads can be configured to process its records either "synchronised en bloc" or "balanced". In that case the desired behaviour could be achieved by having your set of records all processed by a certain thread, which is configured to do it "en bloc", right?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.
Another interesting idea. I would rather have the load-balancing case being the default, though. At least I'd like the load-balancing setting to be easy, and the grouping to be the more elaborate configuration.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.
I have seen some cases where in case of a serial-type connection underneath a large number of IO-connected records in a slow task (e.g. the 10 second scan taking more than 1.5 seconds to finish) was filling up low level queues so that fast processing (going through the same queue) was heavily affected. With almost no way to change this behaviour.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.
Load-balancing would make the IOC a lot more "elastic" in this regard. Ralph