Improving Performance for SystemLink Writes

NIVeriStandAdd-Ons / Data-Publishing-Service

Data Publishing Service allows users to publish NI VeriStand channels as LabVIEW shared variables. User can connect to the published shared variables e.g. using the Data Dashboard for LabVIEW.

Other

2 stars 2 forks source link

Improving Performance for SystemLink Writes #3

Closed agomez08 closed 4 years ago

agomez08 commented 4 years ago

Main Changes:

Moved Channels writes to a separate loop to make timing more accurate and independent from timeout of event structure in main loop.
Implemented batch writes for SystemLink tags with Multi Write.vi.

Results:

Publish.Period_ms = 250 ms.

Previous version: Data was updated in the server at ~2.5 Hz (~400 ms).

New version: Data was updated in the server at ~4 Hz (~250 ms).

Publish.Period_ms = 100 ms.

Previous version: Data was updated in the server at ~2.5 Hz (~400 ms).

New version: Data was updated in the server at ~10 Hz (~100 ms).

*Using 50 channels for all the tests above.

Fixes #2

eatondan commented 4 years ago

This is great! The only question I have is why is there a wait in the flush? Can we remove that? It looks like you handle all the errors in the lower loop.

agomez08 commented 4 years ago

I added that wait because in one instance while testing I found the next behavior:

Command was en-queued to update SL tags.
A very short time ago, the user un-deploys from VeriStand.
The top loop starts closing references, including the handle for SystemLink Communication. At this point the bottom loop has already extracted the command from the loop.
The bottom loop gets to the point where it tries to implement the SL Write, giving an error since the handle was already closed.

To avoid the scenario below I put the 1 second wait after flushing the queue to make sure the bottom loop finishes processing the last command sent before closing all of the references.

Hope this makes sense, let me know if you have any different approach in mind.

eatondan commented 4 years ago

What if I changed the code to this:

eatondan commented 4 years ago

I believe the above scheme would use your better write multiple tags, improve the overall loop rate (because now it is timed using a wait multiple instead of a static wait), and simpler code with no queue issues.

agomez08 commented 4 years ago

@eatondan , I think that will work as well! The other reason why I moved it to another loop is because my understanding is that code inside an event structure would always run in the UI thread, not sure how this could affect the SL writes though.

Let me know if you'd like me to test the approach you suggest and check if there is any significant difference.

eatondan commented 4 years ago

You are correct on the UI thread. I am impressed as most people don't know that. I put a timed sequence structure around the loop which makes everything single threaded in a different system ( I believe). That made it good enough. I am going to make a couple other small changes and post the update by Friday.