Member Discussion

Multicore Processors - What Is The Benefit Of 6 Vs 4 Cores For VMS?

If I'm specifying a recording server for a VMS like Milestone, how much difference does it really make what processor I choose? Do I really need the six core, or is four cores going to do it for me?

Depends on what they want to do with the server? How much load will be on the server.

Say, 50 cameras, 2MP, H.264, 7FPS, as an example.

My question is what, precisely, are the extra cores doing for me. What am I gaining in paying for six cores, what am I losing in going with quad core.

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...

Eric, for your own VMS, what would the difference / benefit be of going from 4 to 6 cores? What is the impact if that machine is storing only versus providing local live display as well?

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 :)


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.


Specific to Milestone (or any other VMS you've tested), are you saying that the 2 extra cores would NOT help in recording more cameras on a VMS server?


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)

Perfomance vs bitrate

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 will be cheaper.

Hope this helps.

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.


The Corporate code is more efficient going to storage.

On a recent performance test in our lab, the lower code was doing 266Mbits and the Corp code was doing 467Mbits on the same hardware and storage structure.

With a better CPU,Storage,memory build the Low code ran at 346Mbits and the Corp code ran at 628Mbits.

Yes it is different...Corporate recording engine is better than Professional line. I don't have numbers...but as far as I remember we are talking about 30% more.

Intereresting. I remember thinking the additional features didn't quite justify the price difference between Corporate and Professional (or Expert). Can anyone confirm the use of a different engine?


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).

Management Client (Corporate) / Management Application (Enterprise & lower)

Using the Milestone Corporate 'engine', cameras are discovered and load faster, the GUI displays video thumbnails faster, connects to camera and display settings faster, etc. To expand on Mike's statement above, 'The Corporate code is more efficient...' - at seemingly everything.

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.

"the bottle neck is not only CPU, it's HDDs"

i always thought that there is always one, and only one, bottleneck at any given instant. do you mean with different configs?

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 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".


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.

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...

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 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.

All measurements mentioned were during the Archiving process itself.


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.


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.

That's what I did. They quoted me a 6 core instead of the quad core I'd already picked out. I was trying to figure out if it was overkill or if I was underquoting.

Since it only adds ~$800, I'd go with it. I don't expect any performance issues with their builds, but if there is and you follow it you can go back to them.

I did a non-discount Dell 3610 build and see going from a 4 core (2.8ghz) to 6 core (3.5ghz) adds ~$800.

A non-discount Dell 7610 build with two (2) 4 core (2.5ghz) processors adds ~$1400.

LSI SAS/SATA controler +~$300-$500 on either machine. Though I'd add my own after the fact, when we install our own hard drives. I do not accept Dell drives for video.


Per... 50 cameras, 2MP, H.264, 7FPS, as an example... This can be estimated at appx 100Mbits for the total throughput.

Depending on what else you plan to be doing with the system (ie viewing) will dictate if you need 6core.

If recording do not need it.

If you anticipate having several clients pulling old data, you may want to consider a couple of SAS/High RPM drives.

Mike, thanks for contributing to this discussion. You've been a terrific resource so far.

Do I need a special controller card to use SAS drives versus SATA drives?


SAS does have a different protocol than SATA so being aware of what is in your system and what it supports is important.

The LSI cards we use in our builds support BOTH SAS/SATA devices which allows us to take a 12 bay chassis...make 4 drives the SAS LiveDB and the other 8 SATA storage.

You will also want to look for on board cache on the controller. Without it you will not be able achieve any significant speeds (above 100Mbits).

Yep, you need a sas controller card that is different from the sata one.