Comment 4 for bug 1722530

More input re the need for a 64bit userTag.

SLAC is well into the design and implementation of LCLS-II, and a 64 bit pulseId is baked into the design for all components, including non-EPICS components like our data acquisition.

Thus, while I appreciate Michael's suggestion that there is some redundancy in using a 64bit userTag, not having one makes it difficult to reconstruct the upper 32 bits as that would be facility specific.

In our EPICS timing module driver, we have access to the timing stream with 32bit sec, 32bit nsec, and a 64bit pulseId that increments at 1Mhz. A 32bit pulseId would roll over after approx 4300 sec, so while it's messy to have to provide an API for converting from an epics::pvData::TimeStamp object to our 64bit pulseId, a single reference point would suffice.

Since we'll have a unique mapping from each 64bit pulseId to specific 32bit sec and nsec values, we also think we could convert epicsTimeStamp objects w/ just uint32 sec and nsec to our 64bit pulseId by keeping a few additional reference points as needed to handle any long term drift or ntp corrections.

For V3 clients, our current EPICS server implementations are publishing the upper and lower 32 bits of each pulseId as separate CA PVs, requiring V3 clients to monitor the pulseId PV's separately and do their own correlation between epicsTimeStamp and 64bit pulseId.

We're now starting to look at how V4 clients can handle this and would really love to avoid similar hacks for V4.