![]() |
![]() ![]()
Experimental Physics and
| ||||||||||||||
|
Without any testing, just from an architectural perspective... In your existing application, in that IOC process, the state machine is a CA client and the EPICS process database is a CA client. I don't see why the process database being connected to 2000 external PVs would show significantly different behavior compared to the SNL state machine being connected to 2000 external PVs. That said, with a "next generation" SNL machine connected to proxy records you will see added latency, as everything needs to go through one layer of records. But with timestamps being forwarded (TSE=-2), that shouldn't affect your aggregation algorithm too much. An SNL state machine is not special as a CA client. If you see large performance differences between SNL code and a client application, you need to find the reason. Could be programming language, application design and architecture (threading), library stack, host performance, networking, ... Generally, I would consider such combination and aggregation tasks typical middle layer services. One of the motivations for PVAccess is better support of such services, and a thing like "global beam position" is an excellent example of the structured data that we had in mind for that. Cheers, ~Ralph
| ||||||||||||||
ANJ, 10 Mar 2025 |
![]() · Download · Search · IRMIS · Talk · Documents · Links · Licensing · |