LabVIEW Embedded

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP between PC and LM3S8962 very slow

Solved!
Go to solution

Hi there

 

Im using a TCP connection between my PC and the LM3S8962. Ive been doing some testing and the connection is VERY slow - only transmitting every 200ms or so - even with the simplest of TCP examples from both the embedded and non-embedded examples. Could this be due to the Nagel algorithm? Ive tried using the TCP-NODELAY package although get connection errors whenever I try implementing it.

 

Any help would be much appreciated,

 

Brad

 

 

0 Kudos
Message 1 of 5
(6,401 Views)

Are you reading and writing over the TCP connection?

 

UDP is much faster. I have soem figures which I'll post soon.

 

For my "trial" application I found that reading and writing over TCP was very slow. So I now send TCP from microcontroller to PC and UDP form PC to microcontroller.

 

BTW Brad, can you tell me a bit about what you are using LabVIEW Embedded for ARM for. I'm trying to find out what people are doing with the product and what they think of it.

0 Kudos
Message 2 of 5
(6,399 Views)

Hi vitoi

 

For that test I was only writing over TCP. When I read and write the speed decreases to a transfer every about 400ms.

 

Ive worked around the problem however by using the STM package that LabVIEW offers - I discovered that writing with that over TCP was very quick (I do not know why since the STM package uses the same TCP functions that my simple program was using). For read and write functionality I had to re-write the STM Read Message VI since my embedded module could not process the "Unflatten from String" block. So, I replaced it with Type Cast functions and now I get a read and write transfer every 60ms - adequate for my purposes. 

 

Im a student using LabVIEW Embedded for ARM for teleoperated robotic arm control. 

 

 

 

 

 

0 Kudos
Message 3 of 5
(6,391 Views)
Solution
Accepted by topic author B-rizzle

I discovered that including an "Error to Warning" vi and ignoring error 56 solved the speed issues using normal TCP. STM includes this inherently in their functions and was thus the reason why STM was so much faster. 

0 Kudos
Message 4 of 5
(6,327 Views)

Apologies, but the above post is incorrect.

 

It was in fact disabling the Nagle algorithm through the windows registry that allowed for faster TCP communication speed - implementing a TCPNoDelay and a TcpAckFrequency variable in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces directory. A lot of gamers apply the same thing in order to improve their gaming performance. 

 

 

Message 5 of 5
(6,313 Views)