Experimental Physics and
Industrial Control System

Excuse me, there's an "0" too much slipped in while typing …
~ 2 MByte  100 times/s. 


> On 22. May 2019, at 18:19, Heinz Junkes via Tech-talk <[email protected]> wrote:
> 
> I have a data source (VMEbus-digitizer, RTEMS, EPICS 7) that sends 
> with pvaPut Dataframes ( ~ 2 MByte )  about 1000 times/s  to a server which holds 
> a Pv. 
> 
> PV-Structure:
> 
> structure
>    structure value
>        double[] column0
>        double[] column1
>        double[] column2
>        double[] column3
>    string[] labels
>    string[] units
>    string descriptor
>    long counter
>    structure[] attribute
>        structure
>            string name
>            any value
>            string descriptor
>            int sourceType
>            int source
>    double[] digitizerTimeStamp
>    structure timeStamp
>        long secondsPastEpoch
>        int nanoseconds
>        int userTag
>    structure alarm
>        int severity
>        int status
>        string message
> 
> 
> What is the proposed way to guarantee that the transmitter will get rid of its data within 1ms, regardless of how many monitors are attached to the PV?
> And if possible also independent of the load of the server. Can this even be guaranteed with pvAccess? 
> Are there such things like caches, pipelines etc.? Or do you have to implement it yourself?
> 
> Danke,
> Heinz

Attachment: smime.p7s
Description: S/MIME cryptographic signature

References:

question about pvAccess/pvData, pvPut Heinz Junkes via Tech-talk

Navigate by Date:

Prev: question about pvAccess/pvData, pvPut Heinz Junkes via Tech-talk

Next: registerRecordDeviceDriver.obj unresolved external symbols Thomas, Patrick via Tech-talk

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <2019>  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: question about pvAccess/pvData, pvPut Heinz Junkes via Tech-talk

Next: registerRecordDeviceDriver.obj unresolved external symbols Thomas, Patrick via Tech-talk

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <2019>  2020  2021  2022  2023  2024