Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Linux RT cRIO 9035 - FTP Problem (100% CPU Usage)

Solved!
Go to solution

Hello Community,

I have the following Problem with my Linux RT cRIO-9035.

If I use FTP to transfer files from my cRIO a problem happens with the CPU usage from 1 of the 2 CPU-cores.
No App is running on the cRIO und the CPU usage before the FTP Transfer is nearly 0% of booth CPUs.

It happens with different FTP tools. Currently we need to use FTP instead of WebDAV because there are some older cRIOs with VxWorks OS.

 

Can someone help me with this problem or have some similar experineces.

 

 

My Device:

  • NI-cRIO-9035 (2 x 1,33 GHz)
    • NI Linux Real-Time x64 3.14.40-rt37-3.0.0f1
    • CompactRIO 15.0.0 Driver
    • Legacy FTP Server (deprecated) 1.3.0

 

Greetings

David

Download All
0 Kudos
Message 1 of 6
(4,943 Views)

Now I'm confused I have the same problem if I use WebDAV. There is nothing runs on the cRIO target and after a clean restart the only thing I do is to transfer data via WebDAV and it causes 100% CPU usage of Core2.

 

The cRIO controller runs perfectly for several days if I use our normal signal acquisition application but without transferring the data. Signal conditioning (different calculations) with 6 channels  x 100 kHz from the FPGA and cyclic TDMS storage on local disk.

 

Properly I have to reinstall the cRIO but I didn't like to without knowing the problem.

0 Kudos
Message 2 of 6
(4,921 Views)

Hey DavidLabview,

 

Is it always the 2nd core which is running at 100%?

How big is the file you want to exchange (like 1GB)?

Is the connection somehow slow? How long does it take you to transfer the data?

 

Have you tried the ftp connection/file exchange before? Or is this the first time you looked at the CPU resource?

 

Regards,

Brandizzl

0 Kudos
Message 3 of 6
(4,904 Views)
Solution
Accepted by topic author DavidLabview

Hi Brandizzl,

thanks for your comment. It wasn’t always the 2nd Core sometimes it was changed or split between booth cores.

I tried it with several types of files normally smaller than 200 MB.

The connection was normal fast. The Transfer worked like I know it from the VxWorks controllers.

 

I used it very often with several VxWorks controller before and I never had something like that with the CPU Usage.

 

Right now I had reinstalled the cRIO completely and this CPU usage problem doesn’t exist anymore.

 

But now I have the next Problem with the RAM usage of the LinuxRT controller its filled up when I copy data to the cRIO per WebDAV or FTP in the size of the file I copied.

And the problem exists if the controller writes the TDMS Data itself on the HDD. It blocks the RAM until I delete the file. If I rename the file the RAM will be blocked at the same level.
If there is created a new file he kicked out the old file from the RAM and holds the new one. So nothing happens if I delete the old one only if I delete the new one the RAM is increasing by the file size.

 

Regards

David

 

P.S.: Sorry for the time it takes. I was busy to try all the things.

0 Kudos
Message 4 of 6
(4,862 Views)

Is the new problem now within the LV program? Are you closing the references?

0 Kudos
Message 5 of 6
(4,857 Views)
Solution
Accepted by topic author DavidLabview

No i tried it again without anything of my Labview application.

 

I found something in the NI Knowledge Base to this topic.

 

Memory Reporting Issue with NI Linux Real-Time OS Targets

http://digital.ni.com/public.nsf/allkb/AC6200D19D23C61586257C8D006E6DC2

 

Now I'm trying to free up the memory after file creation.

0 Kudos
Message 6 of 6
(4,843 Views)