search

epics-base / pva2pva

PV Access gateway/proxy and EPICS Process Database integration
https://epics-base.github.io/pva2pva/
Other
4 stars 13 forks source link

Question about the performance of pvaccess. #58

Open zhuzzzzzz opened 1 year ago

zhuzzzzzz commented 1 year ago

I write a record like this: record(calc,"spam0") { field(INPA, "spam0.VAL CP") field(CALC,"A+1") } Then I start two terminals to monitor the value change of spam0, as you can see in the picture below, the left terminal runs camonitor and right pvmonitor. But I found that in the pvmonitor there exists a lot of value loss(it is supposed to +1 each time) while in camonitor it looks good. Does this mean pvaccess has a bad transmission performance compared with channel access? image

ttkorhonen commented 1 year ago

Michael may comment on this particular case, but in real use (at ESS) pvaccess has a much better transmission performance than channel access (which is not bad either, to be clear.) Especially if one has a mixture of scalar and array PVs.

This is what I see now:

Screenshot 2023-05-25 at 12 20 35

(sorry that I keep updating the comment, I made a few tries to improve the screenshot.)

mdavidsaver commented 1 year ago

Performance is going to vary somewhat by system. My rule of thumb is the CA is more efficient for scalar values, while PVA does better with array values. There are a mixture of design and implementation details which contribute to this. eg. CA has a simpler, but less flexible, wire encoding scheme. However, in current CA implementations do a lot of copying by value. While barely noticeable for scalar values, this adds a lot of extra work for arrays. With PVA, the wire encoding scheme is more flexible, but also more complex, which adds overhead. However, PVA implementations handle arrays by reference, eliminating much extraneous copying.

Also, as @ttkorhonen mentions, current PVA implementations do a better job of "fairly" balancing when different PVs with different data sizes are updating a different rates over the same TCP connection. eg. A long standing issue with CA implementations allows PVs with large data size to "starve" other smaller PVs. This is commonly encountered when trying to route an image PV through a cagateway, which tends to adversely effect all other PVs coming through that cagateway. PVA gateways don't have this issue.