lkml.org 
[lkml]   [1999]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectHow 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.129 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site