Genetec and Milestone 500 Camera Recorders Announced

Author: Ethan Ace, Published on Apr 05, 2016

The megaserver era has arrived?

VMS manufacturers Genetec and Milestone have both announced new hardware claiming support for 500 cameras or more, huge increases over past claims.

But the question is: can servers really handle real world throughput for these high camera counts? And is there really any market demand for it?

In this note we take a look at the announcement from both manufacturers, the logistics of bandwidth vs. camera count and other issues, and how these recorders may impact the surveillance market.

*** ********** *** *** *******?

*** ************************************ **** ********* *** ******** ******** ******* *** *** ******* or ****, **** ********* **** **** ******.

*** *** ******** **: *** ******* ****** ****** **** ***** throughput *** ***** **** ****** ******? *** ** ***** ****** any ****** ****** *** **?

** **** **** ** **** * **** ** *** ************ from **** *************, *** ********* ** ********* **. ****** ***** and ***** ******, *** *** ***** ********* *** ****** *** surveillance ******.

[***************]

Genetec ********

** * ****** **** ****, ******* ******:

**** ******** ******, *** **** ****** ****** ** ****** ** able ** ******* * ***** ********** ** *** ****, *** is ******* ** ********** ** ** *** ******* ***/** ******* in ********** *********, ***** ********* ** ********** *** **** ********* for ***** ***********.

* ****** ***** (**** * ***** ******* *********) ****** **** Mbps **********, *** ** ** *** *******.

Milestone ********

********* (***)********** *** ***** ** ********** *** ****, *** *****. *********'* *********** ****** ** *** ***** *** slightly ****** *******'* *****:

*** ***** ******** ****** *** *** **** ***********-****** ** ******* 512 ** ******* **** * ********** ********* *********** ** *****/*.

*********, *** ***** *** ********, *********'* ******** **** *** *****, also ****** *** **/* ********** ********, ****** ** ******* ** 120 ****** ********.

Milestone ******** ********

********* ******* ******* ****** ** ******** ** *** *****, ****** of ***** ********** ** *** *** ******/*** **/* ******:

*** ********* ** *** *********** **** ***** ***** ******* ** to ******* *** ******** *** ***** ********* **** *** **** reliable ****** ***** *** **** ** *** ******** *** ********* the ******** *** ********* **** ************ ** ********* ********. ** do ****, ** *** ******** ********* ************* ***** ******* ******** and ***** ********* **** *** **** ********* ** * ********* as ********. *** *******, ** ******* *** ******* ********** *** document *** ******* ***** ******* **** **** *****.

********* ** *********, *** *** ****** *** *** **/* ******* are *** **** ****, *** *********** **********:

***** *** *********** ** ******** *********** ** *** ****** ** cameras.

** **** ***** **** ********* ** ****** *** ***** **** the **** ****** *****, *** ***** *** ***** (****** ** standard **) ********* **** **** ****** ******.

***, **** *** ******* ** (** *** ****) ** *** limitation ** *** *****, *** **** **, *** ** *** handled **** ********** (**** *,*** **/*) ** ***** *****.

***** ** * ******* ******* ** *** *****, ******* ** is *** **** ** *** **** **, ** ** **** to *** ******* **. ** *** ****** *** **** *********, we **** **** *** ****** *** ******* **** ***’* ** give ** *** *,***-*,*** **/* ********* ** *** ******* *** configuration ** *** ******* *********.*** ********* *** ************** ** ********* ********* ** *****/*. (******** *****)

*** **** ** **** ** *** **** ** *** **** that *** **** ** *********** ** ******** ***** **% ***** this ****

******, ** **** *********, **** ** *** **********, ******* ***** may *** ** ********* ** ********* **** **** *** **/* on *** *****. ****, ***** **** **** ** *** ***** eliminates *** *** ** ******** ******* *******. ****** *** *** storage ** *** ***** ** ** ** ***, **** ******* to ** ** ****** **** ***** ******. ******** *** **/*, this ******* ** **** * **** ** *******.

Camera ***** ** ********** ********

*** ******* **** **** *** *** **** ********* *** ********* maximum ******* *********, *** ***** ******: ***** ******* *** **********.

****** ***** *** **** ** ****** ******* ** *** ********* consumed *** *** *******. ********* *********** *** **** *************, **** under ***/* ** ***/* ** ****, ********* ** ***** ****, compression ********, ***** **********,***** ******, *** ****. ******* ****** *** ************ ***** *** ***** *************** **** ******* ** ***** *********.

Generally *** ***** ** ***

** *** ** *** *******, ***** *** ********* ********** ******* Genetec *** ********* ****, *** ******* *** ***** ** **** to **** ****** *** ********.

*** *******, ********* ********* ** **:

*** **** ***** ** *********** ******* ** *** ************* ** the *** **** ***** **** ** ** ********* *** - 720P ** ******* ******* ** *****, ***/* *** ****** ** disks.

** *** *****, * **/* ******** ** **** ***** ****** are ****. *** *******, ** ************ / ******* ********(******* **** ****** ****), **** ******* ******* ******* ******* ****** all ******** **** * **/*. ** *** *****, **** ****** averaged ~*-* **/*. ********, ***** ******** *** **** ******, **** high ****** *** *** ***** ****** ****** ***** *-* **/* or ****. **** ***** *** *** ******** **** ******, *** 720p ******, ***** ******* *** **** ********* ********.

**** ***** ***** ******?

**** **** ***** ****** **** ** **** *********, ********* *.***+, or ******* *********** ** ****** ******* ********. *******, **** *** least ********* ** **** ****** ******, ******* **** **** ******* will *** ******* ********, *** ********** ************ **** ***** ** done *** ***** **** ********* ** *******, **** **** ********** machines **** ** ***** *** ******, *** ****** **********.

Large ****** ***** ** *******

***** **** ********** ******** ******* *** ********* ********* ** **** allow *** ****** *********** *** *********, **** ***** ****** ****** (200-300 *** ****** ** ****) *** ********* ******** ** *****, as *** ****** ******* * **** ***** ****** ***** ** failure. **** ** ********* ** ******* ******* **** ** ****** server ** *** ***** ** *******, *** **** **** ********** and ************* ****, ** **** ** ********* ********* ***** *** additional ******** ************.

**** ****** ***** ******** ********* ***** ****** ******** *** **** likely ** **** ********* ******* *** ***** *********, *** **** is *** **** ** *** *****.

Ethernet ***********

*** ***** ******** ****** ** ****** ********** ** *** ******* interface. ** **** ********, ******* ******** ** *** ******* ********* available, *** ** ******* ** ~*** **/* ****** ********** ** less. ****** ********** ******** ***** ******** ******* **********, ****** **** potentially ****** ** ******* *** ******* ** *** ******* *******, or ********* ****** *** ********* ******** ** ** ***, **** more ********* **** ******* ******* ******.

Other *********** *******?

******* ** ***** *************' *** **********/****** ******** *****, *** ****** make ****** ***** ****** ** **** ** ******* *** *********.

  • ********'* ******* ********* ******* *** *** **/* ** * *** ****, *** only "** ** ***" *******, ********* *** ** ~* **/* per ******, **** ****** ** ********* ********.
  • *****'* * ****** *********** ** ** *,*** **/* ********* ********** (******* ** *****), but **** *** ******* *** ********, **** * **/* ****.
  • *******, *** ******* **** **** **************************** "****" *** *******, *** *** *** *** **/* **********, respectively.
  • ******: ************'*********** *** ****** *** ******/ *,*****/* **********.

************?

******** ******* ******* ** *** **-** ****** ******** *** **** ******** ** ******** ** ****, ***** ******** servers **** ** ***** **** ******* ****** ** *** ******. Very *****, **** ****** ***** *********** *** **** ***** ********* bandwidth ******** **********, *** ***** ******* *** ***** ****-*******, *** running **** ******* ** ******* *** ****** *** ** ***********.

****, ***** ***** ***** ****** ***** ****** *** ***, ******* of ***** ******* ****** **** ********* **

Signaling ******

******* ***** ********* *** *********** ******, *** ****** ***** *** claims *** ****** ********** *** ***** ********* ********, ****** **** is *** ** ******* ********* ********* **** *** **** **** the *** ****** ****** *** **** (****, ** ********, ** true ******* *******, **** ****** ** ** * **** **** with * ******* *****).

Take *** ****

**** ** *** ***** ** ***** ***+ ******* *********? **** and **** ** *** ** *** ********.

Comments (36)

But why

One or two customers needed it, so they built it. Now they're offering it to the world to appear innovative...That's my guess at least.

I've done 500 cameras in a single VMS instance. That was to take advantage of some of the existing infrastructure the organization had. They already ample processing power in terms of servers to run the VM in, and the network infrastructure allowed for 10 gb/s in. It also let the IT department have both redundant failover at the software level, along with back up VMs that could be spun up pretty quickly.

What they didn't have a lot of was free rackspace. So there was a trade off in terms of complexity of set up for a savings in real estate. It's not something that everyone would run into, and the degree of complexity isn't that much for an IT department with the skill set for it. But they also gained redundancy for software failures, and the failover VM was on separate hardware.

It's not something I'd ever do with a pre-built recorder because you're sacrificing a lot of the advantages gained by using VMs. And you'd be pretty storage limited. But I'm guessing this is less about the hardware announcement and more about the camera count for enterprise customers.

I am curious if the statistics were done with 500 cameras actually connected and streaming, or was the data extrapolated based on a much smaller number of cameras and then the usage multiplied? I am skeptical if this scenario would be linear enough to do that.

Just added a poll on this: how appealing is a 500+ camera recorder to you? Take a minute and answer above.

"In most networks, gigabit Ethernet is the fastest interface available, and is limited to ~800 Mb/s actual throughput or less"

Yes, my experience is that is burst, with sustained throughput being actually quite less, maybe 60% of the wired connection's rated speed.

Can Miletone and Genetec clarify if that is sustained throughput or burst?

Their numbers are sustained. The ~800 Mb/s is our note, not theirs. I've been seeing 70-80% of rated in any testing we've done, but we haven't done full formal testing of it, either.

Below is the correct info for Avigilon's HD NVR Premium servers. We have a hand full of these in the field with one pushing 230 cameras and ~500Mbps. For large enterprise customers these large capacity servers are very useful IMHO.

I'd be curious to know how well server side VMD works if enabled for every camera on a 500+ camera NVR?

Anyone got any experience with that?

Good question, we've asked Milestone to comment on this and I'll report back when they do.

[Update: Milestone confirms their calculation assumes camera side VMD. Server side VMD of 500 cameras would likely add a very high processing load. Related: VMS Server Load Fundamentals Tested]

I'd be curious to know how well server side VMD works if enabled for every camera on a 500+ camera NVR?

I think the CPU would vaporize in a matter of seconds.;)

Why would you even consider server side VMD and tax the server when the camera can do that for you? I highly doubt that they the manufacturers are planning on that even being tried with their 500 camera appliance.

Yes, one would think so, but to play devils advocate... I have meet some installers that always use server side motion detection - I am not sure why. It could be out of ignorance, or perhaps they find it more reliable, or easier to setup. Perhaps they are using 500 ultra cheap cameras that do not transmit their motion events to the VMS (there are some cameras like this). Maybe it isn't 500 cameras at all, but 500 streams, in which case you might have 250 cameras each with a second low resolution, low FPS stream, and with sufficient number of cores (don't they have 18 core Xeons these days?) then maybe these appliances can handle it. That is why I thought the question was interesting.

In case of Genetec, the timeline is only showing motion with different color if you set VMD on the server. If the camera is doing the VMD you have a continous grey line. Most operators like to see a visible sign of where was motion on the recordings. Motion only recording is not allowed for security reasons.

Displaying edge based motion on the timeline sounds like a basic feature that any VMS would support.

I have not seen the Genetec software, but could it be that you are using cameras that do not send motion events? or perhaps they send them on a different port, and that port is blocked.

What cameras were you using?

We asked Genetec to clarify the server vs. camera motion display, and this is their feedback:

Most vendors provide a simple VMD event while a few provide VMD metadata. Axis cameras, for example, provide us with some additional information such as the exact level of motion. So we receive the motion detection level in % and the size of the green bars displayed in Security desk varies based on the level of motion received from the camera.

Other camera manufacturers provide us with only a basic event motion on/off or true/false information. In this case, we display a full green bar when the motion is on and we display nothing when no motion event is sent.

Limitations of hardware motion detection
When motion detection is performed by a video unit, the following limitations apply:
• Not all units support multiple motion detection zones. If you switch motion detection from being
detected by the Archiver to the unit, the existing zone configurations not supported by the unit are
lost.
• The unit might not interpret the Sensitivity parameter the same way as the Archiver. Therefore,
when testing your motion zones, the results might not be accurately reflected in Config Tool.
• The Motion search task in Security Desk is not supported.
• Motion indicators (green bars) are not shown in the timeline during playback.
NOTE: This limitation does not apply to Axis cameras.

We use server side motion for many reason.

1) Uniformity of detection

2) Unified interface, not logging into each camera individually

3) Smart Search ability in DW Spectrum (NX Witness)

4) We account for the hardware up front

5) We limit each server to 64 cameras, which is modest for the servers we build/spec

6) Camera side VMD isn't always available in the cameras we use (Hik/Dahua), due to the VMS

single point of failure eeek!

prefer my VMS split between multiple Virtual machines and Multiple physical servers

Exacq does not not have a fixed limit, you can license until it craps out. With SATA drives performing at 3 Gbs and up network is the weakest link. Assuming you bond your interfaces plus configure the switch for it and by establishing a secondary viewing & management Lan.

I could be wrong here, but if a client has 500+ cameras, they likely have 10GbE LAN too, right? Why would 10GbE be too costly? Wouldn't a server of this scale be a premium over a cluster of smaller servers anyways? What's another >$1k for a 10GbE NIC?

I really dislike the use of number of cameras per NVR. VMS/NVRs should be rated in throughput with a camera max listed as secondary information. I like how Avigilon and the manufacturer I am evaluating specifications indicate max throughput then max number of cameras. Many still list # of cameras only and you have to dig deep to find throughput information.

Evaluating the throughput rating of NVR's has been a big question of mine for some time and I currently have a design that I have been working on that has over 700 physical cameras with over 1000 camera streams (some are multi-imager cameras). Total throughput is around 12Gbps and storage is approximately 3 to 4 PB for 30 days (24x7x30).

The manufacturer of the VMS we are evaluating claims a throughput of 400 Mbps using their NVR (customized Dell server) and 300 Mbps for 3rd party server. These numbers are recording throughput and that the same rate can be achieved for video retrieval.

The client requested that the project follows their current data center guidelines and that we add to the existing VSphere environment using Cisco UCS servers and a Dell storage area network.

For this project, we evaluated the option of using Cisco UCS B Series Blade Servers (Dual CPU Xeon E5-2660 B420 M4 Blades) with one NVR instance per CPU. The Cisco UCS chassis supports VIC (virtual interface computing) network interface cards that allow for high speed fabric connection directly from the virtual machine to the core network using multiple 10Gb interfaces. The servers would be connected to a Cisco Fabric Interconnect switch that is connected to a Nexus 7004 core via multiple 10Gbe interfaces.

For the storage solution we are looking at Dell Compellent FS8600 storage controllers connected to the Cisco 7004 via multiple 10Gbe interfaces. This solution drops off the fabric at the Cisco 7004 utilizing 10Gb iSCSI to the Dell SAN. For the storage backend we are using Dell S5000 switches and SCv2080 storage arrays.

I would think the server configuration above would provide the 400 Mbps throughput rating equal to the manufactures provided server or even higher. Without having a way of testing or confirming the actual bottlenecks in the NVR platform it's hard to make any assumptions.

The other issue is the cost of the virtualized server and storage area network in this solution is a more expensive option than using the manufacturers NVRs and the management without a qualified IT department would be a nightmare. The manufacturer offers 90TB single NVRs which would provide all storage in the NVR without need of any external or attached storage. From a keep it simple standpoint the standalone NVR would be the best option.

12000 Mbps total throughput / 300 Mbps (400 minus some breathing room) = 40 physical NVRs for this project with 3600 TB of storage. Using 300 Mbps (they recommended 200 Mbps for virtualized) we would need ~60 virtual machines.

Other issues that come up would be server side video analysis and transcoding. What is the impact of storage only on the CPU and at what point of utilizing the CPU beyond this causes any impact to the storage throughput. The manufacturer being evaluated does have a tech paper showing different camera/server configurations and results that help make some assumptions but it is based on their NVR solution.

It would be nice if IPVM could start a section on NVR throughput testing and bottleneck evaluation. I would love to hear from other users here on their experience with NVR throughput, especially in a virtualized environment.

EDIT: One point I forgot to make and was a reason for my comments above. We are using high resolution high bandwidth cameras for all designs now. As such we have a need for high throughput and not high camera count NVRs. The solution I indicated above would only be 15 to 25 cameras per NVR.

NOTICE: This comment has been moved to its own discussion: 700 Camera Server Sizing Question

Andrew

It is not as much the "VMS" that has the limitations rather the architecture. I think all mature VMS at this point should be similar in throughput from the "software" side. As a manufacturer, we constantly evaluate our VMS software throughput versus raw data bypassing our software. The differences are insignificant. When we have compared to our competitors it is very much similar. It comes back to hardware.

There are other factors involved - such as processing but we have found that the problem first arises on the RAID and drive side of things. This is straight math. Processing comes into play when you start to tax the VMS with analytics or other resource intensive items. When people ask how many analytics can i run on a server - the question is similar to how high is up. There are infinite variables. Some times we like to say a camera per processor core but that is a very crude metric since if there is little activity and infrequent analysis that number can grow. But that is similar again to saying how many cameras can i put on a server.

We have conducted an analysis of data throughputs on a variety of hardware environments and will share the results. You also have to look at some other factors. We often tell a customer while your car can drive at 125MPH would you drive it at top speed 24 hours a day. If you have a one ton pickup and load it to capacity how long do you think it will last. Everyone seems to want to push the envelope rather than best practices in design systems. Maxing out systems or even close to maximum is an issue because everyone forgets the what if scenarios. What happens when you have a malfunction or degradation of some sort - how will the system respond.

So you're saying that distributed architecture is the way to go and giant recording appliances are a dumb idea? Got it.

It really depends on many variables. Ultimately, what are the customer objectives. We worked on an airport project overseas where there were 10,000+ channels of video and some "lofty expectations." The design aspect was a major undertaking but the question we asked the customer was who was going to maintain it. Everything was to be virtualized with redundant command and datacenters. Included were all aspects of security not just video. Access, intrusion, analytics, etc.

For simplicity and easy management we have found that RAID10 systems which can easily accommodate 500Mbps throughput are the ticket. Size the number of cameras accordingly. Try not to use 100% of throughput in case of drive rebuilds, etc. 75% capacity would be recommended. If someone wants to be adventurous well...

Today, we offer storage arrays with 60-80 drives in a 4U box. With 8TB drives out there that is alot of storage in a small platform.

Also to take into consideration is fault tolerance and redundancy and how that is handled. Virtualization has some benefits there but to a point.

With respect to giant recording appliances the concern is always what happens in the event of a catastrophic failure. Believe it or not many people still do not understand that having 2 CPU in a single server is not redundancy and if you lose a CPU you lose your system the same way you would with a memory failure.

What is the threshold for acceptable video loss on failover. We have several government clients who record for more than 1 year and will not allow even a single frame loss over the period. So an architecture was designed whereby "long term" storage is written to a single large appliance and a redundant "short term" storage is located on "opposite" servers for a short period of time (days). So in the event of a catastrophic failure there is a buffer period being written elsewhere until the failed device can be re-engaged.

There are easy methods to make giant recording appliances work and no requirement for a PhD to manage and maintain. But just has to be well thought out. As you know as well, the appliance is one thing and the network and power is another story.

How does one manage redundant self healing networks. Site redundancy, power redundancy, etc. It can get complicated. The question we often ask does come back to not just the budget for the system but for the maintenance and upkeep as well, which is a "job."

"But just has to be well thought out. "

Couldn't agree more.

Milestone confirms their calculation assumes camera side VMD. Server side VMD of 500 cameras would likely add a very high processing load. Related: VMS Server Load Fundamentals Tested

Server side VMD of 500 cameras would likely add a very high processing load.

I think the decoding you would need to do before even looking for motion (assuming h.26x) would add at least as much processing as the actual analytic.

I have personally found Milestones recommendations as to what a specific set of hardware can and cannot do to be useless

Michael, what specific issues or problems did you find with Milestone's hardware / sizing recommendations?

"on that hardware you should have no issues with 60+ camera's"

when we find services starting to fall over and other issues when we get close to 40 cam's on the hardware we listed to them, this is without anyone actually accessing the specific server.

I've always found their estimates way off.

Theoretically anything is possible and comes back to the "bottleneck." It is not what they do tell you in the press releases but what they don't tell you.

First concern is the read/write speed of the hard drives which is where you can first back up. So the answer to increasing the throughput is higher speed drives which are disproportionately more expensive and then financially illogical.

Next you have to look at the RAID array configurations. RAID 10 is going to double the Mbps throughput of a RAID 5 scenario. Of course RAID 5 you would lose approximately 25%+ with storage and RAID 10 50% in storage. Unrelated to this is what no one ever seems to consider is what happens when the RAID becomes degraded - testing shows that in a RAID5 you can lose more than 80% of your throughput during a rebuild while a RAID10 is nominal.

Next is the process of virtualization. Using a blade server and virtualizing the distribution and storage arrays.

Once you have figured out the actual throughput then of course we know it is a matter of math. The age old question then of how to make the math work of lower frame rates and resolution which subsequently lower overall bitrates. The question i often ask is if you are going to lower the resolution and bitrates on a high megapixel camera then why did you spend the money in the first place on a camera which has the capabilities to provide higher quality images. Bitrate = Quality.

So yes probably even 1,000 cameras is possible as well if you work the math and the hardware!

You mean I can put up one box and record all my eggs in a single basket! Wow! Think of the savings!

I smell BCDVideo in here somewhere, not that that is a bad thing - but 500 camera server is just asking for trouble if it goes down.

I remember more than a decade ago when we were marketing 32 channel DVRs and we were told that's ridiculous no one is going to buy it - who in their right mind would put more than 16 cameras on a single server and take the risk.

Update: I just saw an old relevant discussion to this. 2 years ago, IndigoVision released an NVR spec'd for 700 cameras / 2,000Mb/s throughput.

Login to read this IPVM report.
Why do I need to log in?
IPVM conducts unique testing and research funded by member's payments enabling us to offer the most independent, accurate and in-depth information.

Related Reports

Mobile Surveillance Trailers Guide on Jan 17, 2019
Putting cameras in a place for temporary surveillance where power and communications are not readily available can be complicated and expensive....
Testing Bandwidth Vs. Low Light on Jan 16, 2019
Nighttime bandwidth spikes are a major concern in video surveillance. Many calculate bandwidth as a single 24/7 number, but bit rates vary...
Access Control Records Maintenance Guide on Jan 16, 2019
Weeding out old entries, turning off unused credentials, and updating who carries which credentials is as important as to maintaining security as...
Winter 2019 IP Networking Course on Jan 10, 2019
Today is the last day to register for the Winter 2019 IP Networking course. This is the only networking course designed specifically for video...
NTP / Network Time Guide For Video Surveillance on Jan 10, 2019
Inaccurate time can lead to missing or inadmissible video, yet this topic is often overlooked, with cameras and servers left defaulted,...
Managed Video Services UL 827B Examined on Jan 09, 2019
Historically, UL listings for central stations have been important, with UL 827 having widespread support. However, few central stations have...
UK: Private Video Surveillance Complaints Down Since GDPR on Jan 09, 2019
The arrival of the GDPR on May 25, 2018, brought fears the law would spark a massive increase in privacy complaints about security camera use....
H.265 / HEVC Codec Tutorial on Jan 08, 2019
H.265 support improved significantly in 2018, with H.265 camera/VMS compatibility increased compared to only a year ago, and most manufacturers...
2019 Video Surveillance Cameras Overview on Jan 07, 2019
Each year, IPVM summarizes the main advances and changes for video surveillance cameras, based on our industry-leading testing and...
Surveillance Codec Guide on Jan 03, 2019
Codecs are core to surveillance, with names like H.264, H.265, and MJPEG commonly cited. How do they work? Why should you use them? What issues may...

Most Recent Industry Reports

The IP Camera Lock-In Trend: Meraki and Verkada on Jan 18, 2019
Open systems and interoperability have not only been big buzzwords over the past decade, but they have also become core features of video...
NYPD Refutes False SCMP Hikvision Story on Jan 18, 2019
The NYPD has refuted the SCMP Hikvision story, the Voice of America has reported. On January 11, 2018, the SCMP reported that the NYPD was using...
Mobile Surveillance Trailers Guide on Jan 17, 2019
Putting cameras in a place for temporary surveillance where power and communications are not readily available can be complicated and expensive....
Exacq Favorability Results 2019 on Jan 17, 2019
Exacq favorability amongst integrators has declined sharply, in new IPVM statistics, compared to 2017 IPVM statistics for Exacq. Now, over 5 since...
Testing Bandwidth Vs. Low Light on Jan 16, 2019
Nighttime bandwidth spikes are a major concern in video surveillance. Many calculate bandwidth as a single 24/7 number, but bit rates vary...
Access Control Records Maintenance Guide on Jan 16, 2019
Weeding out old entries, turning off unused credentials, and updating who carries which credentials is as important as to maintaining security as...
UK Fines Security Firms For Illegal Direct Marketing on Jan 16, 2019
Two UK security firms have paid over $200,000 in fines for illegally making hundreds of thousands of calls to people registered on a government...
Access Control Cabling Tutorial on Jan 15, 2019
Access Control is only as reliable as its cables. While this aspect lacks the sexiness of other components, it remains a vital part of every...
Avigilon Favorability Results 2019 on Jan 15, 2019
Since IPVM's 2017 Avigilon favorability results, the company was acquired by Motorola and has shifted from being an aggressive startup to a more...
Gorilla Technology AI Provider, Raises $15 Million, Profiled on Jan 15, 2019
Gorilla Technology is a Taiwanese video analytics manufacturer that recently announced a $15 million investment from SBI Group, saying this...

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.

About | FAQ | Contact