VMS Server Sizing

By Sean Patton, Published May 25, 2018, 09:48am EDT (Info+)

Specifying the right sized PC/server for VMS software is one of the most important yet difficult decisions in IP video surveillance. In the past manufacturers designed and certified that a specific appliance 'box' would support a specific number of cameras (e.g., 4, 8, 16, etc.). Of course, the simplicity came with limited flexibility for expansion.

With VMS software being widely deployed on 'regular' PCs/servers, integrators need to properly specify the right ones. If your machine is not powerful enough for your cameras, you can face all sorts of painful issues and difficult to troubleshoot problems.

The good news is, fundamental guidelines exist to help select the right hardware.

Inside, we explain many of the factors to consider, including:

  • New Technology Impact
  • Key hardware drivers (CPU, RAM)
  • Server Cost Differentials
  • Maximum Throughput
  • Throughput Calculations
  • Bits versus Bytes
  • Smart Codec Impact
  • H.265 Impact
  • GPU Processing
  • Multicast Support
  • Multiple NIC Support
  • Manufacturer Specifications

New ********** ******

***** ********** ************ ** *** **** 5 ***** **** **** ** ****** on *********** *** ****** ** ******* that * ****** *** *******. ******* that ****** ** *** ****** ********** can ******** *** ****** ** ******* required. ***** ******, *.*** ********* *******, and *** ********** *** ******** *** channels *** ******.

Key ******** *******

*** ****** *********** ** **** ********* on *** *** ***, ******** ********* how **** ***** *** ** ********* for ******* *** *********. ******-***** ****** detection ***** **** ******** ********* **** significantly *** ***** ** ** ***** into ******* **** ******** ****** ********.  Exact ************ **** ********* ** *** specific *** ****, *** *** ********* is * ********* ** **** ****** manufacturer **************:

  • ***** *******, ~*-** *******: ****-**** **********, such ** ***** **** * *** e6850 ** **** **-*****, *** ***
  • ***-**** *******, ~**-** *******: ****-**** *********, such ** **** **-*****, *** ***
  • ***** *******, ~**+ *******: *-**** ********** such ** **** ** ****** ** Core **-*****, ** ** ***

**** ********* *** *** ************* ******* may ** ********** ** **** ****** in ***-***** ******* **** ** **** or **. *** ********, **** * Duo *** ** ********** *** ********* only ***** ** ******* ***, ***** Xeons *** ** ***** ** ****-*** workstations *** *******.

Server *****

******* *** ********* *** ********* **** hard ****** *** ********* ****** ** the ***-$*** *** *****, ******* ***/*** appliances ***. ***** ******* *** ** run ** *****-******* *** ***** **** desktop, ***********, *** **** ****-** ********, in *** ***** ** ~$***-*,*** ***. Mid-range ******* ******** **** **** ****** workstations ** ***** **** *******, ~$*,***-*,***. Large ******* *** **** ******** ***** this *****, ********* ** ************* *** chassis ****. $*,***-**,*** ** **** ** common *** **** ****** ******, *** to *** ******** ** ***, *** speed, *** *** ******** ** ****** counts ** **** ***** ****, ********* power ********, *** ******** **** ***** required ** **** *****.

********** ********* ***** ** *** ** the ****** ***** ******** ** ****** sizing. ********** ***** **** *** ** the **** ********* **** ***** $*** USD ** *** **** ** * server. **** **** *********, *******, ** the ***** ****** ** ********* ***** and ******** ***** *** *******, ** the **** **** * *** **** 2.00 *** **** ********* ** ***** core *.** *** *** ** $***-***.

Importance ** ******* **********

*** **** ** ********** **** *** estimated ******* ********** ** *** ****** will **. ** *** ********* **** sever **** ***** ** ******* ****** throughput, ** ***** ***** **** ***** the ******* *** ***** ******* ** time, ********* ** ******* ******* *** loss ** *****. **** *********** **** oversize * ****** ** **-**% ******* of **** *******.

Total ******* ********** ************

**** ********** *******, ***** ******* ********** handling ** *** **** ******** ******. Throughput ** *** ***** ****** ** bandwidth ****** **** *** *** *** machine (*.*., ** **/*, ****/*, ***.)

***** *** *** ******* ***** *** impact ****:

  • *** ********** ** ********* *******: *** quantity *** ******* ** ******* ********* is ******** *** ******* ********* ** total **********. **** *** ** ** simple ** *********** *** ****** ** cameras ** *** ****** ****, *.*., twenty ***** ******* **** * ****** size ** ***** **** = ** Mbps *****. *******, **** ***** ******** bitrate, ***** **** **** **** ******* each ******'****** ************* ***********, *** *******. ** ******* begin ***** *-* **/* ** *****, when ***** *********, **** *** ****** overload ** ************** ******. *** *** to ****** **** ** ***** ******* that ******* ******* *** ***** (*** *** ****** ** ***** ***).
  • *** ****** ** ********** *******: *** second ****** ***** **** ******* ** throughput ************ ** ********** *******. **** is *********** *** ******** *********** ** perform, ***** ****** ******* ***** *** fixed ********, ** *** ***** **** multiple ***** *** ******* ** *** server *** **** ******* ******* ** cameras. ** ****, ** ****** ******, throughput ****** ** ********** *** *** worst ****, **** *** ******* ****** of ******* ********* ******* *** ******* simultaneously. ********** *** ** ******** ** various ****, **** *** ******** ***** via *** *** ******, ** **'* supported, ** **** ** **** ******* from * *** ******:

client throughput

*** ******'* ***** ********** ** *** sum ** ***** *** *******. ** a ****** **** (**) ***** ******* with * **/* *******, *** *** clients ******* *** ******* (** **** total) ****** ** ********* ** ****** 120 ****. ***** ************ *** ******** by *** ************. **** **** ******* the ****** ** ******** ** *** camera ******, ******* ******* *** ****** through *** ******, ****** ******* ** throughput ************. ****** **** ********* ******* from ******* ** **** ** ******* when *** ****** ** *** ****-******, i.e., ** * *****-****** ****. ***** should ******* *** ***** ******* ****** throughput **** ***** *** ********.

**** ****** *****

** ******* ***** ********* **** *** bytes. **** ******* ****** ***** ********** using **** *** ****** *** **** VMS ******* ******* ***** ****** **** using ***** *** ******. * **** = * ****, ** ** * manufacturer ********** ****/* **********, **** ** equal ** *** **/* ** ****** streams.

Smart ***** ******

** **** *****,***** ********** ******* ******** *************, **** ~**% at * ******* ** ****** ****** to **% ** **** ** *** motion ******. ***** ***** ********** ****** average system ****, ******: ******* **** ***** be ***** ** *********** ***********.

*** *******, ** *** ******* ******* is ~** **/* *** ****** *** to ***** ******, *** ********* ****** to ~*** **/*, **** ****** ********** ****** be **** ** ********* ****** **** and select **********. ******* ** ******* *** this ********* ********* *** ****** ** systems ******** ****** ***** ***** ****.

H.265 ******

** ******** ** ***** ******, *.*** bitrate savings ******** ** *.*** *** ******, with **-**% ********** ******. *******, ***** reductions *** ********* "**** ****", ******* of ******* ** ******/********** ****** ** in ***** ******. ******* ** ****, the ******* ****** ******* **** ***** smart ****** *** *** ******* **** using ******* (***-*****) *.***.

***** ****** **** **** **** *.*** streams **** ******** *** (***/** ***) **** when ***** ******-**** ****** *********. ******* H.265 ** **** ********* ********* ** decode **** *.***, **** ******** ******** less ****** *** **** ******, ***** these ******* *** ****** ********* *** ****** CPU ****. ***** ****** ** ***** of **** **** ****** ******* *** consider ***** *.*** *** ****** ********* where ********* (***-*********) ******* *** **** for ********.

GPU ********** *******

********** ******-***** ********* (*********** *******, ****** detection, ***** *********, ***) ** *** resources ** ******* ** ******** ** the ******* *** *** ********** ******* in ****** ********.

**** *** ******* ** **** *********** ******** ********** ***** ****** *********** *** ******, ***** ***** ** NVIDIA *** *********. *** ******* ****** a *********** ******** (**% - **%) in *** **** **** ********** ** the ******'* ******* ***** ***.

** ********** *********** (**) ** **** Learning ********* ****** **** ****** ** the ***** ******** ********, ** ****** that *** ******** ************ **** ****** much **** ********.

Multicast ******* ******* ******

********* ******** ** * *** ******** can ****** *** ************ ** *** total ********** ********* ** * ******.

* *** **** ******** ************, **** a ******** ********** *******, **** ****** Client ******** ** ******* ******* ******* directly **** *** ******* ******* ******, instead ** **** *** ******. *** server **** ************ **** **** **** to ******* *** *** ******** ******* from *** ******, *** ******** ******* will **** ** *** *** ***** that *** ********. **** *** *** potential ** **** *********** ********* ** high ******** ****** ************ *** **** have * ********** ****** ** ******* where **** ******* ** *******.

Multiple *** *******

**** ************ **** ******* ******* ** be ********* ** *** ** **** isolated **** ******** **** ******* ****** PCs. ** ***** ****-************ ************, * secondary *** *** ** ******** *** failover/backup *************. ** **** ** ***** situations ******** * ******/*********** ******** **** can ******* ********* **** *** ******** support ******** ************* ****** *** ****** operating ****** *** *** ********.

Manufacturer **************

**** ********** ** *****, *** ****** most ********* ****** ** ************ ***************. Users ********** ******* ***** ** *** meet *** ******* ************ *** ***** given ********** *** **** ********** **** seeking **** ******* ** ****** *****. If ** ********** ** ******* ** accept *** ********* **** ** ***** an "************" (********* ** **************) ****** and *** ************** ***** ** ***** project ******* *** **********, **** *** be **** ** **** **** **** from * ***** *******. *** ***** wishing ** **** ** ****, ******** strictly ** ************ *************** ** * minimum ** ***********.

*** *** ***** *************** *** ************ varies ******* *************. **** **** ***** some ** ***** *** ********* ** throughput ****, ****** *** **** ******* to * ****** ** ******* *** server. **** ****** ** ************, *** users ****** ****** ***** ***** *******:

  • ********: ******** ***** *** ************** ** their****** ************ *******, **** *** ****** ********* *********** defined ** ** **** ****, *** ACC *********** ********** ** ** *******.
  • *****: ***** ***** ****** (*** ******) recommendations ** *** ***************** ***** *** ***** ****** ******** versions. ***** ****** *** ****** ** <50 ****, **-*** ****, *** ***-*** Mbps. *************** *** ***** *** ******* and ********* **************.
  • *******: ****** ************ *** ***** *** minimum, ***********, *** ****-*********** ************** *********'* *************. ** ******** ***** *** ***** for **** *********** ***** ** **** supported ******* *** *** ** ***** Streamvault ********** ** ** ** *,******* read (**** ******* ************ ******).
  • *********: ****** ************ *** ****** *** Low *** ****-*** ******* *********** *************. ********** *********** ***** **** ***-*** servers ********** ** ** ******* ***** / ******* ******, *** ****-*** ******* supporting ** ** ******* ***** / 400Mbps ****** ******* ***********.
  • *********: ********* ******** ******** ***** ******* ******* ******** *************** **** ******* ******. ** ********** limitations ** ************** *** ********* *** listed.

******* ***** *************** **** **** *** a ***** *************, **** **** ******** for ********* ****** ** *********, ************ hardware *********** *** ** *************. *******, there ** ****** ****** ** ****-****** hardware *************** ** **** *** ***** project, ** ******* ** ******* *************** for ******* ********** ******. ***** ****** also ******* ******* ***** *************** *** up-to-date, ** **** **** ******* *** pre-sales **********, ** **** *** ******* information, ***** ***** *** ****** ******** at *** ****, ******* ******.

 

 

Comments (16)

Donald Gordon

IPVMU Certified | 05/25/18 05:06pm

Sean,

Nice article on server sizing.  With 1080p cameras we had to offload the video motion detection (VMD) off the server and let the cameras do that analysis and send VMD events to the Milestone server.  That has a dramatic reduction in the amount of CPU processing power (and thus cost) you will need for the server.

Without doing server-side VMD, the server sizing is most influenced by the I/O subsystem.  The type of hard drives, RAID technology, and RAID controller selection are important.

The latest advice I received from Milestone on server I/O subsystems required 15,000 RPM SAS hard drives.  Those are now available in 900 GB capacity.  We also use LSI RAID cards with battery backed up cache.  Milestone recommends placing the drives in a RAID 10 set.  Note that our LSI RAID controller does not allow more than 16 drives in a RAID set (we have a 24 bay server).  There may be other reasons (rebuild time) not to use larger RAID sets anyway.  With all that said, I have seen the Milestone Husky systems use SATA drives and I think in a RAID 5 configuration so I am a bit perplexed :-).

I would really like to hear anyone's experience using native 4K sector hard drives over the old 512 byte sector drives.  Is there a performance advantage and do any of the video management system software available take advantage of native 4K sector drives for improved read/write performance?

Agree: 1
Disagree
Informative: 2
Unhelpful
Funny
Avatar

Walter Holm

IPVMU Certified | In reply to Donald Gordon | 06/13/18 04:59pm

RAID 5 is fine for small drive quantity, but beyond I believe 6 drives, it becomes too risky, I would then at least use RAID 6.  RAID 10 is great (performance-wise) but more complex for most to maintain.  I would recommend better hardware with RAID 6 (SSD offloading, faster drives) than to use RAID 10.  Why is that?  With RAID 10, you can lose half your drives and your still okay, but is that all, NO.  You can lose two of the wrong pair of drives and good bye to all your data.  RAID 6 builds on RAID 5 but has two parities instead of one.  The number of drives before failure is no longer tolerable is much higher (it's not linear) and I think it's in the late 20's or early 30's of drives.

4K drives should be less about performance and more about integrity.  Performance could be there but it will be minor, SSD would offer much larger gains.

Agree
Disagree: 1
Informative: 3
Unhelpful: 1
Funny

Undisclosed #1

05/25/18 05:18pm

RAID Penalties?

Agree: 1
Disagree
Informative
Unhelpful
Funny

Undisclosed End User #2

05/27/18 02:28am

I noticed the very well written article referred to camera court. When sizing servers is their a difference in using camera count verse imager count?  I.e you have a single imager 1080p fixed camera and a multi imager 1080p camera.  

Also as specs very by manufacture, how do you recommend I write a SOW that lists min specs without over or under specifying the server and/or workstation size?

Agree
Disagree
Informative: 1
Unhelpful
Funny
Avatar

Mike Dotson

Seneca | IPVMU Certified | In reply to Undisclosed End User #2 | 05/29/18 12:49pm

Yes indeed the multi imager cameras present a different load to a server.  The concept I use to explain this is as follows...

A single imager camera (NOT panoramic, 360 etc..just a plain vanilla cam) will present the data to a system much like a series of 'tractor-trailer-trucks' delivering their goods to the destination.  At the destination, the payload is unloaded and off he goes.

The multi-imager adds this twist.... the truck is now built with multiple trailers linked together like a train, so when it arrives, the trailers have to be separated before they can be unloaded.  This adds load to the entire system... CPU, Memory, Storage so when I see these types of cams, I suggest at least doubling any estimated resources for each one.   HD encoders also fall into this category (like Axis F44 type).

A spec request simply based on camera count is only useful for an analog based system.

An IP system needs to know resolution, FPS, scene complexity, scene motion amount and stream quality (compression) to be able to have a chance at a decent recommendation based on estimates.   The IPVM team always recommends doing on-site reference measurements with actual cameras for the most accurate results. 

Keep in mind that the primary reason for RAID is data protection, followed by the potential performance increase (assuming the use of hardware RAID).   RAID6 is the best protection whereas RAID 10 typically provide the best speed.   RAID5 is more popular because it combines a little bit of everything (protection, capacity, Read Speed) as long as you don't make your arrays too large (due to rebuild times with the larger HDD being so long, you want to minimize the potential of a 2nd drive going bad while the array is rebuilding).

Agree: 3
Disagree
Informative: 6
Unhelpful: 1
Funny
Avatar

Sean Patton

IPVM | In reply to Undisclosed End User #2 | 05/29/18 01:21pm

As Mike stated (with a lot of specific details), you need to be concerned with the number of imagers, but mainly just the throughput and recording rates (which is obviously a product of the imagers). How you get to an accurate totalynumber will vary, and as Mike pointed out, depending on the camera make/model and the VMS chosen, there will be additional resource requirements.

Your last question brings up one of the more difficult tasks in creating a vendor-agnostic specification. In most ways, as an integrator, I saw minimum specifications as merely a glancing check to see if there is a sign to what vendor a customer might be leaning towards. The server that you receive should minimally be able to support the throughput and retention of the system the integrator is providing, plus whatever percentage of growth you may want to plan for. I've had customers and specifications that include a 30 day post-installation check to confirm that the server was retaining the required video, with whatever percentage open space on the drives. If an integrator is coming in with all H265 or smart codec cameras, and is figuring a low amount of motion, versus another integrator with standard H264 and figuring a higher amount of motion, with a different VMS that is going to perform server side analytics/motion detection, than let the integrators make that choice. 

The main other option is to decide specifically what VMS manufacturer, camera manufacturer, % of motion, etc so you have a complete system design to put out for bid.

Agree: 2
Disagree: 1
Informative: 3
Unhelpful: 1
Funny

Undisclosed End User #2

In reply to Sean Patton | 05/30/18 02:09am

Thank you Mike and Sean..

I understand the points you are making, having to specify vendor-agnostic specifications for the goverment is very hard when we can not specify a vms manufacture or camera manufacture. Also I have never offered or had a potential bidder ask to come on site while preparing there proposal to test cameras. 

One thing we are allowed to do is present a minimum spec and site a specific vendor and model with the phase or similar. Even with that hint, usually only 1 and 10 vendors I would say, propose what I am hinting at for some reason.  I feel your frustration with bad specs and hope you feel mine with trying to generate that vendor-agnostic SOW that fits within the FAR, with enough detail to get what I need.

i think it would be a great project for IPVM to write a perfect vendor-agnostic IP vms/cctv sow once a year and let both sides (specifies and integrators) provide constructive feedback. Hey that could even be a new class for IPVM to offer.

Agree: 1
Disagree
Informative
Unhelpful
Funny

Undisclosed Manufacturer #3

In reply to Undisclosed End User #2 | 05/30/18 01:56pm

IPVM has quite a few articles about the RFP process....good and bad.   Look for their tag under the 'Articles'.   As of this post, there are 59 of them.

Agree
Disagree: 1
Informative: 1
Unhelpful: 1
Funny

Undisclosed End User #2

In reply to Undisclosed Manufacturer #3 | 05/30/18 04:47pm

You make my point exactly, RFPs are very important on both sides of the fence.  You as a manufacture and me as an end user should speak the common language, however it is one of the most contentious issues.. 

Agree: 1
Disagree
Informative
Unhelpful
Funny: 1

Robert Shih

Independent
05/31/18 06:27pm

Hmm...as informative as this is... it still doesn't completely answer questions I posed in this topic.

Agree: 1
Disagree: 1
Informative
Unhelpful: 1
Funny: 1

Olivier Faber

06/15/18 01:01pm

Eocortex provides a calculator (based on resolution, FPS, analytics in use) that lists an example CPU and/or GPU. We match those up to https://www.cpubenchmark.net/ to match them to other CPU (Xeon) models since they only provide desktop CPU's.

I gives a good indication but can be a tad on the light side server spec wise.

Agree
Disagree
Informative
Unhelpful
Funny

Undisclosed Integrator #4

12/09/18 10:50pm

I understand there are a lot of variables but it was stated

 

VMS server performance is most dependent on CPU and RAM

 

and

 

When specifying servers, total maximum throughput handling is the most critical metric. Throughput is the total amount of bandwidth coming into and out the machine (e.g., 40 Mb/s, 80Mb/s, etc.)

 

How is the CPU rated for bandwidth?

 

I read this article https://en.wikipedia.org/wiki/Memory_bandwidth

 

The looked up the specs on this processor https://ark.intel.com/products/126688/Intel-Core-i3-8100-Processor-6M-Cache-3-60-GHz-

 

With a bandwidth capacity of 37.5GB/s that means 37,000Mbps right?

 

Well according to DW I can run around 4000 4MP cameras at 30 FPS and still not max this processor out.

 

 

I am a noob at this but I know enough to know this does not add up.

 

What am I missing?

 

FYI I do not have any specs or system in mind, just trying to understand how to get close to specing the right server for future projects.

Agree
Disagree: 1
Informative: 1
Unhelpful
Funny
Avatar

Sean Patton

IPVM | In reply to Undisclosed Integrator #4 | 12/10/18 07:24pm

If there was a way to stream your video raw direct to hardware CPU memory, then yes, you could support 4000 cameras on that processor. =)

Unfortunately, in most cases, you are stuck working in a Windows or Linux operating system which is going to process the streams and create "bottlenecks".

This is why websites like CPU Benchmark exist for the PC gaming market. Unfortunately (or fortunately) we're not all trying to play Skyrim at 120fps, so benchmarking would have limited usefulness for video surveillance. Your best bet is to follow the VMS manufacturer's recommendations and work with their sales/support to select server specifications.

Agree: 2
Disagree: 1
Informative
Unhelpful: 1
Funny
Avatar

Sergio Guzman

Pine Crest School
IPVMU Certified | 02/22/19 06:54pm

Still valid. Loving this.

Agree
Disagree: 1
Informative
Unhelpful: 1
Funny

Patrick Kelly

In reply to Sergio Guzman | 02/22/19 07:41pm

Not sure if you are referring to UI4 and the  screen shot UI4 provided but it is incomplete and the statement "Well according to DW I can run around 4000 4MP cameras at 30 FPS and still not max this processor out." is completely invalid, the number of servers required is found on the next page of the Storage Calculator 

Agree
Disagree: 1
Informative
Unhelpful
Funny
Avatar

Sergio Guzman

Pine Crest School
IPVMU Certified | In reply to Patrick Kelly | 02/25/19 02:14pm

No, this is a good analysis of what is needed to begin. And all NVR calculators are garbage. You have to use them very carefully. If you do not understand the environment you are making a projection for, nor how well the users will use the various features to avoid extra bitrates, it is going to be difficult.

Agree
Disagree
Informative
Unhelpful: 1
Funny
Login to read this IPVM report.
Why do I need to log in?
IPVM conducts reporting, tutorials and software funded by subscriber's payments enabling us to offer the most independent, accurate and in-depth information.
Loading Related Reports