AGENDA 12 March 2014 V4 Core Day


9:00  - pvData status - Marty

10:00 - pvAccess status - Matej

         - status (15')

         - facts and myths about large data transfer (30')

         - pvMS (multicast), zeroMQ (30')

         (Note pvAccess security session on friday, joint with DISCS)

11:00     - Services API

         - Proposal for standardization (*Matej*)

         - GetPut vs RPC (*Marty*)

           Objective: Will we make a standard, or a pattern for pvs

           with arguments and services?

11:45 - pvDatabase status - Marty

12:30 - Lunch

13:15 - CSS and PVManager joint session.

   - CSS and PVManager stage of integration - Matej/Gabriele

   - PVManager plans - establish priorities - Gabriele

              C++ implementation


              Performance measurements

15:00  - *Gateway*

     Requirements and plan for v4 Gateway (*??*)

16:00  - pvRequest and the monitor options (Ralph)





OBSERVERS: Gary Trahern (ESS), Kevin Meyer (Cosylab), Miha Vitorovič (Cosylab), Miha Reščič (Cosylab), Vasu Vuppala (MSU), et al.


NEW TOPIC: Marty reviews pvData


MK: 2 new types union and variant (variant is any type, union choice of finite set)

Marty demos constructing and assigning to variant and union.

MS: Easier way to construct unions using FieldBuilder

// 1. creates new instance of PVFloat


// 2.

pvUnion->set(“float”, pvFloat”);




RL: Thread safety

MS: pvData not thread safe.You have to care of this yourself.

PVFloatPtr  a =pvUnion->select(“float”);.

PVIntPtr b = pvUnion->select(“int”);


MS: No exception on writing to “a”

RL: That’s bad.

AI On MK: to provide documentation on unions. Predict peoples mistakes. And avoid using type names as variable names. GW will be dumb user representative for union additions to pvData documents.

AI URL: https://sourceforge.net/p/epics-pvdata/action-items/99/

MS reminds us that he wrote a cookbook for pv* stuff. [where is this?]

DH:  1 Gotcha is: get on union gets field. get on smart ptr gets ptr

MS: Yes. Avoid using ptrs. Always use shared pointers. Pass as const ref as arguments.

DH Can’t use covariant return types with smart pointers.

MK reviews Michael Ds’s array AP and convertI.

Swapping in data. Reduced code size by rewriting convert.

MK: Old API deprecated. These method should go.

RL: Never a release with methods marked as deprecated.

MS: Not enough users to worry.

MS/DH/MK get rid of deprecated API.

MK to add list of changes for API of arrays to pvDataCPP documentation. Examples can reference Matej’s cookbook. [Added to AI on updating documentation]

Cookbook URL: http://sourceforge.net/p/epics-pvdata/pvDataCPP/ci/default/tree/documentation/pvDataCPPCookbook.txt

AI addendum: MS update documentation on unions and arrays.

AI URL: https://sourceforge.net/p/epics-pvdata/action-items/99/

MS: Vx works 5.5 issues.

MK: For pvDataCPP ok on all OSs supports. Not necessarily older Vx works

MK: Like all builds in same place.

RL: Why? Places work on AJ as behind firewall. Cloudbees is public.

RL/MK agree violently. Keep CBs but add builds to APS builds.

AI: On AJ:  Correct names of windows builds in APS jenkins, win64 -> win32, since

they’re actually win32

AI URL: https://sourceforge.net/p/epics-pvdata/action-items/100/

RL: Should add windows 64 bit build.

MK: Even in Java bitset didn’t work w.r.t. serialisation

MK reviews monitor  queue size

2 options

queue size = 1;

queue size >= 2



Discussion of const. DH outlines suggested changes.

MS: Have to get const consistent or it won’t work.

DH: Agree. Will up priority on looking at this.

AI:On DH to review/implement and make consistent, use of const for methods in all C++ modules of V4 in particular, but also arguments and structures.

MK: Typedefs for smart pointers? Not yet. Add most common if needed.

PVField review :antics

MK: Old methods in PVFields not needed, should go before someone uses them.

Get rid of toString(StringBuilder) methods in C++ - use C++ idioms

MS: Need to get rid of String. ->std::string.

Should we still provide toString() convenience method.

Discussion of pros and cons of std library and need of logging api.

MK: Keep toString().

AI on MS: To clean up toString and related methods. Remove builder methods and add convenience toString() in pvDataCPP.

AI on MK. In pvDataJava make toString robust with respect to array

PVStructure discussion:

MK get rid of append remove methods.

MS: Added new get field methods. What to do with old methods.

DH: Deprecate methods.

MS: Java version is horrible because of generics.

GW: Concern about old methods going.

Discussion about Python bindings. Need to discuss with Sinisa.

More discussion on get methods.

TK: Prefer new methods.

DH: Array syntax horrible and error prone.

MK: Mark as deprecated

GW: Rather deprecated methods not removed in next release

RESOLUTION: Old subfield access methods will be deprecated, and replaced with templated and generics signature methods. We will NOT remove the methods prior to next release, but rather after next release.

RES URL: https://sourceforge.net/p/epics-pvdata/resolutions/19/

AI on MS: Mark type specific subfield access methods deprecated.

Discussion of type of length and offsets and arguments in ChannelArray

MK: These should be size_ts no ints

MS: -1 is used as get everything. Should be max size_t (default argument).

AI on MS: Change API and protocol of ChannelArray for; 1) replace offset and count types of int with size_t, 2) add argument for stride. count of 0 to mean whole array remainder after the offset [so offset == 0 and count == 0 means whole array].  

DC asks for clarification on whether new method.

MS: Default args in C++, overloads in Java

Discussion on setting length and capacity

AI on MS: Go through channel array API and make consistent with shared vectors with respect to setting length and capacity.

Discussion on ChannelGet

MK: Suggestion (from MS) that should get back introspection data on getConnect()  and more information back on getDone() (ChannelGet, PVStructure and bitset in addition to status).

MK: Also add bitset tp put get.

GW: 800+ downloads in last year.

RESOLUTION: New API for channel gets and channel putget  for Java and C++ so that the introspection interface is returned on channel acquisition (channelGetConnect).

The current definition for Java is:

public interface ChannelGetRequester extends Requester {
   void channelGetConnect(Status status,ChannelGet channelGet,PVStructure pvStructure,BitSet bitSet);
   void getDone(Status status);

interface ChannelGet extends ChannelRequest {
   void get(boolean lastRequest);

Change to

public interface ChannelGetRequester extends Requester {
   void channelGetConnect(Status status,ChannelGet channelGet,Structure structure);
   void getDone(Status status,ChannelGet channelGet,PVStructure pvStructure,BitSet bitSet);

interface ChannelGet extends ChannelRequest {
   void get(boolean lastRequest);


NEW TOPIC: Matej reviews pvAccess status and large data transfer


MS: New things:

1) Multi-platform support

Linux, Mac OS X

Win 32 (64 bit) on MS compiler (not Cygwin)


VxWorks 6.8, 6.9 not 5.5

Test on Linux only

2) Support for Unions/Variants and their arrays

3) Stability

Codec based on pvAccess core - easy to add new transports e.g.async I/O, shmem, reliable UDP, zeroMQ

4) eget/pvget/pvput improvements e.g. read from std i/o file

5) Ported to new array and convert API is really good.

6) Studying TCP/UDP transports, RTPS (RTI DDS) multicast, discovery

Java prototype called pvMS

DC raises the dual existence of eget and pvget.

MS: eget understands NTs, pvget doesn’t

Discussion of whether need 2 or 1. MS doesn’t want pretty print etc. in pvget

DH: Want to put string to enum PV

MS describes Myths and facts about large data transfer.

MS: Bandwidth delay product

(the product of a data link's capacity (in bits per second) and its end-to-end delay (in seconds)

TCP window limited to 64KB

TCP window scale option

TCP buffer auto-tuning

TCP auto-tuning get disabled if manually call setsockopt with SO_SNDBUF/RCVBUF

MS: TCP is boring old-fashioned but still great.

Bad because is P2P. Push-pull bottle neck sending same data to multiple workers. Need multicast.

Multicast is over UDP

Not reliable, no congestion control

Multicast offloads fan-out on switch

some switches don’t support IGMP and change multicast to broadcast.

TCP is reliable if receiver

is slow (or block) sender will be slow.

UDP is connectionless, scales, light

Perfect candidate for unreliable pvAccess monitoring

MS: Changed fields requires reliable transport.

RL: Like video streaming, send complete structure every so often.

MS: Yes, or client signal if it’s missed something.

Does this UDP solution exist?

PGM (pragmatic general multicast)

(open pgm implementation)

RTPS (real time publish subscribe)


Expensive. Has community edition

pvMS: Prototype. Java only.


NEW TOPIC: Gabriele’s talk on pvManager and Graphene, status and proposals for further work.


Problem data from multiple sources V3, V4 etc

Middle layer (between source rate and client rate) does computation, combines values, prepares plots.

Pluggable services were added: service registry, services added; CF access, database access, etc.

Status: framework functionality has been growing, starts being used outside CSS-Studio, increasing contributions (COSYLAB, UMich, ITER, FRIB).

Current problems: CS-Studio dominates focus, no clear support structure, no well thought out contribution process.

Way forward: treat this layer as its own top level project “DIIRT” (data integration in real time), better release planning for diirt, increase effectiveness of contributions.

diirt web site has been created.

Cloudbees CI jobs automagically pull/push from all affected tools and projects, triggering new builds of target projects. E.g., a diirt dev branch of CS-Studio rebuilds after a change in graphene.

Integration Test Framework: should include corner cases, power downs. Should be able to drop the tests into an existing context.

Scripts on server and client being started, results collected after 15 mins.

Considerable amount of cases is being covered already.

Martin Konrad and Andrej Babic are improving the framework, results have to be integrated.

Hope: this will result in one FLINT framework for running integration tests.

Need to run tests on differents sets of OS/hardware/version.

Clients: CS-Studio (mostly BOY)

Possible diirt improvements: performance optimization, improve graphene widgets.

Implemetations other than Java:

Python: Jython vs. Pure Python implementation: both approaches have their pros and cons.

C++: harder to write and support

Python / embedded JVM: performance? Can we keep the interface reasonable?

MATLAB: Simple example needed. GC has no access to MATLAB and no use cases.

There is MATLAB available from free on the RaspberryPi platform.

NM: MATLAB does not support a clean callback interface.

Q: Do any of the Qt packages implement a data concentration layer?

A: The PSI package does.

Web Gateway using web sockets: on top of CA, as web sockets allow server updates.

Should have general purpose web gateway, powered by diirt and web sockets?

Q: We need some agreement on the data types used (VTypes, NTTypes). Representation as JSON or FastXML?

GC: Might need different serialization for the same VTypes.

About 10% of the audience would use a web service if it existed. Vasnu and Greg to help GC with the specification.

Idea: pvA Gateway on top of pvmanager. Could handle data aggregation and processing, protocol conversion, and cache service responses.

GW: We would probably need a pvA Gateway sooner than a web gateway.

GC: Both services share a bunch of functionality - much things could be shared.

BD: Req: people want to look at the status of their subsystems on their browser, from home.

RL: WebOPI is a solution for that.

pvAccess Gateway is higher priority than web sockets on top of pvAccess.

Historic Data: combine archived and life data in one cache, ITER will be contributing to that.

Functions: Better support for disconnect/alarm/time, adding element-wise functions.

Support for N-Dimensional Arrays: students working on intensity graph (hopefully ready by end of May)

Q: Are some NTTypes to be dropped?

GW: Some rarely used types might be getting simplified. The NTTypes are in public draft status.

V4 Integration: COSYLAB has done datasources and services. Presented to CS-Studio as an XML service specification for the service plug-in API.

GC showcases the EXEC service inside a BOY panel.

DISCS Integration: Proteus is embedding pvmanager (for CA access). Should more actively try DISCS service integration through diirt (and CS-Studio)

Diirt services are *not* general purpose. Each underlying specialized service will need special clients to do the special tasks (e.g., manipulation of CF data).

RL: What about authN/authZ?

GC: The wrapping service layers should take care of this.

Scope: All data can be accessed in diirt != all data access should use diirt.

For services, only calls useful for generic clients should be supported.

For datasources, the situation is more complicated.

Only the general part of protocol and service features (~common denominator of the features) should be accessible through diirt.

GW: Priorization? pvmanager as a base for the pvA Gateway?

GC: Needs help from Matej for that.

GW: Large data sets are a primary use case for pvA, so the pvA Gateway has to have streaming capabilities.

GC: If the pvA Gateway needs to replicate exact and full pvA behavior, it needs to be a pure pvAccess application.

pvManager, otoh, can just forward things as Java objects.

GC: What do you get from using pvmanager in the Gateway?

GW: protocol conversion, rate change.

AI on Ralph: List the functionalities that might be needed for a framework for creating Gateway-type applications for EPICS V4.

Q: Vtypes or NTTypes? Will the twain ever meet?

GC: NTTypes are focused on serialization, performance, and other on-the-wire issues.

VTypes are focused on API use and wrapping different types from different datasources.


NEW TOPIC: Data Archiving: Nikolay Malitsky


NM outlined different approaches for no-sql databases for archiving.