[Bug 1841634] Re: CP link triggers lost when record is async

[mdavidsaver via Core-talk <core-talk@aps.anl.gov>]

I think I need to talk a bit of theory first.  What I see here is a
queue of queues, or a chain of queues.  In such a case, it is optimal to
handle overflows at the head of the first queue.  Anything else results
in work being done by earlier queue(s), only to be discarded when a
later queue overflows.  This is wasted work is what I meant by "churn".

The dbCa queue is 5 deep, while the RPRO "queue" is only 1.  Potentially
queuing up 5 scans only to discard 4 of them seems unnecessarily
wasteful.  Is is "a lot of".

imo. The proper way to handle these queue of queue situations is to
couple the queues so that flow control can be applied.  A full queue,
other than the first, can then apply back-pressure to the previous
queue.

This idea played into my adding scanOnceCallback() and using it to
provide feedback to dbCa.  What I see here is that that this feedback
comes too early.

I raise the possibility of using dbNotify because it seems like to only
mechanism I know of in Base at present which might provide the
additional information which scanOnceCallback() doesn't, when an
inprogress async record has finished.

I say "at present" because I don't particularly like dbNotify.  It's too
narrow in what it can do, and yet has enough options to be confusing.  I
would rather have a more general mechanism which doesn't try to handle
the "put" or "process" part of the sequence, which can be accomplished
with other APIs, but rather focuses on providing notification when
current (async) processing completes.  There is no other way to do this
part.

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1841634

Title:
  CP link triggers lost when record is async

Status in EPICS Base:
  Confirmed
Status in EPICS Base 7.0 series:
  Confirmed

Bug description:
  From Benjamin Franksen:

  Here is a small self-contained database to reproduce this:

  record(calcout,"input") {
      field(CALC,"A<4?A+1:A")
      field(INPA,"input")
      field(ODLY,"1")
      field(OUT,"input.A CA")
  }
  record(calcout,"output") {
      field(ODLY,"1.5")
      field(INPA,"input CPP")
      field(CALC,"A")
      field(TPRO,1)
  }
  record(calc,"check") {
      field(INPA,"input CPP")
      field(INPB,"output CPP")
      field(CALC,"A==B")
  }

  Processing "input" (caput input.PROC 1) starts the test. The "check"
  record should eventually settle to 1 (but doesn't).

  With 7.0.3 I get this output:

  scanOnce: dbProcess of 'output' # initial CPP processing
  scanOnce: dbProcess of 'output'
  scanOnce: dbProcess of Active 'output' with RPRO=0
  scanOnce: dbProcess of 'output'
  scanOnce: dbProcess of Active 'output' with RPRO=0

  Note how this says "with RPRO=0".

  And camonitor says:

  franksen@tiber: ~ > camonitor input output check
  input                          <undefined> 0 UDF INVALID
  output                         2019-08-27 16:02:16.106413 0
  check                          2019-08-27 16:02:16.106617 1
  input                          2019-08-27 16:02:26.498483 1
  check                          2019-08-27 16:02:26.498721 0
  input                          2019-08-27 16:02:27.493734 2
  output                         2019-08-27 16:02:27.993908 1
  input                          2019-08-27 16:02:28.489068 3
  input                          2019-08-27 16:02:29.484350 4
  output                         2019-08-27 16:02:29.984458 3

  I think the difference in behavior between processing due to a CPP
  input link versus processing due to a PP or CA output link is quite
  surprising.

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1841634/+subscriptions