File transfer overloads RT Target processsor

[TurboPhil]

I have an RT project that performs high speed data logging directly to the RT target's hard drive; after running a test, I must then transfer the raw data files to the Host PC to process and view them. I have a VI included in the Host application that programmatically transfers the data files using the FTP Get Multiple Files VI from Internet Toolkit pallette. My problem is, the file transfer seems to use an exorbinant amount of processor time on the RT target. My startup.rtexe running on the target (a PXI-8106 with a single-core processor) uses about 30% of the processor time, but when I initiate the file transfer (typically transferring 25-30 individual files of ~1.3MB each), the processor usage jumps up to near 100%--often slowing down important functions of the executable. I notice a similar problem if I manually copy data over FTP using Windows Explorer, as well.

Is this a known issue with the PharLap OS? Is there anything I can do to ease the load on the processsor? So far, the only thing I could come up with was to put a wait function in the While loop in the TCP Read Stream VI (about four levels down in FTP Get Multiple). A 5ms wait dropped the processor usage spike considerably, but it also extended the total time to transfer a few MB of data from 10-15 seconds to about 2 minutes. So, it's doable that way, but certainly not ideal.

Any suggestions? Thanks!

[Ben]

Have you tried putting the TCP functions in a timed loop with a very low priority?

Also try using a "0 ms wait" in your loops. The "0 wait" tells the scheduler "It's OK to interupt this loop if someone else want the CPU."

Just trying to help,

Ben

Maybe I should add this "solved icon" to my signature....

[TurboPhil]

The 0ms Wait function is a great idea....unfortunately, I'm downloading the data from the RT target to the Host--so the FTP function calls all exist on the Host PC--but the bottleneck appears to be on the RT target as it is responding to the FTP commands and uploading the data to the Host. So I am assuming that the problem is something low-level in the PharLap OS that sets FTP replies to a higher priority than I would imagine they should be.

[Ben]

---

TurboPhil wrote:
The 0ms Wait function is a great idea....unfortunately, I'm downloading the data from the RT target to the Host--so the FTP function calls all exist on the Host PC--but the bottleneck appears to be on the RT target as it is responding to the FTP commands and uploading the data to the Host. So I am assuming that the problem is something low-level in the PharLap OS that sets FTP replies to a higher priority than I would imagine they should be.

---

"Oh bother!" (Winnie the Pooh)

It sounds like you will have to "roll-your-own" since we don't have control over that aspect of the OS. I admit that will not be trivial. Two approaches could be to set up a TCP/IP exchange between the two nodes and make sure the RT side throotles its CPU usage (again low priority). Another approach is to wrap-up file open/read/close into and Action Engine that is served via VI server. Then invoke the the AE using VI server call by reference to open/read/and close the files.

Still trying to help,

Ben

[G-Money]

TurboPhil-

         This is sadly expected behavior and please let me know if I don't explain it fully. The PXI RT contoller runs the PharLap OS. The PharLap OS has the LabVIEW Run-Time hosted on it. This is the system where your code resides and runs. When you change the priority of the different loops on your block diagram, it is this scheduler that tells things to turn off or on to run. FTP VIs use a service called FTP Server.vi. It is hosted on the PharLap OS itself and has normal priority. Unfortunately, changing the priority of your Time Critical (TC) Loops will not shut off the normal priority FTP Server because they are both on the same "level" in relationship to the PharLap OS. So when you have your TC Loop running and FTP running and they are both set on normal, they will starve the CPU. Never fear though, you can set your TC VI to a higher priority and it will override the normal priority of the FTP Server. You will still see a RT CPU usage bc the FTP will be trying to run anytime your TC VI reliquishes the CPU resource, but you will not lose critical data. Unfortunately FTP is based on TCP/IP which is very intensive communication protocol but there is no better way to accomplish what you are wanting. Please let me know if this wasn't clear or if you have any other questions. Thanks!!