Messages in this thread | | | Date | Thu, 29 Apr 1999 19:18:12 +0200 (MET DST) | From | David Kastrup <> | Subject | How to make Linux scale up WRT bandwidth and size? |
| |
Hello,
copies of relies to poster appreciated since I am reading linux-kernel only on an occasional basis. Thank you.
I am working at the Institut für Neuroinformatik in Bochum, Germany, and I would like to tell about a setting where using a Linux system would seem a good solution, but where I am sceptical about whether this solution will prove satisfactory anytime soon.
We are processing video sequences for testing and developing computer vision algorithms here, and I am currently playing around with a Linux Alpha station with 500MHz.
Typical B&W pictures have 736x256 bytes and come at a rate of 50 frames per second. This means a sustained rate of roughly 10MB per second. Lossy compression would falsify the results and is thus not possible. Uncompressed files are what is easiest to handle, anyway. The PCI bus where SCSI-Controller and frame grabber are connected is (if I am not mistaken) capable of performing roughly 130MB per second. Considering that we do have to transfer stuff into memory and out again, we have half of that available for raw transfer, which should even be enough for colour pictures (which would, however, probably demand using a RAID controller for the RAID array of disks instead of the single Ultrawide SCSI bus topping out at 40MBps). Trying to find a controller that would use a 64bit PCI-slot would not be a bad idea, either.
In theory.
Now how to do the recording? The easiest solution would probably be memory-mapping a recording file and doing a single large read-call from the framegrabber (video4linux device) to the file.
Will this be able to provide the necessary sustained performance that the hardware is principally capable of providing? I doubt it yet, but I need a more qualified opinion.
We have not yet turned to real-time harddisk recording, but I certainly would one day like to have this possibility open. The following problems I see that might prove a problem. Some of these might be in principle solvable already, but I have not yet done actual experiments:
File size: the ext2 file system tops out at 2GB file size, which is sufficient only for very short sequences (about two minutes). Something like 10GB would be more appropriate. For handling of the sequences *after* recording at the latest, we need to put them on files. Partitions are not flexible enough. So probably we need to use a non-native file system for this, like NTFS.
File access speed during recording: we could probably get around this one by not memory-mapping a file, but a partition (or its RAID equivalent). It would probably still be a large waste of resources not to be able to be using a raw device for this.
Size of memory map: will the Alpha system without complaint map a 20GB file into the address space available for the video4linux device? Not tried yet. It's things like that one wants 64bit-processors for.
Efficiency of memory map: will all that happens in that scenario be a transfer from framegrabber to memory in one copy done in busmaster mode by the framegrabber, and from memory to disk in another busmaster done by the SCSI controller? Is there even a possibility that a single read call onto a raw disk partition could be handled by shuffling the data immediately around between cards without going through memory? Probably not, but probably this would be too sensitive to buffer overrun, anyhow, unless one would have a RAID controller with serious onboard buffer size.
So this wraps up some real-world "extreme" configuration where I think some feasible out-of-the-box operation should be imaginable using something like Linux. Apart from the file size limit, one could expect that the functionality provided by Linux 2.2 should be up to task. At least the APIs to use for this task seem more or less clear-cut. Will the functionality behind them work well enough for the requirements? I will see whether this is the case after a bit of testing. Suggestions for how to approach this problem are welcome. And, of course, if any developer happens to concern himself with trying to make Linux perform well under such circumstances, I'll be willing to do some testing of more specific things, too. Since I am not system administrator of the system in question, implementing kernel-level changes might however be connected with longer delays.
I might add that at the moment we do not have any other system up to the task of realtime recording. We currently go via an expensive laserdisc as intermediary buffering device in recording. However, our existing solution *does* get at least along with 20GB files.
Apart from the 2GB problem, the change to the Linux station and a standard framegrabber supported via video4linux *will* be a big step forward. The question is just how big a step forward we can make it.
Thanks for listening,
David Kastrup Phone: +49-234-700-5570 Email: dak@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209 Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |