LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Slow TCP duplex handling on remote connections


Ben wrote:

 

Single element queue version.

 

Please forgive me if you knew this already but I do not rember seeing your name in the cross-posters list so let me ask...

 

Have you heard of LAVA ?

 

Were you aware they have a OOP sub-forum ?

 

I am not trying to chase you away (may it not be so!) but wantd to makes ure you were aware of that resource. There are many GOOP developers on that forum and they use the single-element-queue technique.

 

AS for me...

 

When I get my team up to speed on LVOOP using shift registers, I may migrate to the other techniques but for now the complexities involved in getting the data will only make it harder for me to convert them.

 

Ben


I am aware of the LAVA people. I looked into their implementations and I just could not force myself on giving up on the simplicity of value based classes, and still keep the power of reference based classes whenever I might need them during execution. So I deviced this "trick" base class.

 

With this solution, I am sitting in the middle, using ref whenever I need it and value most of the time, with the same class. Hence the name "Intermediate".

 

So I guess I'll stay over here since I use the ref lock/unlock as sparingly as possible. Even though efficient, they have an overhead compared to value based data access.

 

Roger

0 Kudos
Message 31 of 63
(1,519 Views)

Back to the topic.

 

Is there a way to set the TCP_NODELAY on a SBRIO?

 

Roger

 

0 Kudos
Message 32 of 63
(1,479 Views)

RogerI wrote: 

Is there a way to set the TCP_NODELAY on a SBRIO?


According to this post (from an NI employee), Nagle's algorithm is disabled on all RT targets as of LabVIEW 8.6.1.

 

If you're still seeing throughput problems despite this, is UDP an option for your application?

Message 33 of 63
(1,457 Views)

nathand wrote:

RogerI wrote: 

Is there a way to set the TCP_NODELAY on a SBRIO?


According to this post (from an NI employee), Nagle's algorithm is disabled on all RT targets as of LabVIEW 8.6.1.

 

If you're still seeing throughput problems despite this, is UDP an option for your application?


 

Nathan, thanks for the help!

 

I am currently seeing about 2Hz when testing between a SBRIO target and windows machine(with the TCP_NOWAIT set), and about 200Hz between two windows machines both with the TCP_NOWAIT fix.

 

Maybe Nagle's algorithm is still in place for some reason on the RT target? I am using the following software, see the attached picture.

 

 

SBRIO.jpg

 

 

The target does not seem to be running at its limits either:

 

 

SBRIO2.jpg 

 

 

Regarding UDP: TCP is a bit more robust as I can be sure that no packets are lost or out of order?

 

Roger

 

Message Edited by RogerI on 03-30-2010 03:19 PM
Message Edited by RogerI on 03-30-2010 03:20 PM
0 Kudos
Message 34 of 63
(1,437 Views)

RogerI wrote: 

I am currently seeing about 2Hz when testing between a SBRIO target and windows machine(with the TCP_NOWAIT set), and about 200Hz between two windows machines both with the TCP_NOWAIT fix.

 

Maybe Nagle's algorithm is still in place for some reason on the RT target? I am using the following software, see the attached picture.

 

Regarding UDP: TCP is a bit more robust as I can be sure that no packets are lost or out of order?

In that case we'll have to hope an NI engineer chimes in; I don't have access to an sbrio to do any testing.  NI switched real-time operating systems at some point (from PharLap to VxWorks) so maybe that article referred only to one of them.

 

As for UDP, do you have a long network between the server and client?  If you're using a crossover cable, or working within a single office where there are a few switches and only one possible route between the two systems, it's highly unlikely you'll lose packets or receive them out of order.  You can also implement your own scheme to guarantee ordering if it turns out to be necessary.  It looks like with your OOP approach it wouldn't take long to write a UDP version and see how it works; if you do, I'd be curious to know how the speed compares.

0 Kudos
Message 35 of 63
(1,400 Views)

nathand wrote: 

As for UDP, do you have a long network between the server and client?  If you're using a crossover cable, or working within a single office where there are a few switches and only one possible route between the two systems, it's highly unlikely you'll lose packets or receive them out of order.  You can also implement your own scheme to guarantee ordering if it turns out to be necessary.  It looks like with your OOP approach it wouldn't take long to write a UDP version and see how it works; if you do, I'd be curious to know how the speed compares.


If you start adding your own protocol on top of UDP to preserve packet order ad such you may be better off going back to a TCP connection. TCP will do this and more and the stacks are highly optimized. A roll your own solution even if it is doing less may not be as optimized and therefore will perform no better than the TCP solution with less functionality.

 

I do agree though if you have a relatively small and clean network environment a UDP data stream can be quite reliable.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 36 of 63
(1,397 Views)

@Mark Yedinak wrote:
If you start adding your own protocol on top of UDP to preserve packet order ad such you may be better off going back to a TCP connection. TCP will do this and more and the stacks are highly optimized. A roll your own solution even if it is doing less may not be as optimized and therefore will perform no better than the TCP solution with less functionality.

I do agree though if you have a relatively small and clean network environment a UDP data stream can be quite reliable.


Except that UDP sends packets immediately, cutting out the Nagle algorithm/TCP_NODELAY problem.

0 Kudos
Message 37 of 63
(1,394 Views)

Nathan, Mark, thanks for the input.

 

Maybe a NI engineer could give some input regarding this latency issue?

 

The RT target will be controlled from a Android or iPhone device on a 3G network.

 

I am basically done with the client and server part, if it just wasn't for the latencies......

 

I am thinking padding data to force an immediate send, but that seems like a crappy solution?

 

Roger

 

0 Kudos
Message 38 of 63
(1,377 Views)

Any NI engineer with some time to look into this and help me out?

 

Roger

 

0 Kudos
Message 39 of 63
(1,279 Views)

RogerI wrote:

Any NI engineer with some time to look into this and help me out?

 

Roger

 


I guess not? Easter?
I went ahead and "solved" it myself with a classic LV "fix": I pad every send. 
  • When working on SBRIO, pad each TCP Send so that each send is at minimum 1024bytes. 
  • On windows use the fix suggested by Nathan in this thread.
 The resulting performance is about 200Hz on a windows machine on my local net. For the SBRIO, the final speed is about 30Hz, which should be enough.
 
Roger
 

 

Message 40 of 63
(1,259 Views)