Re: Support for 64 bit integer Normative Types?

[Sky Brewer via Tech-talk <tech-talk at aps.anl.gov>]

Yeah, DBR_V4_GENERIC_BYTES is not efficient. It stores the pva encoding structure with every message. I’ve thought about making a version where the encoding is stored in the type as well instead, but you run into the ‘union’ and ‘any’ types problem. 

However, if you use compression, I will imagine you would gain most of the data storage back as the message type is duplicated it should compress very well.

Creating a ‘int64’ or ‘long’ type makes sense regardless. 

It would be nice to maybe make a 

DBR_V4_GENERIC_FIXED_TYPE_BYTES type as well 

where we store the message type in the metadata of the file rather than in each event. Where it supports only pvData without ‘union' or ‘any' in the structure. I’m not sure of the benefit of doing this vs implementing say the NTTable or NTMatrix etc. 

If I were to start the protobuf spec from scratch, I would probably try write the full pvaData spec as a protobuf spec and then add the nt types on top. But that’s probably overkill.

Sent from Outlook for Mac

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>
Date: Tuesday, 29 September 2026 at 23:03
To: William Badgett <badgett at fnal.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Support for 64 bit integer Normative Types?

On 9/28/26 2:39 PM, William Badgett wrote:

Let me elaborate further:   The NTScalar with an int64 value field works fine in the sense of only sending out parts of the structure that have changed in value.      But when we try to int64 the event size on the Archiver Appliance PV details I see the per event size for int64 quite a lot larger than int32:

Int32 19.5 average bytes per event — DBR_SCALAR_INT DBR type

Int64  686.6 average bytes per event — DBR_V4_GENERIC_BYTES DBR type

So this was really more of an archiver appliance question — my inference is that int64 are archiving the full data structure rather than what has changed.

Correct.  The AA data model was originally defined to follow the CA protocol, which can not transport 64-bit integers.  This model has been extended to support PVA by mapping some common PVA structures to the equivalent CA types.  However, if this is not possible the fallback is to store arbitrary PVA data structures, which as you found this is less efficient.  Also, there are limitations on what queries can be made.

Supporting 64-bit scalar/array natively seems a reasonable addition.

https://github.com/archiver-appliance/epicsarchiverap/issues/550

thanks!

---

From: Michael Davidsaver <mdavidsaver at gmail.com>
Sent: Friday, September 25, 2026 11:53 AM
To: William Badgett <badgett at fnal.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Support for 64 bit integer Normative Types?

 

[EXTERNAL] – This message is from an external sender

On 9/25/26 9:19 AM, William Badgett via Tech-talk wrote:

Is there any plan to create a centrally supported signed or unsigned 64 bit integers as the value field in NTScalar ?

Like an int64outRecord?

https ://docs.epics-controls.org/projects/base/en/latest/int64outRecord.html

https ://docs.epics-controls.org/projects/base/en/latest/int64inRecord.html