Re: PVA links alpha

[Michael Davidsaver <mdavidsaver@gmail.com>]

On 04/25/2018 12:05 PM, Andrew Johnson wrote:
> Hi Michael,
> 
> Since I've just started reading your page I might as well write down
> some comments as I get to them. I haven't tried using this at all.
> 
> Before I get to the pvalink bit, your example for the QSRV Timestamp
> option says 16 in one place and 20 elsewhere.

This is what I get for being indecisive.  I started using 16, then changed
my mind and decided that 20 made a clearer example.

> On 04/24/2018 12:11 PM, Michael Davidsaver wrote:
...
> Wow! Are all of these options things that may actually need to be set
> separately for each link?

Yes.

> Are there any for which an IOC-wide default
> might be wanted? (maybe not, I wrote that before reading the doc...).

I'm not sure.  I think probably not as doing so would mean that .db files
from 3rd party modules would need to be ridiculously explicit, or risk
being broken if these defaults aren't as expected.

The one I might agree on this the 'local' flag as in my experience,
3rd party modules don't often (intentionally) make links outside
of an IOC.

>> I've tried to describe all of these on the documentation page, although
>> it would be nice to get some comments as to how well I've succeeded.
>>
>> http://mdavidsaver.github.io/pva2pva/qsrv_page.html#qsrv_link
> 
> Do you support forward links? Not covered that I can see.

Yes, it's supported.  A forward link is a put without any data
(which PVA allows).  How exactly this is interpreted may not
be correct yet.  It isn't documented because I haven't spent much
time on this yet.

> In general I like your approach to option naming, just a few quibbles below.
> 
> monorder: Allowed range? This should probably be called phase,

So "monorder" --> "phase"?

> to match the PHAS field, which is unsigned;

From dbCommon.dbd

>	field(PHAS,DBF_SHORT) {

I know this is signed as one of my "tricks" for roughly measuring
processing time of a scan list is to set one record PHAS=-1 and
another to PHAS=1 and look at the difference in the time stamps.

> I'm not sure that supporting -ve
> numbers makes much sense. Is there any performance penalty for leaving
> gaps between values, say 10,20,30 vs 1,2,3?

The performance hit to sort is taken once each time a link is added
or removed.  So unless links are being re-targeted, there is no cost
after IOC startup.

> defer: Probably needs more explanation and an example — how does it
> group puts together? Could I have 2 independent deferred groups for the
> same target PV (so should the value of defer be a group name instead of
> a boolean? If so, maybe defer is the wrong name?)


All link to the same PV name, and the same pvRequest for monitor,
also share the Put cache.  So yes, you would have two groups
if one link specified "Q:5", which as I think about it, can
only cause confusion.


How would such a "put group" name tell me which link should actually
execute the Put?  This is what the 'defer' tag encodes.


I'm working on an more complete example.

> record(ao, "src:I") {
>   field(OUT, {pva:{pva:"tgt", field:"I", defer:true}})
>   field(FLNK, "src:Q")
> }
> record(ao, "src:Q") {
>   field(OUT, {pva:{pva:"tgt", field:"Q", defer:false}})
> }

So the second put from "one:Q" actually executes the put, which
includes both I and Q values.

> retry: That name doesn't make it clear that it's related to disconnected
> channels, although I don't have any other naming suggestions yet.

Yup.  I have the same lack of ideas.  "retry" isn't good because it actually
doesn't retry if a put fails.  "queue-put-while-disconnected" seems too long...

> always: Not sure I understand the description, can you try to re-word
> it; an example might help.

For CP/CPP, process only on value update, or always.

"value update" in this case meaning that the subscription update
includes a new value, which may be the same as the previous one.

> local: Could you instead provide "host" where the user can tell you
> which host should have the PV (to avoid doing broadcast searches, or
> allow pointing outside the local subnet) and that would understand some
> value to mean the same as local:true?

I'm trying to handle what for me is the common case of detecting
when I've typo'd a PV name.

(I have considered adding a "LOCAL" link modifier to detect when
 a typo makes a CA_LINK when I intended a DB_LINK)

Also, I'm not sure if per channel override of the search address list
actually works.  I see code which looks like it would do this,
but I've never tested it.  Finding three TODO's (and ten !) in one
method doesn't fill me with confidence.

>         virtual void callback() OVERRIDE FINAL {
>             // TODO cancellaction?!
>             // TODO not in this timer thread !!!
>             // TODO boost when a server (from address list) is started!!! IP vs address !!!



> Got go to now, hope this is helpful to start with.

Yes, thanks.