ZoneMinder Forums

I have 2 servers, exact same hardware, exact same OS(Fedora). One is running ZM 1.24.x and the other is running ZM 1.23.x. There is a marked difference in the CPU load for ZM between these 2 servers. I am wondering if the network based cameras put a heavier load on ZM versus the capture card based cameras ? The system running 1.23.x is using an 8 port capture card with 6 cameras connected, the system running 1.24.x is using a IP based camera, only one at this time, and the CPU load is significantly higher than the 1.23.x system. An uptime on the 1.23.x shows a load average of 0.02, 0.04, 0.00. The 1.24.x system with the one IP based camera shows a load average of 0.29, 0.26, 0.28 and ZM feels a bit sluggish on this system. I should also note that 4 of the 6 cams on the 1.23.x system are setup for motion detection, and the one IP based cam on the 1.24.x system is setup for motion detection as well. My main question, is this normal ? Do the IP based cams require more CPU to process in ZM ? Thanks in advance.

Simple answer. Yes My understanding of why is that the tcp/ip overhead combined with the load of decoding the jpeg( if using motion detect.)

get the SIMD working as explained in another post - it's from some japanese developer, it works well, and lowers ZMC/ZMA CPU time to almost half

ZM converts the jpegs into raw RGB to be analyzed for motion. It adds and extra process doing so. The library mentioned above does help considerably if this is on an intel 32 processor, though no support for AMD or any 64 proc.

PS the post about the SIMD performance enhancement was

http://www.zoneminder.com/forums/viewtopic.php?t=6419

towards the end there are detailed infos how to make it work

I did some research/work into this and I believe it does work with newer AMD cpus with MMX support.
cpuid |grep MMX

I have 6 GB of RAM on my (hopefully) production AMD-triple core, so long term a 64 bit option would great, although I don't think it's ever going to happen on that jpeg project.

i looked a bit at the sourcecode and i think it'll work with any MMX and does NOT require SSE1,2,3 etc

cordel wrote:ZM converts the jpegs into raw RGB to be analyzed for motion. It adds and extra process doing so. The library mentioned above does help considerably if this is on an intel 32 processor, though no support for AMD or any 64 proc.

Is it always the procedure ZM to convert the images and if the motion detection option is selected to be analyzed or the images are not converted until the motion detection option is selected?

Is it always the procedure ZM to convert the images and if the motion detection option is selected to be analyzed or the images are not converted until the motion detection option is selected?

Only converted when analysed that why record is more CPU efficient

Sure about that? If that's the case, what are all those ZMA processes doing running on record only cameras?

Every camera will have a zmc process. This process stores the frames in a shared memory buffer for other processes to use. This can be the analysis daemon (zma), the streaming server (zms) or the frames daemon (zmf).

Because there are multiple daemons using the frames captured by zmc all of the captured frames, from whatever source, have to be in the same format. If the format is a compressed one (eg jpeg) then zmc would only be able to guess at the amount of memory to allocate for the frame buffer and all the other daemons (including future ones) would have to decode the frame before performing whatever task is assigned to it. Even the streaming server would have to decode, add the date/time to image, and encode again before sending it to your browser.

The current system ensures incoming jpegs are decoded only once. Storing the images as jpegs could result in the same jpeg having to be decoded at least 3 times depending upon youe settings

i think zma does the check IF a frame is blank -
if you change the options/config/SIGNAL_CHECK_POINTS number i see a difference in how much cpu it is useing, though very little while you are only recording

BTW that makes me wonder why JPGs must be recompressed before they are saved - why can't you just use the incomeing JPG as it came from the cam (IP cams) and pull that out of some buffer and save it? of course that'll work only in "snapshotjpg" mode from IPcams but it'll save cpu time

Here's a quick note on how images are processed:

zmc: captures the raw image from a capture card and places it in memory space, or
captures jpeg/mjpeg/rtsp/etc converts it into raw and places it in memory space.

zma: will run any time any of the recording options are enabled as it'd duties are to analyze the image, convert the raw images to jpeg, and write images to disk or pass off to zmf.

So long as you are recording, zma will run.

cordel wrote:Here's a quick note on how images are processed:

zmc: captures the raw image from a capture card and places it in memory space, or
captures jpeg/mjpeg/rtsp/etc converts it into raw and places it in memory space.

zma: will run any time any of the recording options are enabled as it'd duties are to analyze the image, convert the raw images to jpeg, and write images to disk or pass off to zmf.

So long as you are recording, zma will run.

Can this be configured in1.24.2?
I am happy with the jpeg stream to be saved & used as is from my IP cams.

Just trying to lower the load. Got a hyper threaded P4 2.4 (1GB mem) with 2 IP jpeg streams and load is at 4.0!! I don't know its managing to funtion with that load.

Might not be cpu - load is a combination of a lot of factors, including IO, memory etc.

Have a read of http://www.zoneminder.com/wiki/index.php/Managing_Load - it might help.