TCP datra , send - receive - slowing down

[Mirasoul]

Hi guys,

I have a problem with tcp/ip connection, it works very slowly and I cannot find the source of my problem.

I attached screen from wireshark.

10.93.1.105 - server

10.93.1.244 - client

As you can see in the pictures, when I force data to send, server responses pretty fast. But receving data in Labview works very slow(the next data is send when previous is received)

So I assume it shouldnt take more than 200ms. After 5 mins since start it takes like 1s to receive answer, after 15mins it takes like 4-5s....

Is there any leakage or I should clean buffer or what?

In read_buffer.vi you have got full structure. I have header - forces server to send size of data in the buffer, when this size is different that 0 starts to read them.

I have verifed that in wireshark, microcontroller(server) sends everything correctly, and correct size.

I attached 3 files - these show my problem.

thank you for any advices.

[GerdW]

Hi Mirasoul,

• there are lots of wait functions in your code: usually you don't need additional waits in server-client communication…
• you are reading/writing to a lot of property nodes, the can (potentially) slow down your VI…

After 5 mins since start it takes like 1s to receive answer, after 15mins it takes like 4-5s....

Is there any leakage or I should clean buffer or what?

Do you build big arrays? As you do in that Read VI with repeatedly using InsertIntoArray with allo those hidden controls/indicators?

That would explain such behaviour…

[Mirasoul]

Hi,

first of all thank you for answer.

there are lots of wait functions in your code: usually you don't need additional waits in server-client communication…

- meaningless in this software, it doesnt explain why it slows down in time.

you are reading/writing to a lot of property nodes, the can (potentially) slow down your VI…

- meaning less, there was not a big amount of data

Do you build big arrays? As you do in that Read VI with repeatedly using InsertIntoArray with allo those hidden controls/indicators?

- it could be it, but its not....

I send updated version. Still doesnt work correctly.

I removed all data collectors, but still wrong.

[GerdW]

Hi Mirasoul,

more suggestions:

- combine your 3 TCPWrite operations into just one by appending the 3 arrays into just one. No need for those tiny statemachines to send a request to your device.

- there still are waits in both loops: 30ms in the receiver loop, 25ms in the sender loop. What's that weird coupling between the loops using a value property of that summed up enum value?

- there's no error handling in your (main) VI: do you get any errors while running the VI?

[Mirasoul]

- combine your 3 TCPWrite operations into just one by appending the 3 arrays into just one. No need for those tiny statemachines to send a request to your device.

Unfortunately, not possible. These are procedures for Microcontroler bootloader(just simplified, to show an idea of work). So it has be in this way. ...->adress->feedback->length->feedback->data->feedback->address->...

- there still are waits in both loops: 30ms in the receiver loop, 25ms in the sender loop. What's that weird coupling between the loops using a value property of that summed up enum value?

-updated in the attached version

- there's no error handling in your (main) VI: do you get any errors while running the VI?

-none

[GerdW]

Hi Mirasoul,

So it has be in this way. ...->adress->feedback->length->feedback->data->feedback->address->...

So why do you separate sending and receiving into 2 loops?

Why not implement a proper state machine to exactly follow those steps?

[Mark_Yedinak]

You can try disabling the Nagle algorithm. This will force the TCP to write the data as soon as it gets it.

[rolfk]

Where did you get this VI? It looks suspiciously like a VI that I believe to have posted somewhere around fall of last year somewhere but I can't find the post where I did that for the life of me. And I'm afraid that at least the Mac implementation might not be quite right though haven't tested that yet.

[Mirasoul]

Doesnt matter where he got it. 

According to main subject.

I used queues to separate transfer layers and it solved problem. It was newbie problem:).

[billko]

---

@Mirasoul wrote:

Doesnt matter where he got it. 

According to main subject.

I used queues to separate transfer layers and it solved problem. It was newbie problem:).

---

That's easy to say if you aren't the author.