LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP/Stream performance tied to logging and/or GUI events?

I'm experiencing a very puzzling issue. Has anyone see or know of a relationtionship between UDP (or Stream) network performance and GUI mouse events and/or the file write function?

 

I've developed a "thick client" that communicates to/from my Windows Host PC and a LabVIEW RT target (cRIO-9022). The RT system has a timed loop (control loop) with 2 sets of RT FIFOs sending/receiving data to/from two communication loops using UDP to/from the Host Windows PC. On the Host Windows PC there are corresponding two loops for the UDP connections (to/from RT). Data is sent or received from the Host comm loops through Queues. There are Queues that send/receive some of the data to/from a GUI loop (i.e. all the control and indicator terminals). Additionally some of the data is sent to/from an "algorithm" timed loop.

 

The test that I set up was trying to evaluate what the nominal "network loop rate" was. To do this I created a cluster with two paired time-stamps {t_new, t_loop}. I generate a new time-stamp value, t_new, in the RT control loop, plug it into the cluster and send the cluster through an RT FIFO over to the first UDP loop to be networked over to the host. On the host the receiving UDP loop sends the cluster through a queue to the "algorithm loop". The "algorithm loop" copies the "t_new" value into the "t_loop" cluster value. The cluster is then send to the outbound UDP loop through another queue and is then networked back down to the RT system. The receiving UDP loop on the RT system then sends the cluster to the control loop through a another RT FIFO to finally "close the loop". 

 

This path results in clusters getting the to the host that record the "network loop rate" between the RT timed-loop and host 'algorithm' loop and back. 

 

My question stems from two very odd observations:

 

  1. the "network loop rate" significantly increases when I produce a mouse event on the VI scroll-bar on the host GUI VI. I've seen the "network loop rate" speed up by a factor of 20x while my mouse button is down on the scroll bar. However, when the mouse is released the "network loop rate" returns to the slower rate. <head scratcher>  If anything I would have expected it to slow down not speed up.
  2. I see a similar speed up I enable an additional loop on the host that begins writing the data to file  (received through another queue from the inbound UDP comms loop). 

 

I'm not done debugging this but I'm getting conflicting observations. I *believe* observation #2 could be related to a poor choice of timeout somewhere in the chain of the data path (control loop >> FIFO_comms >> UDP_UP >> Q_algo >> algo >> Q_comm >> UDP_Down >> FIFO_control. The data being logged gets splits off as follows ...UDP_UP >> Q_logging >> file write loop.

FIFOs have a depth of 2, Queues have a depth of 1.

 

(I'm sorry but I'm not in a position where I can post the codes.)

 

I've looked into the various timeouts and have not found a source of the problem. Even *if* #2 is explainable by timeouts and/or FIFO/Q depth configurations (which I'm not convinced that it is) it does not explain observation #1. 

 

So, I turn to the community. Does anyone see something that I am not? 

 

Thanks in advance...

 

 

0 Kudos
Message 1 of 3
(2,704 Views)

It sounds a little bit like a thread-switching thing to me? I wonder if it's something to do with the UI thread having less to work to do while scrolling - perhaps because it's having to redraw the whole panel as you scroll which might actually be less work than updating the control/indicators in a tightly timed loop, have overlapping controls/indicators or if you're using lots of property nodes to update values.

 

Is it possible that it is actually slowing down, and the fact you're seeing it 'faster' is because it's trying to catch up after the fact? Normally if you move a panel around a lot or do lots of scrolling it causes the CPU usage to go up (and as such might cause your program to lag).

 

What is the spec of the PC you are running on (how many cores?) and what's the CPU usage of your program like?

 

Without seeing some sort of code (perhaps try removing the sensitive parts) it's going to be pretty difficult to help you diagnose.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 2 of 3
(2,618 Views)

@Sam_Sharp wrote:

It sounds a little bit like a thread-switching thing to me? I wonder if it's something to do with the UI thread having less to work to do while scrolling - perhaps because it's having to redraw the whole panel as you scroll which might actually be less work than updating the control/indicators in a tightly timed loop, have overlapping controls/indicators or if you're using lots of property nodes to update values.

 

Is it possible that it is actually slowing down, and the fact you're seeing it 'faster' is because it's trying to catch up after the fact? Normally if you move a panel around a lot or do lots of scrolling it causes the CPU usage to go up (and as such might cause your program to lag).

 

What is the spec of the PC you are running on (how many cores?) and what's the CPU usage of your program like?

 

Without seeing some sort of code (perhaps try removing the sensitive parts) it's going to be pretty difficult to help you diagnose.


Sam,

 

Thanks for the thoughts. The machine I'm running this on is a 12 core 16GB Windows 7 machine. I don't have the CPU usage right now. Will look into this and reply later. Will also look into trying to reproduce this in a simplified code that I can post.

 

 

0 Kudos
Message 3 of 3
(2,588 Views)