Slow TCP duplex handling on remote connections

[Ben]

---

RogerI wrote:

Sorry for being a pain in the.... I take my LV G coding quite seriously and I want LV to be as great as other OOP languages. 🙂

I think I understand the motivation for Nagel's algorithm, but there must be a way of disabling such features when RT performance is desired?

Ben, your post came in just before I got a good response with a proposed TCP_NOWAIT fix and maybe this sorts out the latency issues?

Roger

---

Keeping in mind the Proverb "Give not assurity for a stranager." I don't think I will violating that by saying "listen to what Nathand as said." I have read many of his posts on networking and he is a resource I would use in a similar situation." He is up on the modern implementations an seems to have tred this path and is willing to share notes.

This topic is near and dear to my heart so please keep us updated on what you find. It's only a matter of time until someone else is going to be knocking on my cubicle wall asking a similar Q.

Ben*

* Co-author of the first Ethernet Sniffer developed in VAX-Macro, and run on a micro-VAX in about 1988. I only mention this as evidence that I know enough about this subject to know when I and being fed bull. Nathan is the real thing.  

Message Edited by Ben on 03-29-2010 09:01 AM

[User002]

Mark, 

The implementation I target is actually spawning threads (vi server calls), using the RT loops executing deterministically, that is, each connection is handled in its own "thread". Definetley parallell.

The communication is intended towards a SBRIO target where the RPC server resides. The client side implements a very thin API for communicating with the RPC server.

The API and protocol could be run from any device supporting TCP. It could in fact be another SBRIO. So we'll se how the TCP_NOWAIT fits the RT target. 😉

One thing LV is currently missing is good threading abstractions and debugging capability.

Roger

[Ben]

---

RogerI wrote:

...

One thing LV is currently missing is good threading abstractions and debugging capability.

Roger

---

After we get the network going as fast as we need, please take some time to explain to an old tech what those terms mean.

Ben

[User002]

It means a LV VI Server with some gold plating for OOP people. 🙂

Roger

[Ben]

---

RogerI wrote:

It means a LV VI Server with some gold plating for OOP people. 🙂

Roger

---

OK. When you get a chance, throw some OOP ideas at this discusion. I am still teaching myslef LVOOP based on the Craig Larman book and would love to see an hear more about how OOP soultions can help me out.

Ben

[User002]

Hi everyone!

Thanks for the help. The TCP_NODELAY fix seem to work well for my RPC calls. I am currently executing remote calls at about 200Hz between two windows machines, I guess this is quite close to the maximum attainable given the TCP/IP latencies between the machines?

Although, I didnt get it to work on the SBRIO. Is there a way to do this in the NI RT-OS domain?

Ben,

I'll give some oop ideas on that forum. I got some LV classes, and example usage, that might be of use for other people in the LVOOP community?

BR,

Roger

[User002]

---

Ben wrote:

---

RogerI wrote:

...

One thing LV is currently missing is good threading abstractions and debugging capability.

Roger

---

After we get the network going as fast as we need, please take some time to explain to an old tech what those terms mean.

Ben

---

When you get going strong on LVOOP, and have been studying and coding in some well designed OOP programs or framework, you can tell goodbye to all shift registers, local variables, typedef clusters in queues, hack "patterns" and never miss them for one second.

I used to wonder what OOP was good for, these days I wonder how I even could write one single LV program without it. It's a revolution.

Roger

[Ben]

---

RogerI wrote:

---

Ben wrote:

---

RogerI wrote:

...

One thing LV is currently missing is good threading abstractions and debugging capability.

Roger

---

After we get the network going as fast as we need, please take some time to explain to an old tech what those terms mean.

Ben

---

When you get going strong on LVOOP, and have been studying and coding in some well designed OOP programs or framework, you can tell goodbye to all shift registers, local variables, typedef clusters in queues, hack "patterns" and never miss them for one second.

I used to wonder what OOP was good for, these days I wonder how I even could write one single LV program without it. It's a revolution.

Roger

---

I use LVOOP extensively with SRs to remember the private data state from iteration to iteration since they allow working in place and they achieve the same end but in a cleaner fashion what can also be done with DVR (Data Value Refernce) or single-element queues.

So how do you maintain the state info without SR's ?

OR

How do you write Loops without SR's ?

Ben

[User002]

---

Ben wrote:

---

RogerI wrote:

---

Ben wrote:

---

RogerI wrote:

...

One thing LV is currently missing is good threading abstractions and debugging capability.

Roger

---

After we get the network going as fast as we need, please take some time to explain to an old tech what those terms mean.

Ben

---

When you get going strong on LVOOP, and have been studying and coding in some well designed OOP programs or framework, you can tell goodbye to all shift registers, local variables, typedef clusters in queues, hack "patterns" and never miss them for one second.

I used to wonder what OOP was good for, these days I wonder how I even could write one single LV program without it. It's a revolution.

Roger

---

I use LVOOP extensively with SRs to remember the private data state from iteration to iteration since they allow working in place and they achieve the same end but in a cleaner fashion what can also be done with DVR (Data Value Refernce) or single-element queues.

So how do you maintain the state info without SR's ?

OR

How do you write Loops without SR's ?

Ben

---

Almost all my classes inherit from an intermediate base class. Combination of value based oop and ref oop.

The wire contains a snapshot of the object data.

inside a loop, use a lock, modfy data, and then unlock, just two extra vi's to guarantee you are exclusive on data.

More specific: Use ref whenever you need to modify data, use value whenever you dont.

I posted code and some info in: http://decibel.ni.com/content/message/15181

Added a picture with an exclusive lock on the object data from one of my example classes. It's all very simple and clean LV code?

You can place these locks within a for loop, inside a thread, event handler, etc, etc..

[Ben]

---

RogerI 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