Help identifying bottleneck for ip cams

[camus]

I have zm running on a Dell Dimension 3000. It has an P4 2.8Ghz with 512MB of memory. I'm wondering if the bottleneck i am currently encounting is because of the cameras, zm, or cpu/mem/etc.

A high load avg is about .62, but typically its in the low .20s. top reports that out of 512MB of memory, only about 180MB are used.

shared memory is set to 402653184 (shmmax and shmall). I set this in /proc/sys/kernel/.. and in /etc/sysctl.conf

I have two ip cams running:
1 Dlink DCS 900 12 frame buffer gets around 3 fps
1 Panasonic BL-C10 11 frame buffer gets around 2 fps

output from ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000002 65536 root 600 655360 0
0x7a6d2003 262145 www-data 700 3456448 3
0x7a6d2001 294914 www-data 700 3456448 3

1. the output from ipcs shows each camera using 3456448 bytes in shared mem. Dividing this number by 1024, I get 3375. Does this mean each capture daemon is only using 3mb?

2. the panasonic BL-C10 says it can get 15fps. Anyone have any ideas on what the maximum fps that can be retrieved on a remote camera?

3. If i am having a bottleneck with memory, should top show all my memory being used, or will it still be listed as free.

4. If I up the buffer size 1 frame on the panasonic, zm doesnt start capturing. Is this a memory related issue?

thanks

[TheFluffyOne]

Do you get better performance if you only run one of the cameras at a time?

[zoneminder]

You should get much faster captures than that. Are you using the single image urls or mp-jpeg ones?

Phil

[camus]

Ok, I've tried running one at a time. When I try running each camera by itself using the Monitor function, I still get about 2-3 fps on each camera. Ocassionally the fps burst higher, but it doesnt seem that the image refresh is actually improving.

Now I did notice something odd in the logs:

ERR [Found unsupported content type ' [[[insert garbage here]]] ']

This happens with both cameras. If i change the remote host path from the motion to single jpegs these messages disappear.

For the DCS900: video.cgi vs image.jpeg
For the BL-C10: nphMotionJPEG vs snapshotJPEG

Now I read another post that said I could check what this garbage is by trying a wget on the url. When I do this on the motion urls, it is non-ending stream.

So I think my poor fps might result from the problem reading this stream. Is there any settings I have to use for zm to parse these streams correctly?

thanks,
James

[zoneminder]

Try changing the setting of Options->Network->ZM_NETCAM_REGEXPS and seeing if that makes any difference, with the mp-jpeg path.

Phil

[Baylink]

Camus, I'm having the same problem with the BL-C10's: slow frame rate; lost of dropped frames, timeouts, and dying capture daemons, and if I use the motionjpeg instead of snapshot URL, it gets much worse.

I don't have any answers for you, but I'm sure interested in yours...

[ma77hias]

What settings are you using on the D-Link DCS 900 ?
I am running a couple of these !§%"§$&$§" cameras and when I use the resolution 640x480 and minimum compression I also only get 3 fps.

Increase the compression on the camera and you can get up to 7fps

[camus]

Changing the value for REGEX mentioned earlier, does eliminate the random junk being spewed in syslog. I also upgraded to the latest 121.3 release.

Right now I am running 3 BLC10 and 1 DCS900W. The computer is using about 300MB of memory and has a load average of .22

I'm getting 4-5fps on both the BLC10 and DCS900W using the motion jpegs. I am using the standard compression for both.

The problem i am currently having is that the fps is a bit jumpy. For instance one camera shows 5fps but then jumps to 10fps intermitently. The motion stutters.

Also, when i playback a capture, the camera seems to freeze. I have to adjust the rate to 4x or 10x before i see the motion. Since the jpeg stills show the entire motion i think this is an issue with playback. Any ideas how I would fix this?

thanks

[zoneminder]

It's probably worth checking zmdc.log or /var/log/messages just to make sure that your capture processes aren't restarting a lot. Sometimes this can cause jitters like you are seeing and is a symptom of something more serious.

What playback method are you using, and browser etc?

Phil