Slow TCP duplex handling on remote connections

[User002]

---

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

[User002]

Back to the topic.

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

Roger

[nathand]

---

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?

[User002]

---

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.

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

 

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

[nathand]

---

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.

[Mark_Yedinak]

---

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.

[nathand]

---

@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.

[User002]

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

[User002]

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

Roger

[User002]

---

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