Download with TCP

[zerotolerance]

Sorry for the confusion. 

"LabVIEW takes longer to download the file via TCP than the stand-alone application" is the main title here. The second title "Speed calculation"  became a spin-off from the 1st title.

[zerotolerance]

Is there a ready made example for testing TCP IP download speed (i.e. through ftp). I'm just thinking if the wi fi router is to blame, and I just want to see if ANY code that is written in LabView shares the same fate on my end, or is it just the code I've written. I am now monitoring download speed with a 3rd party software, and LabView is definately choking on TCPIP download. 

Thanks 

Kas

[zerotolerance]

---

@nathand wrote:

A better approach might be to read the size you do know in a single read, then do a second read in immediate mode for whatever is left.

---

I just tried this method as well but no improvements. I also took the whole Speed calculation outside the loop, where I only calculate the speed once the TCP Read is finished, but again, no improvements. 

The holdup is definately in the TCP READ. I checked at how the ftp data stream is conducted, and it seems to be very similar to what I have done. 

None of the intermediate improvements (i.e. replace concutenate string etc.) would help much because TCP Read is what is bringing the Download speed down so much.

Kas  

[nathand]

---

@zerotolerance wrote:

Is there a ready made example for testing TCP IP download speed (i.e. through ftp). I'm just thinking if the wi fi router is to blame, and I just want to see if ANY code that is written in LabView shares the same fate on my end, or is it just the code I've written.

---

You can put together a trivial test of download speed, if you have two computers available. Here's a snippet with the sending and receiving sides together, you'll need to split them of course.

[PhillipBrooks]

I don't have LV 2013 loaded, so I can't look at your code.

From the image you posted initially, the only questions I have are:

Why 4096 bytes per read?

     A typical TCP packet has a MTU size of something like 1500 bytes.

     A yEnc message looks as if it can have up to about 256 bytes.

     If you look at a network sniffer and see ~256 bytes payload per packet, I would reduce the read size to a multiple of that, but less than 1500.

What purpose does the "Pause" subvi serve? Could it be causing a delay that is throttling your reads?

[zerotolerance]

Hi Nathand. 

I'm currently limited to 1 PC, so I was hoping for something that involves an Internet server. Or if you know a ftp site I can connect to and download a package. 

P.S 

I sent you a PM. Let me know what you think.

Thanks 

Kas

[zerotolerance]

Hi Philip

"Why 4096 bytes per read?"

Initialy I played around with various sizes, but eventually I set it as 1024. Just before I posted this thread I checked how ftp VIs achieve this, and based on "TCP Read Stream" I saw that they use size of 4096, so I just left it like that. 

Appart from some basic operating principles, I'm not very familiar with the TCP/UDP insights. 

"A yEnc message looks as if it can have up to about 256 bytes." 

Not exactly. A yEnc message can be up to 15 MBytes (and in rare instances higher). The 256 bytes refers to a LINE SIZE in yEnc Message. So to make things simple (because I don't think this would change anything), we can forget about what type of message it is (i.e. yEnc or some other format) and think of it as a single file in the server that has a sive of about 15 MB. 

"I would reduce the read size to a multiple of that, but less than 1500."

So far, I have reduced/increased the size and the Time Out. Changed to all the modes and modified the VI to accomodate various Read Modes, changed the whole framework more than 3 times (with various improvements along the way) and NOTHING. For testing purposes, I only kept the TCP Read in the loop and took EVERYTHING else out, but no change. 

Thats why I'm thinking that its must be something deeper in the LabViews TCP IP protocol that is causing this.

"What purpose does the "Pause" subvi serve?"

Since the file that is being downloaded may be large, the "Pause" simply aborts the download (if the user chooses t do so) and gets out of the loop.

Thanks

Kas