High speed data transfer TCP/IP

[MarcelD]

Using the TCP vi�s in Labview 7.0 I am sending 2MB of data at once over the network from one computer to another. Sending this data takes over 10 seconds and looking at the transfer speed with I find it reaches little over 1Mb/sec, confirming that it is really the transfer that takes this long. I have tested the transfer with various computers running different version of Windows but always with the same result. I doubt it is the network that limits the transfer as I can easily transfer files between the computers with sustained transfer rates of more than 50 Mb/s. Are there any settings one can change in Labview to speed up the transfer between computers?

[Ben]

You may want to review this discusion.

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000007BE0000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0

The original poster got some good result in the end.

Ben

[Ben]

I should add a little info about the link.

After days of talking and experimenting, the original poster shared all of his findings along with some sample code.

Ben

[MarcelD]

Hi Ben,

Thanks for pointing out this very interesting link. Using the little test vi's I have been able to figure out what provides the best throughput, i.e. multiple packets of max 8192 bytes with 0 ms interpacket timeout. This way I was able to get a stunning 80 mb/s over a 100 mb/s Lan. It's about time NI impliments this trick themselves in their supplied vi's.

Cheers, Marcel

[Ben]

Very Cool!

I am gald I was able to help.

Ben

[WBlack]

I am running into similar problems and the above link no longer works. Can someone point me to the new link to that information?

Wiley

[Ben]

I think this was the original thread

http://forums.ni.com/ni/board/message?board.id=170&message.id=71099&query.id=0#M71099

Please let us know if this helps,

Ben

[rolfk]

There is no magic wand to do this in the LabVIEW internal code automatically. The correct block size and delays depend on many things such as your network setup including your network card and its drivers, intermediate routers and switches, the actual connection such as hardwired, 10MB, 100MB or GigabitEthernet or maybe dialup connection you have etc. Also while such an approach works well for huge data it could degrade performance for short data, so that you get into trouble when trying to implement fast request/response protocols with only short data messages each.

The real problem I would expect is in the fact that LabVIEW needs to maintain all the data in an intermediate buffer even after the write function returns, eg. not all data has been necessarily received by the other side when LabVIEW returns from TCP Write and of course the according buffering in the receiver side is even more necessary as well. With huge MB buffers the underlying memory manager is exercised a lot more and there is no way NI could avoid that buffering other than dropping the data which couldn't have been sent off in a single shot.

So no, there is no no simple way NI could do this chopping into small pieces without inconviencing you and others in some different way.

Rolf Kalbermatter