Re: Support for 64 bit integer Normative Types?

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

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