Re: Named Event, TSE and GeneralTime

[Dirk Zimoch <dirk.zimoch@psi.ch>]

On 24.02.2018 23:08, Michael Davidsaver wrote:
> On 02/23/2018 02:37 PM, Kim, Kukhee wrote:
> > Dear Core Developers;
> >
> >   
> >
> > I and my colleagues in SLAC, are recently studying about the named event and its new API.
> >
> > It is helpful us.
> >
> > LCLS1 used up all of 255 numbered events in event system, and we need more events for LCLS2.
> >
> > Since, our timing system need to work for both LCLS1 and LCLS2, we want to extend the number of events.
> >
> > The named event removes the cap of 255 events.
> Isn't the "cap" +-32767?  The TSE field is DBF_SHORT.  And the second argument of epicsTimeGetEvent()
> is an 'int'.
The old implementation supported only events 1-255.

> > But, it also brings some following issues:
> >
> >   
> >
> > When we generates event, we latched timestamp and pulse id for the event.
> >
> > If we set TSE>0, the generalTime allows to retrieve the timestamp for PVs.
> >
> >   
> >
> > 1.       There is no limit for the number of event, but TSE has limits -2, -1, 0, …. ,255
> >
> > 2.       Event can have name (not numberic) but, TSE is still numeric field
> >
> >   
> >
> > Since, TSE is still numeric field, we found a quick solution.
> >
> > We are going to assign  “1” to  name “255” named event for LCLS1 and higher number string (ex, “301”, “302”..) for LCLS2.
> >
> > We are going to modify a macro in GeneralTime which limits the maximum number of event to support the higher number events. We are going to extend supporting event number in our Event Provider function.
> >
> > Please, let me know if it is acceptable.
> This is going to come down to the details.  Will this in any way be an incompatible change?
> Either to .db files, code calling epicsTime*() functions, or the time provider API?
>
> > I am also wondering about future plan for the TSE field generalTime Event Provider.
> >
> > Event has name, but TSE is numeric. It looks like we are in the middle of changes.
> In order to minimize redundant work, and frustration, it might be a good idea
> to answer the question of compatibility before going too far.
>
> > I would like to suggest, if we can change TSE field to accept string. Then, we can solve all of above issues.
> >
> > For the backward compatibility for the string TSE field, we can use string for certain function:
> >
> > Ex,          “-2”: driver layer updates record timestamp field
> >
> >                 “-1”: best event provider gives record timestamp
> >
> >                  “0”: current time provider gives timestamp
> >
> >                  Named string: best event provider gives timestamp which corresponds to the particular event.
I thought that TSE uses hardware events (e.g. from MRF event receiver) 
which have not much more in common with db events than a similar name.
> If we're going to change TSE to DBF_STRING then:
>
> 1. You'll need to handle the cases like the ongoing changes involving EVNT.  eg. "-2.0"
>
> https://code.launchpad.net/~dirk.zimoch/epics-base/+git/epics-base/+merge/337850
>
> 2. How about a meaningful symbolic name as well as the compatibility magic numbers?  eg "-2" === "device"
>
>
> For what it's worth, I'm quite happy to consider incompatible changes to the time provider API
> so long as this includes eliminating the global lock.  Now that the lockset modify lock has
> been eliminated, the generalTime global mutex is the major contributor to coupling between
> high and low priority scan tasks.