OR on 32-bit arch?

[Kit Peters]

I've been doing some further reading into the OpenReplay wiki, and it suggests using a 60G buffer / camera.  That amount of space is not a problem - I've got a terabyte disk in the machine I'm planning to use - but I read elsewhere that if I wanted to use buffers bigger than 1G, I needed a 64-bit machine.  I only have a 32-bit machine to work with.  Am I going to be limited to 1G buffers?

KP

--
Kit Peters, W0KEH
GPG public key fingerpint: 1A12 04B6 0C80 306A B292  14FD 2C7A 1037 F666 46A7

[Andrew Armenia]

On a 32-bit platform, the usable buffer file size is limited by the size of process address space, since the buffer is memory-mapped to share data between the various programs. Essentially, the buffer file acts like a big swapfile. The limit will be 1GB, 2GB, or 3GB depending on how your Linux kernel is configured. This is called the "kernel/user split" and refers to how much of the 4GB address space the kernel keeps for itself and how much is available for a program. I've probably gone into way too much detail here already, but the upshot is that most Linux distributions would configure the kernel so that 3GB of address space is available, meaning that your buffer file size will be limited at just a bit less than that. 

Anyway, buffers on the order of 1GB or 2GB should be enough for doing replays of something that "just happened". A 2.5GB buffer will hold about 10 minutes worth of video if my calculations are correct... (mjpeg_config.h by default configures the buffer to allocate 128kb/frame, so 1 MB = 8 frames, 2500 MB = 20,000 frames = 667 seconds?). Keep in mind that, on a 32-bit platform, 2.5GB of buffer will be your total limit across all sources. So if you were planning a four-camera system, your replay buffer would go about two and a half minutes back on each camera... (2500MB total limit divided by 4 cameras, times 8 frames per megabyte...)

I also can't speak to encoding performance on a 32-bit platform, having never tried it, but it should be fine as long as the CPU is fast enough.

Hope this helps,

-Andrew

[Andrew Armenia]

By the way, if your hardware is any more than a couple of years old, you will most definitely want to install the libjpeg-turbo library, which will speed up the M-JPEG encoding greatly by making use of your CPU's vector instruction set. It can be downloaded from http://sourceforge.net/projects/libjpeg-turbo/files/. I typically install it to /opt/libjpeg-turbo as follows:

tar -zxvf libjpeg-turbo-whatever.tar.gz

cd libjpeg-turbo-whatever

./configure --prefix=/opt/libjpeg-turbo

make

sudo make install

Then make sure to set the environment up so that the Openreplay programs pick up libjpeg-turbo instead of your system's libjpeg - you probably want this one in your ~/.bash_profile or somewhere where it will automatically run:

export LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib

-Andrew

[Kit Peters]

Would it be possible to use PAE to increase this limit?

KP

On Dec 16, 10:53 am, Andrew Armenia <and...@asquaredlabs.com> wrote:
> On a 32-bit platform, the usable buffer file size is limited by the size of

> process address space ... the limit will be 1GB, 2GB, or 3GB depending on how your Linux
> kernel is configured.

[Andrew Armenia]

Unfortunately, that won't help... PAE indeed expands the physical address space of the CPU, but each individual process is still limited to a 4GB virtual address space.

-Andrew