Motion Performance on non-PC platforms

Introduction

I have been experimenting with Motion on hardware other than a PC. I have used a Linksys NSLU2 (NAS Device) and a VIA EPIA M10000 small form factor computer.

Detailed Description

Linksys NSLU2

From August 2006 until Spring 2007 I used 'motion' on a Linksys NSLU2.

There is an alternative flash load available for the Linksys NSLU2 which is called Openslug 3.1. It transforms the NSLU2 into a standard Linux platform and removes its Linksys NAS functionality (although the usual NFS and/or Samba can be set up). There is another flash load available called Unslung 6.8, which preserves the Linksys NAS features but is a non-standard Linux (some of the directories are less standard). Neither of these Linuxes provide a GUI, since there is no graphics hardware - interfacing is by ssh only.

Either of these operating systems can be used to run 'motion'. I have used both. The plus points of this machine is it consumes only about 4 Watts (including a USB memory stick). Additional storage can be attached by USB2.0 ports. Adding an external 3.5" HDD adds a further 17Watts approx.

The CPU power of this hardware is limited - the CPU is that typically found in PDAs. The bogomips figure is around 260. No integral floating-point processor is present in the NSLU2 CPU, and no MMX. Motion requires Jpeg decoding for each frame from a netcam, and the motion-detect algorithm includes an MMX optimization which obviously would not be used here. Most PC CPUs now include MMX or equivalent, so one or more of these reasons is why the "motion detection" frame rate is quite limited - see the next section for how to find out exactly how much.

What can be run with this hardware?

It is possible to run V4L cameras directly via USB2.0 ( tested with pwc based webcams in debian arm). Network cameras or devices such as the Aviosys IP9100A (See WorkingDevices). I tried to run 2 netcams with this hardware, but found that a frame rate of 2 fps was not reached on both due to lack of CPU power. I needed 2fps to detect motion in a security application. So for motion detection at 2fps, only one camera should be used. This gives a MotionThruPut rate of 1.6-2.0 fps (Camera: D-Link DCS-900 set to 640x480 frame).

I did extensive research into why a low frame rate throughput was achieved, and concluded that since the ARM processor lacks a floating point unit (it uses a software equivalent), JPEG decoding is particularly slow. This is the major reason why MotionThruPut was low. I also looked at the use of keep-alive HTTP connections, but did not get an appreciable speed increase from that.

It might be possible to run an additional camera if a very slow frame rate (eg. 0.2fps or less) is configured, but motion detection will not 'see' fast events - it would catch very slow ones. Note: This is configured using the minimum_frame_time config option and not the framerate one.

What is MotionThruPut ?

That is the number of frames processed for motion-detection per second. It is not the same as the camera frame-rate, as on slower hardware, camera frames are dropped if the back-end processing (JPEG decoding, mask processing and motion detection) are not yet finished from the previous frame.

MotionThruPut is a performance figure that is shown by the Motion Statistics page using StatisticsDataPatch (most recent versions). It allows you to check if your CPU is adequate for the frame rate you have configured. Most netcams can provide frames at up to (say) 20-25 fps under certain conditions of frame size and compression) - BUT this high fps is of no use if the CPU can only process and motion-detect say 5 frames per second. The latest StatisticsDataPatch I wrote also contains a Throttle system, where if you configure a netcam thread for a lower rate of frames per second than the netcam delivers, motion will not attempt to process frames as fast as it can (which is normal behaviour) and will discard them (evenly over time) to achieve a MotionThruPut rate as close to the configured fps as possible. This reduces CPU usage - a proof can be seen in the StatisticsDataPatch topic - and permits it to be used to run more cameras....

The performance of the NSLU2 running Openslug 3.1, with 2 netcams operating was just about ok. The system load was around 4-4.5 which is quite high. The threads were configured for 3fps and 0.5fps. The MotionThruPut was 1.5 fps on the first channel and 0.5 on the other. In other words, there is no more CPU power to be had and the motion detection ability was beginning to reduce.

Beware - there is still a bug which means this patch will not work on a V4L camera system. You should only use it on netcam systems, as I do, and it will work fine. I will look at it, but I have less time nowadays.

VIA EPIA M10000 small form factor computer

This is a small motherboard containing all usual PC features (video adapter, IDE ports, network, serial etc). It is around 17cm square (Mini-ITX size) and only needs a HDD or memory card to boot from.

I have used one of these as a 'motion' server since Spring 2007. The advantages over the NSLU2 are:

• Faster CPU than the Linksys NSLU2 (1GHz CPU on my model). Bogomips around 2000.
• You can use almost any Linux distribution. I used Grafpup 2.00 as it is very compact (~100Mb). It is a derivative of Puppy Linux.
• CPU power to run lots of netcams and also V4L cameras using the one PCI slot for a capture card
• MotionThruPut will be much, much higher due to CPU power.
• Still a small form factor (Mini-ITX cases available from set-top-box size to toaster size)
• IDE ports to attach local HDDs, no need for USB2 disk enclosures

The down side is higher power consumption than a NSLU2. Although the CPU is said only to consume 10 Watts, the rest of the motherboard hardware, and any HDDs, add up to more.

When running 'motion' on the EPIA M10000 board, 256MB RAM, with 3 netcams running at 2 and 1 fps, the system load was only around 1.0-1.5 . (This is a low load, showing there is plenty of CPU power to permit more cameras or higher fps if required). I would expect this performance to be around the same as a PC of ~1GHz CPU. Two 3.5" HDDs were attached for storage, and the power consumption was around 70 Watts.

For comparison, an Athlon PC with 1GB RAM, and of around 1.8GHz speed, running the same 3 netcam system, a load of 0.5 approx was seen. This shows how a high speed CPU is less affected by the workload. Incidentally this PC consumed about the same as the EPIA machine, at 65 Watts with 2 3.5" HDDs.

Attached Files

None

Installation

Users Guide

Comments and Bug Reports

---