Performance question on multi core processor

[t_houston]

I have run into a problem with lost data reading a high speed data socket.  It appears that the TCPIP read function is losing data.  I have independant verification that the socket is outputting a valid stream but occasionally when reading a packet, I experience data loss in the middle of a buffered read of a single packet.  It appears that the TCPIP internal queue/buffer is possibly seeing an overrun.  My code will automatically detect this but it is unacceptable. 

The program does quite a few other functions in other asyncronous loops at the same time.  The thought is that the buffered read simply gets interrupted and can't keep up. The other loops are set up to not hog the processor  I will be simplifying the program to only do reads and file writes, and no other parsing for debug purposes, but longterm I am breaking down the code into multiple VI's and will pass data between them using named queues.  The other VI's will be programatically launched as VIT's.  The reason for this is that from what I can see, if they are called as a subVI, all will reside in a single core of the processor.  The hope is that by launching them as seperate VIT's, they will end up in seperate cores and not bogg each other down.

Does anybody have any experience in getting an app to utilize more than one core.  I am running LV10 and an multi-processor 8 core XEON machine.

[altenbach]

You say TCPIP, which can mean TCP or UDP. What are you actually using? How busy is your network?

What is the typical data rate?

[Ben]

---

@t_houston wrote:

... 

Does anybody have any experience in getting an app to utilize more than one core.  I am running LV10 and an multi-processor 8 core XEON machine.

---

It could be as easy as using a Timed Seq Structure and take advantage of the "CPU" input node to target the CPU the code will run in.

Note:

All code that uses the UI will be processed in a single core so if the tTimed Sequence changes still shows idle CPU's your code may be running in the UI thread.

Ben

[t_houston]

Sorry I typed TCPIP by muscle memory.  It is the TCP buffered read.

[t_houston]

I didn't realize that if the different threads share the UI that they would run in the same core.  I guess it makes sense. 

If I launch stand alone VITs, each with its own panel, will they still always run in the same core?

[t_houston]

I am reading more than a thousand variable length packets (avg 64 bytes) per second.

[majoris]

Labview natively spreads things across threads, even in the block diagram. This is easy to show by taking a computationally expensive block (with no dependencies) and copy it on the block diagram. CPU usage will go up proportional to the number of blocks you drop until you saturate the cores.

Windows and Labview offer priorities for the threads at the VI level. Perhaps sleeping the other processes more and increasing the priority of your important tasks can make a difference?

[altenbach]

Thse are very small packets and you will never get the full network speed with those, still that's not that much traffic. Can you show us some code how you are reading this. Is it all one connection or do you have multiple connections?

Are the deviced connected directly on the same subnet or is there routing involved?

I would place the TCP read inside a no-wait loop and just shove the data into queue to be consumeed elsewhere in the code at leisure.

Each VI runs on multiple threads, and only the UI thread is shared between all. Except for UI updates, only code that is not safe needs to run in the UI thread. The bulk of the code does not.

What is your CPU load during execution (task manager).

[t_houston]

I tried sleeping the other threads more with no positive results.  The TCP read thread loop has no built in waits so it should be able to hog more resources than the other threads.  If I look at the system usage by core, everything seems to be running in one core.  The usage seems to run around 20-50%.  You would think everything should process fine.  I pass data from the read loop to the parse and save loops via queues.  I rarely see more than one item in the queues. 

I am looking at optimizing the Windows TCP buffering to see if that might help.  Another programmer was writing a similar program and independantly ran across this same issue with his code. 

I am looking at setting the Network Memory Allocation to support LargeSystemCache=1

[t_houston]

We are on a gigabit local net.  This is pretty much the only traffic on the net.  The packets are variable length so I have to read the first 8 bytes, parse the header to determine the packet length, then grab the remaining characters in the packet.  If the header appears well formed, I then stuff it in the queue.  If not, I close the socket, wait a few seconds, then reopen the socket and start over.  I have a couple of simple sections of code in that read loop that calculate time between packets and packets per second and display them, but that is all that is in the read loop.  The loop has no waits.  The parse loop and disk write loops both have wait statements.

The calculated peak burst rate of packets is probably in the 3k packets per second.