Create New Topic

Eric Fleming Bonilha

Well, that will honestly depend on the VMS platform.. I guess you should ask directly to your VMS supplier if their software can take advantage out of a six core processor...

The VMS should be made with parallelism in mind... if the VMS developers don´t properly split the tasks in threads, it might not take advantage of it.. and it also depend on which tasks are multi-threaded...

One thing that takes a lot of processing is decoding (If the server has to decode images for motion detection or even trasncoding), so, if the VMS uses multi-threading for decoding, it will split the tasks between processors and you will have a significant gain in that area...

There could be some tasks that are not parallelized, in that case you could end up with a bottleneck somewhere, causing some delays and malfunction even if your CPU is not fully used

I could go very very deep in this subject since I´m very experienced in this area (As a VMS developer, and developer of our multi-threading core) but I guess you get the idea...

But as I told before, the only one that could actually give you a straight answer is your VMS supplier because only they know which parts of their VMS uses multi-threading...

So, simply put.. if the VMS is well designed, yes, it WILL take advantage of more cores...

Create New Topic

Eric Fleming Bonilha

John, with more cores the system have more air to breath, obvisouly the system would be able to handle more cameras per server, do more tasks at the same time and could process more data

Lets say that the machine is storing only (Not even detecting motion or anything). This should be using very very little of the processor, depending on the bitrate of the cameras. When the machine is only storing (No decoding, no transcoding...) the "heavy" task here would be receiving the network data, parsing it and storing to the disk. While network communication and disk writting are I/O operations which will also depend on the speed of the disks / network card, the data parsing is CPU bound. In our case, even the data parsing and network communication are split in threads, so, the VMS will use all cores to actually do the network communication, parsing and storing to avoid bottlenecks. A bottleneck in this subject would be if the VMS was developed in a way that only 1 thread is responsible for network communication / parsing, in that case, if you have a low frequency CPU (Lets say 1.6ghz), even in a 32core system you could have a bottleneck, since this thread that is responsible for parsing the data will be overloaded and the whole system would suffer because a single thread is overloaded, but if the system is designed (as ours is) with multi-threading in this layer, it will avoid bottleneck by splitting that processing across all processors. So, what gains we have in here? The system can process more data and consequently manage more cameras.The disk recording could also take some advantage of multi-threading, but this will totally depend on the VMS architecture...

Well, when you have a local live display (or a server recording with motion detection or doing transcoding), this is where you will see the most difference (Unless you are using GPU decoding which is not yet too much common for VMSes) since decoding uses a lot of processing power (Especially for those high megapixel cameras), the major gain is that the system can split the decoding process across processors, which will allow the machine to decoder more images and cameras simultaneously (because it will actually use all cores), so the gain in this case is that the machine would be able to decode and render more frames per second (on total) which gives more cameras per machine...

Another thing that plays a major role is the CPU frequency... if there are some tasks that can´t be parallelized, it must be quickly finished, and to quickly finish a task you need a higher frequency to process it, but this is another subject :)

Create New Topic

Mike Dotson

Well described on both posts. My independent performance testing of a variety of VMSs has left me with the exact same observations as you describe. The biggest benefactor of more cores x freqency is any sort of viewing function. While typically NOT suggested for a recording server one has to allow at least a single tile on the server to at least set up a camera. We perform our testing with this in mind and add more hardware resource as needed.

One of the VMS developers I was able to talk to about the Client function described the current difficulty of using the GPUs to decode the streams. It was a case of little improvement for a lot of extra code. They are looking out for GPU architecture changes that will let the decoding task become more efficient. Until that time...CPU horespower is the top dog.

I also have multi CPU in my mix and from a viewing perspective this is clearly a VMS dependent potential benefit. This means some VMS will scale reasonably well with the extra CPU while others do not seem to scale hardy at all.

Create New Topic

Mike Dotson

Well... yes and no. There is a dependecy between the actual VMS resource usage and the total bitrate going to storage.

I describe this with a simple chart to our sales folks as shown below.

At the lower bit rates...CPU dominates because we are not stressing the Storage or NIC resources....then as we progress to higher rates... the VMS starts running into bottlenecks in either the NIC or Storage subsystem before any from the CPU.

For Milestone, the size of the LiveDB and the Archiving schedule come into play.

At the lower bit rates...say 100 or less.... there is not any noticable benefit to the LiveDB needing to be high RPM drives.... but above that it comes into play.

A memory metric also comes in to play more for the quantity.... higher bit rates needing more memory (ie go from 4GB to 8GB)

Create New Topic

Undisclosed

Having some experience with Milestone, the bottle neck is not only CPU, it's HDDs. I'm guessing that your bandwidth with this resolution for your cameras is around 1.5Mbps (perhaps less but we don't have more details), so a total of 75Mbps for the server to record/manage. I would put a XEON E3 series v3 or E5 series v2/v3 (4 cores is enough) and I would put 4x SAS 300GB HDD and then SATA drives for the archive storage. You won't have any problem to record and manage the installation. For Windows, go 64bit but no necessary Windows Server...only if it's Corporate in this case yes. For other version, you can go with Windows 7 Pro 64bit...it will be cheaper.

Create New Topic

John Honovich

Philippe, Thanks. Is the hard drive bottleneck the same for Corporate as for Enterprise? My understanding was that the recording architecture was different for the older Enterprise line (with the live / archived dbs). I would appreciate any guidance you have here.

Create New Topic

Marty Major

I can confirm this - the platform engines are most definitely different, and the performance increase is pretty noticeable on the higher platform.

Also, disregarding the similar sounding names, the GUI [or Management Client] in Milestone Corporate is entirely different than the GUI [or Management Application] for all of the lower XProtect versions (see screenshots of GUIs below).

Keep in mind, I never tested the technical stuff like Mike did... but each week I would install cameras on both platforms in class (separately), so I was able to observe how each platform performed in relation to the other (same cameras, settings, etc).

However, since I wasn't trying to test anything, I would rely more heavily on actual testing like those performed, and related, by Mike above.

Create New Topic

Undisclosed

CPU is really not the problem with Milestone recording engine. I have seen servers loaded with a lot of cameras streams and CPU with not even under stress...but HDD yes. Milestone recommend always (for Corporate and/or high bandwidth) to put SAS HDD, could be 10Krpm or 15Krpm..but you need them. Normally it's a bunch of 4-6-8-10...it depend and could be configured in RAID5 or RAID1. For me, the bottle neck will always be HDDs for recording ONLY. For Archive storage, then it's used SATA drives.

Now, for LIVE viewing, it's pure CPU...Milestone use only CPU (and almost 99% of VMSs) to decode streams, that's why it is recommended to use an external workstation always for Client. This part is really tricky...and there's no established guidelines...which is really "funny".

Create New Topic

Mike Dotson

We have been testing VMS Clients in my lab as well to be able to recommend a build to handle the decoding and total stream count.

It is indeed a tricky situation because there are so many things that can make the decoding CPU work harder. The sneaky one is frequently the actual size of the tiles on the display salvo because many of the VMS change the data down for smaller tiles and up for the larger ones. More data means more CPU decode work.

For ALL VMS's the CPU is king, so spend you money there first. The video card usage is quite variable among the different VMSs with Milestone using it the least.

Create New Topic

Undisclosed

Yes, Corporate recording engine is better than Pro versions. I'm a bit amazed to see that Mike said that they could run 628Mbps streams on a single server, is this true? I mean all this on one server? I would be interested to see exact configuration and scenario for this...

Create New Topic

Mike Dotson

The key to this was the size of the LiveDB (1.2TB RAID10) with the camera rate coming in. We had a mix of H264 and MJPEG streams to boost the bit rate and have a stress factor for servicing remote clients and doing motion detection on the server. The streams were 720P@30FPS/2.5Mbit or 1080P@30FPS/5Mbits.

The archiving scheduled was every hour and we had a 3 hour retention...running Corporate code.

This means the LiveDB could have as much as 4 hours of 'new' video data on it before it got moved to the 12TB DAS archive storage.

If the LiveDB was smaller...one could not get to that rate. This can be seen with the independent testing of our XNVR300 and XNVR400 in the Milestone Certification results (found in their Soultion Finder section). The build we sent them had half the amount of LiveDB that I was using in the lab.

Create New Topic

John Martinez

As an old programmer for IBM and Honeywell and an ex Cisco trainer, I want to compliment everyone on this discussion. This is what I love about our forum. Technical and to the point. This should at least guide us in asking each vms co's the key questions prior to recommendations.

Create New Topic

EJ Nemec

If you're going with Milestone, they have a server build form on their website. You plug in the number of cameras, model, desired fps, days storage, etc,--they respond by email with a suggested build. These are robust builds, I've personally found them to be overkill for us so we've scaled them back for our needs.

With 50 IP cameras you can bump up the cores and clock speed as discussed above, but you might want to also consider going with a machine that has two(2) Xeon processors. Dell 7610 workstation is a low cost 2 processor alternative or the D720 if you're looking for a robust rack mount solution.

There was some discussion about hard drives, I'm sure Milestone will suggest 10k or 15k rpm drives for storing the live video, but the archive video can be the cheaper 7.2K drives. Don't go cheap on the drives, video seems to toast the cheaper drives pretty fast (12-24 months).

I see some people noted the benefits of more cores when viewing video on the server. At 50 cameras, in my opinion, you should never be viewing cameras on the server. Buy separate dedicated viewing stations.

The world's leading video surveillance information source, IPVM provides the best reporting, testing and training for 10,000+ members globally. Dedicated to independent and objective information, we uniquely refuse any and all advertisements, sponsorship and consulting from manufacturers.