EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: pvData introduction
From: "Johnson, Andrew N. via Core-talk" <[email protected]>
To: "[email protected]" <[email protected]>
Date: Fri, 27 Sep 2019 15:50:14 +0000
Hello Kay,

On 9/27/19 7:33 AM, Kasemir, Kay via Core-talk wrote:
Only shortcoming would be that 'info' operations hands you an empty container.
So instead of for example
   StructureDescriptor "timeStamp": { LongDescriptor "secondsPastEpoch", IntDescriptor "nanoseconds", ... }
you get a
   PVAStructure "timeStamp": { PVALong "secondsPastEpoch" = 0, PVAInt "nanoseconds" = 0, ... }
The caller of PVAChannel.info() needs to know that the obtained PVAStructure is empty, it's only meant to describe the data.
Nothing keeps you from printing the timestamp with secondsPastEpoch, nanoseconds, .. and then you see that all values are 0, NaN, [].
Yes, that means inside the client you now have a PVALong with 8 wasted bytes for the long value = 0, a PVAInt with 4 wasted bytes for the int value = 0.
But in the bigger picture, those long, int, double values don't waste much space.
Would be bad if fetching the info for an NTNDArray got the actual int[2,000,000] data array, but all you get is int[0].
At one point we had array types that had a fixed maximum array length. Do those types still exist and can you find out what the maximum length of an array is? The idea being that an embedded client or server with limited RAM would be able to allocate storage for the array at connection time based on that max length, and would never have to free a too-small buffer and allocate a larger one.

The IOC already has that kind of limitation; you can't resize a waveform record at runtime and it would be better for clients to find out before the data starts going over the network that they can't put 2GB of data into a 3 element waveform. I don't know if/how the PVA protocol handles that, but a CA server tells its clients what the maximum array size of a channel is at connection time.

The ability to communicate these kinds of limits is the one thing about your Java rewrite that concerns me, I hope it's not an issue (especially when a Java client is talking to a C++ server). I might have more concerns about API compatibility for a similar pvDataCPP rewrite though, given that the community has probably written a lot more C++ code calls the PVA modules than it has Java code.

BTW, have you talked to Greg White about the new Java API at all? He might have comments...

- Andrew
-- 
Complexity comes for free, Simplicity you have to work for.

Replies:
Re: pvData introduction Kasemir, Kay via Core-talk
Re: pvData introduction Michael Davidsaver via Core-talk
References:
pvData introduction Timo Korhonen via Core-talk
Re: pvData introduction Kasemir, Kay via Core-talk
Re: pvData introduction Timo Korhonen via Core-talk
Re: pvData introduction Kasemir, Kay via Core-talk

Navigate by Date:
Prev: Re: pvData introduction Kasemir, Kay via Core-talk
Next: Build failed: epics-base base-7.0-318 AppVeyor via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: pvData introduction Kasemir, Kay via Core-talk
Next: Re: pvData introduction Kasemir, Kay via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
ANJ, 27 Sep 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·