Since this thread didn't arrive at what I think is the correct answer, I'm going to resurrect it for the sake of future people finding it while searching the forums.
I agree it is sucky, but the actual root cause is almost certainly netiher the ftp server, nor NI..
cRIO targets use a file-system called "Reliance". Its a transaction-based "atomic" file system that prevents data corruption in the event of unexpected shut-downs (e.g. power-loss or hard reboot). (It does not protect against loss of data writes in progress of course).
The performance of the Reliance file system degrades horribly whenever you have more than ~100 items in a folder. This performance degradation supposedly then affects every file/location on the disk, not just localized to the folder with lots of files. In addition there are performance issues if a single file is "large".. Going by DataLight's feature list of Reliance vs. the new version (more on that one below), "large" means >50kB...
If you had over 3000 files in one folder, pretty much any operation that would require file/folder access would be painfully slow. The time-out is probably becuse the server on the cRIO requested file handle(s) and the OS/file-system was so slow it just couldn't keep up.
NOTE: if you MUST have huge number of files (and they are really big), note that you can connect to cRIO USB drives via FTP as well, so you could save all your data-logging outputs to a USB drive or stick instead. The stick must be FAT or Reliance formatted. It [cRIO] does not support NTSF formats.
Now, I have seen these effects in my own data-log folders and it is rather dramatic, luckily the item-count limitation is by far the worst and I havevn't really had to do anything about files, even as big as 15+MB. One work-around (mentioned in this thread but for a different reason) is to structure your folders such that you limit the total number of files/folders at any given level. examples include: c:\data\ch1 , c:\data\ch2, or maybe c:\data\1 ... c:\data\31 with each folder having files for that "Calendar month" date... Unfortunatley, you may (depending on your app) also need to write a routine that once per day (or similar) crawls your folders and trims folder content if the total size of the folder =>xxxMB and/or if there are more than e.g. 90 files in the folder. (you could then auto-delete the oldest files until you are below the limit(s).)
Reliance was actually replaced by Datalight in 2009 by "Reliance Nitro" which largely fixes the performance limitations due to "large" number of files and/or file-sizes.
There is an NI Suggestion Add Reliance NITRO to the list of supported file systems in the RealTime Idea Exchange that could do with some up-voting that would fix this and other issues...
NI articles related to this topic:
Directories with a Large Number of Files and Folders can Slow Down a Real-Time Program
Formatting Controller to FAT with the LabVIEW 2009 Real-Time Utility Drive Causes the Controller Not... [I didn't realize you could format and run the cRIO's as FAT systems... I wouldn't recomend it though due to the risk of hard reboots and power-loss during file operations.)
Somewhat related:
LabVIEW Real-Time and USB Frequently Asked Questions (FAQ)
Reading Data From a Hard Drive Formatted With the Reliance File System in Windows
LabVIEW Real-Time Module Causes Disk Corruption on Hard Drives Greater Than 126 GiB (PharLap ETS only?)
QFang
-------------
CLD LabVIEW 7.1 to 2016
