On Sep 27, 2010, at 11:41 AM, Patrick Cable wrote: > The problem is space on the desktop and that the data needs to be > centrally accessible in real time. And that they didn't have $100k for > a NAS.
Well, you'll never get "real time" unless you use a "real" RTOS in all phases of the process, and NFS sure as hell ain't gonna qualify as any part of an RTOS solution. Now, if "near real time" is close enough, then you may have sufficient "wiggle room" elsewhere in the system. Besides, if you're reading from the local disk on the workstation fast enough, that file storage can be kept to a minimum and you won't need to spend much money on disk space to accommodate it. You might even be able to put that on a high-speed SSD, or even a RAM disk (if the workstation is on battery backup). Then end result would be that you can essentially guarantee no loss of data between the FPGA and the workstation, and then the process of serving that data across the network to the file server would actually be very low overhead and very high speed, because you're only going to have one process writing to the local datastore from the FPGA (which is the slow/expensive part) and all the read operations across the network will be asynchronous and very low impact. > RHEL is terribly old, but I am using 5.5 at the very least. > I may be able to use RHEL6 on the data server; supposedly that's > coming out next month. It sounds to me like your problem occurs before the information gets to the data server, so no amount of "cure tonnage" you try apply to the situation at that point is likely to have much impact. I think you're much better off trying to find unconventional ways to apply a few ounces of prevention earlier in the pipeline. -- Brad Knowles <b...@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu> _______________________________________________ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
