Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

fastest way to transfer data through LAN ?

We have a server client app where the clients are to be served with files (appr. 1 MByte) that reside on the server.
Now the clients receive only the network location and the files are read by the clients from this shared drive (simply with Open file).
Would it be faster to send the actual data directly to the client (either with TCP or UDP (data integrity can be checked in vi.)?
Certified LabVIEW Developer (CLD)
0 Kudos
Message 1 of 6
(4,687 Views)
Sharing drives is often accomplished using TCP/IP.

Are you sure the "bottle-neck" is the ethernet?

Disk drives are generally orders of magnitude slower than LANs.

UDP is probably a bad choice. It is good for advertising (sending out the same thing over and over, and who cares if anyone gets the message) but would be very troublesome for file transfers. I shiver just thinking about what it would take to do this in UDP.

If you decide the bottle neck is really the ethernet then take a look at the VI server examples. You could use VI server to execute a file read VI on the the server that opens and read the file and returns it to the calling VI running on the client machine.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 6
(4,687 Views)
Thanks for your comment,
I just want to add that our harddrives have a sustained I/O speed on the interface of more than 40 MBytes/s, so that's more than the theoretical maximum of 12.5 MBytes/s of 100 MBit Ethernet.
Certified LabVIEW Developer (CLD)
0 Kudos
Message 3 of 6
(4,687 Views)
OK,

"sustained I/O speed" is a spec that tells you that once the drives heads are on the correct cylinder and the servo has locked onto the servo track, that the drive can transfer data at that rate.

A better spec to look at would be the average latency. This will tell you what kind of performance you can expect out of getting a drive to move its heads from one location to another and get the new data.

There is also the issue of others apps requesting other files on th same drive. Do you have exclusive access to this drive? If not, your app has to wait in line behind all of the other requests th are pending for th spindle.

Unless the drives are solid state drives, I would still work to convince myself the bottle-neck is the ethernet.


Trying to help,

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 6
(4,687 Views)
From search examples look at

Networking>>>TCP & UDP >>> Data Client.VI

and Data Server.VI

Try modifying the server example such that one just returns a hardcoded constant 1 Meg array. Run that one machine. Use the client see what kind of performance you get.

Do another mod of the server and have it open, read and close a 1 Meg file. Run that version on the SAME machine as the client.

Disk drive are dog slow. As long as they are mechanical, they will remain so.

Still trying to help,

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 6
(4,687 Views)
Thanks for all the comments, we'll try some things out.
Manu.
Certified LabVIEW Developer (CLD)
0 Kudos
Message 6 of 6
(4,687 Views)