Search the Community
Showing results for tags 'read'.
Found 1 result
I am experiencing intermittent issues from a real-time application calling 'take' on topics. Generally it works as expected. If no data is available it does not block and the call completes in microseconds. Same case when there is data available with the call completes in microseconds. However occasionally a single call to 'take' completes anywhere from 2ms to over 20ms. It happens for both cases where there is data as well as when there isn't. Size of the data also does not matter as I see this with topic sizes from 40 bytes to 8000 bytes... This is causing issues as the calls are done by a process executing at 60Hz (and thus each frame only has 16.67ms to complete...) What conditions would cause a 'take' or 'read' to block? Details on the configuration: Using OpenSplice 6.7.1 Communication in question is only between 2 machines connected directly via 1Gb Ethernet. Both machines are running federated/shared memory mode and communicate using DDSI2E. I *am* running two separate DDSI2E services on each machine with a configuration provided by PrismTech as I have a need to communicate on two separate networks (with separate network cards...) However, the calls causing issues with blocking is on the DDSI2E service tied to the network cards directly connected between two machines. I do have durability service running on each but doesn't help if I turn off. The QoS is set as Reliable, Volatile durability with Keep All History, sorted by source timestamp, and min latency set to 50ms (also tried leaving at default of 0 as well.) I also have a lifespan of 300 seconds set on these topics. The process that is blocking on the 'take' call is running Real-Time scheduling and pinned to a CPU all to itself. All 'takes' are also done from a single thread All OpenSplice processes are also set to Real-Time scheduling and pinned to a different CPU. I have pre-allocated memory for doing the 'takes' on each topic. Memory is also locked for both the process calling 'take' and all opensplice services. Additional Notes: The blocking seems to occur when a backlog grows on some of the topic data. There are periods of time where the reader has to pause doing takes for a while and the history depth grows on some of the topics... There are other times where the sender sends a large burst of samples also causing a buildup of history (since the reader is only running at 60Hz and only does so many takes per frame). In both of these cases, this is where I see the spikes in 'take' time. I have tried adjusting the config files on both ends heavily, adjusting queue sizes, adjusting bandwidth, max packet sizes, network buffers, etc all with little effect. Any assistance would be greatly appreciated! Chris