FTP Problems... 3-4 minutes for transfer

[technomage]

I have RTOS unit based on PXI-8184, 850 Celeron, 512 MB Ram. I am trying to get FTP to work properly. What I see is 3-4 minutes to transfer a 2MB file. Ridiculous. I have used execution highlight to monitor that subvi's are getting the parameters. However, when running normally, after they have the params I still see a wait of 30-40 seconds before the subvi executes. I am using an Open, Put, and Close vi for this operation, so I end up waiting 2-3 minutes total for this simple tranfer to occur.

I have also used Ethereal to examine the packets. They show no problems, other than the time lapse between things. I have included my simple vi and a text based log from Ethereal.

Any Ideas????

[Kevin_Price]

It's fuzzy now, but I recall a similar problem with way-too-slow ftp transfers with a similar RT system.  In our case, it was really slow with a direct crossover cable connection but decent speed with a LAN hub in between. 

To get decent speed from the crossover cable we ended up going into some of the network adapter settings.  I *think* the main thing that helped was the duplex setting.  The available choices were something like Half, Full, Auto with Auto as a default.  One of the others worked better for us.

Dunno if it'll help, but it doesn't take long to try...

-Kevin P.

[technomage]

Thanks for the reply. I am using a router/switch for my setup. I have also tried the half and full duplex settings with no noticable difference. I can do very fast transfers at the command line from my laptop, or by using WS-FTP. It is just the vi driven transfers that are so slow.

technomage

[TCPlomp]

I've seen this problem also with LabVIEW RT on a PXI controller, the funny thing was one system had a transfer rate of 50 kByte/s ( at 100 MBit connection), the other had a speed over 2 mbyte (downloading several files from the FTP controller speeded thins up 1 file 1.2 MB/s, 2 file 1.6 MB/s total 5 2.2 MB/s..)
It looked to my like the system fragmented (remember FAT32 is used) and the OS has no defrag option...
now i will stop my rants over LV RT and PXI..

Ton

[technomage]

More Info...

Today I connected to another PXI chassis and ran my FTP transfer vi again. This vi only grabs an existing file and moves it to another computer. Again I had Ethereal running to capture the packets. Here are the facts:

1. Start the VI. Ethereal shows NO activity for 27 seconds and then captures the first 5 packets. Examination shows these to be the "Open Session" chat, which would be driven by the FTP-Open-Session.vi I have used.

2. Wait for 23 seconds and then Ethereal captures 3 more packets, which are the "Request for User" chat. This would be a subset of the FTP-Put-File.vi.

3. After another 24 seconds Ethereal captures 3 more packets which are the "Password Request" chat. Again this is a subset of the FTP-Put_File.vi.

4. Wait for another 25 seconds and Ethereal captures 3 packets which prove to be the "Set to ASCII" chat. This is a default subset of FTP-Put-File.vi.

5. Another 21 seconds goes by and then Ethereal captures 2 packets which are the "Port Request" chat. Still being driven by FTP-Put-File.vi.

6. Now I wait for 29 seconds and 6 more packets are captured. These are actually the "Request to Store" the file conversation. This is still being driven by the FTP-Put-File.vi.

7. After 26 more seconds I then see Ethereal capture over 2400 packets. These packets all came across in 0.789608 sec. This is the actual file. I calculated the transfer rate at 3,117.596 bytes/sec.

8. Then I have one last wait of 24 seconds to capture the final 900+ packets. examination shows that the first 12 of these are the "Close Session" chat, being driven by FTP-Close-Session.vi. I believe the rest are all commands from the vi to "Stop the VI". All of these 900+ packets transferred in less than 0.3 sec.

9. TOTAL TIME FOR THIS SIMPLEST OF TRANSFERS = 3 MINUTES AND 21 SECONDS.

I guess my next try might be to reboot the RTOS units into Windoze and defrag them.... I really can't understand why this is only seen when using vi's to control the FTP functions.

Please give me some ideas....

[Sima]

Hello, I have the same problem. After doing some data logging on an RT system (a Desktop ETS), I FTP it over to the local PC, which will sometimes take several minutes for a few MB file. We also have a watchdog, which is just a bit that toggles between the PC and RT. If that value hasn't changed in 5 seconds, an alarm is displayed, and that usually happens when the user hits the button to FTP the data file over to the PC.

[technomage]

Yes, it does look like this is a common problem. It's just too bad that we can't seem to find an answer. I may have to figure out another way to transfer files.

Today so far I have tried it with two RTOS chassis and they both act the same. Approx 3 minutes and 23 seconds for the transfer routine. The actual data transfer takes less than one second fro a 2.5MB file. All of the time I am losing is caused by the "chatting" between the computers.

For anyone else facing this problem, check out the Ethereal network analyzer at http://ethereal.com/ . It is open source software which gives you an easy to read way to see what is going on with your network. Without it I would still be totally lost with this problem.

technomage

[technomage]

Latest info: still trying to figure out what is happening here. I have now built an even simpler vi to transfer a 2MB file. Then I captured that with Ethereal. Here is the simplest FTP vi I can think of along with the capture. In a nutshell the FTP-Put-File.vi takes almost 3 minutes to execute.

IS THIS A BUG OR WHAT???????

technomage

[eaolson]

I tried your VI, after downsaving it to 7.1, and was able to transfer a 2MB file in about 5 seconds.  Are you able to do other network-related things from within Labview that aren't slow?  How about running a VI from a host computer targeting the RT machine?  I had a similar problem when targeting an RT chassis across the network, but not necessarily transferring files, and was able to fix it by changing the network communication to half-duplex, and fiddling with a couple of parameters in ni-rt.ini file.
http://forums.ni.com/ni/board/message?board.id=170&message.id=142824

[technomage]

Thanks for your reply. I am running my vi from the laptop, but on the RT target, for this transfer in order to use the Put function. My app has to send files from the RT unit, because the host doesn't know when a file has been generated. I have checked the "SocketSendBufferSize" in ni-rt.ini and it is set to 65535. I have tried various combinations of Half Duplex and Full Duplex, and Autonegotiation. Also while I was poking around I removed the check mark on "Stop system if TCP Fails" within MAX. I tried my very simple transfer and it took 2 minutes and 57 seconds. with both NIC's set to 100MB/Full Duplex. My packet analyzer showed the actual data (2.4MB) transferred in 0.756342 sec. All of the delay seems to be waiting for the vi on the RTOS to send the next chat item.

1. This single vi "FTP-Put-File.vi" will login and supply "anonymous" as a user name.

2. The laptop will reply within 0.002 sec and then the vi on RTOS will send ACK.

3. But then I wait for 25.3 sec for the RTOS vi to send the password. Again the reply and ACK is almost instantaneous.

4. Then 25.2 sec later the RTOS vi requests ASCII data transfer, with an instantaneous reply and ACK.

5. I wait another 24.8 sec for the Open Port request. It is replied to and ACK from the RTOS vi immediately.

6. After another 24.6 sec I see the RTOS vi request to Store the file. I see 7 packets used to set this up, which all occur within 0.09 sec.

7. Next I see a wait of 24.9 sec and then the data is transferred at over 3MB/sec.

When I run other vi's with no FTP functions I can (almost) instantly see updates to front panel objects on my host from the vi running on the RT target.

Yesterday I rebooted two RTOS units back into Windoze XP and ran defrag. I also ensured that FTP would run from the command line within XP. No trouble or noticable delay from that angle, but I cannot try the same thing at the command line while running the RTOS, since there is no command line. I then booted back into RTOS and I still have the 3 minute transfer times.