ZoneMinder Forums

Hi

I am new to ZM and haven't got hardware/software set up yet, however I'd like to do most of research beforehand.
I've been reading threads that people experience quite a drop in performance the more cameras they use.

What i was wondering is whether or not anyone had profiled to see where the bottlenecks in ZM (or libraries it's using) are? From my limited ZM knowledge, candidates would be:

- downloading an image from a camera (either camera is slow or the network)
- modec
- storing images on harddrive

Is it the modec step? If so, i can perhaps give a hand at implementing a GPU accelerated modec. The operation is rediculously parallelizable (i think) so the performance boost should be substantial.

Also, are there any kind of ZM architecture documents? I'd like to avoid diving into the code to reverse engineer the high-level architecture.

Thanks
Alex

Thanks for your posting. Unfortunately there are no architecture documents. I have done some profiling and not found any obvious bottlenecks other than DB and file access for the most part.

The motion detection code is in zm_zone.cpp mostly and other image manipulation code is in zm_image.cpp which might be a good place to start if you want to have a look.

Thanks for reply Phil, i got a chance to briefly look at the code. BTW it's written quite well, but it certainly doesn't help that there are very few comments

What is the priority for the project optimization? Is it mostly bug fixing? Or there is a good effort put forward to optimize ZM?

I'd give a hand in that, but i am not exactly a DB developer/specialist, so won't be helpful if the bottleneck is there.
I can however look into performing image operations on GPU (jpeg encoding/decoding, modec, etc) but there is not much point if that's not a bottleneck.


Alex

since we added mmx libs i feel the spped has improved massivly, plus its hard enough supporting it on i386 arch, i can imagine all the different gpu's that would have different quirks lol
What would be useful though if you have looked at macie k code is an easier to implement version of this for most people to install as a viewer.

I myself cant do c but started aproject in realbasic, but macie app was so much better as it used shared mem, (mine didnt) if you dont want to do the gui i can do that if you can get rb to talk to the shared mem i will do the rest.

James

jameswilson wrote: What would be useful though if you have looked at macie k code is an easier to implement version of this for most people to install as a viewer.

i am sorry, i didn't quite understand this sentence

if mmx optimization had massively improved speed, i have a feeling that implementing same parts on GPU will be even more massive of an improvement. But, as i said, if it's not a bottleneck, it will just be a waste of time.


Alex

i think the bottleneck now is disk speed. Ie the pci bus can only take so much traffice in each direction. with current dualcore processors (i havnt tested the new core duos yet) and quad core now out, processing of images is fine, its getting them in and out. Ie the pci bus carrying the images from the card or network catd, then backout down the bus to the drives for storage.
I pushed a dualcore fx60 to 250 fps at 320x240 in mocord a few months ago, and it ran. I wouldnt advice this framerate long term and also motion detection is not something you can benchmark as how oftern would all cams have 100 motion per input?
While having detection or compression done in the gpu i feel there are other areas more important than this, but thats just my opinion. I remeber all the hassle macie k had with different gpu's as different cards worked in slightly different ways

James

So if disk IO is really the bottleneck, i am guessing there are only two real ways to improve performance substantially:

1. Upgrade HDDs to some fast SCSI units in some fast RAID config (using PCI-e of course and not the ancient PCI), or...
2. Spit out the images in some form of compressed format (be it just spatially or both spatially and temporaly (mpeg) ). This of course will require fast encoders/decoders that could be implemented to utilize GPU.

can anyone see this being useful? anyone tried going to option #1? what was the performance boost like?

btw, differences in GPUs are taken care of in OpenGL pretty well (extensions) so no problem there. Also, who is macie k ?

Alex

the problem is mate your talking the top .5% of systems this will help. I suse sata raid regulaly with zm but never go anywhere near its limits.

I think the big gains would be to process on the card before passing to zm, ie in the capture card but then what about ip cams firewire stuff etc.

I assume your itching for a project to help with?

Well, i plan to use ZM for couple of my relative's businesses, thats how i got into ZM to begin with (being linux geek and all)
So seeing how people complain that performance goes waaay down when using several cameras, it made me think about how to improve it's performance. Also i did a lot of GPGPU and OpenGL programming back in university and now work in a firm that deals with this stuff. Naturally i thought along lines of graphics hardware acceleration.

But the lack of architecture documents makes ZM kindof hard to get into. (making diving into the code and figuring out stuff the only option)


Alex