woodyads

I think a killer in your case Rory is if you are going to try the Raptor and RAID 0 then definitely throw in a separate OS drive with swap file on it. Reason If you set up RAID 0 drives with OS and swap file (virtual memory) then your drives will be jumping from the stream to the virtual memory. you could be better off with no Raptor and putting OS and swap file on one drive and streams on the other. You loose more time moving heads than writing. So get your Raptor 2 high speed hard drives for streaming and cheaper hard drive for the OS and swap file. Or and I haven't put too much thought into this. I am sure most CCTV software could be set up this way. Keep the two stream drives separate and send separate cameras to each drive. Put them on separate controllers (might not be necessary) . This could give better performance on playback than a RAID 0. Furthermore you could bring the streams in on separate network cards. This would reduce the fragmentation of the streaming files and you will only use one disk for review when reviewing one stream so the other streaming disk will be left alone. Drive selection. You would need to test to verify. Cache may be more important than disc speed. As head jumping is you biggest overhead, cache on a hard drive works in different ways, one method is to grab the entire track cause chances are the next drive request will come from the same area. With streaming this is the case. Granted that faster hard drives usually have more cache than slower drives. But scrutinise between different brands. I only refer to reviewing as a problem because if you are having problems with recording you are not going to have a hope reviewing and recording at the same time. Cheers

Raid stands for redundant array of independent drives. RAID 0 is not true RAID as there is no redundancy. Cheers Colin right on the mark there. Techniques for utilising arrays of drives are mirroring, striping and parity. RAID 0 is not mirroring its striping, with no parity (kmurrey you probably meant this above). RAID 0 = Stripe RAID 1 = Mirror RAID 4 = Stripe with parity (dedicated parity disk) (nobody uses this) RAID 5 = Stripe with distributed parity RAID 1/0 or 10 = Mirrored Stripe. (High redundancy quick rebuild very fast) Stripe for speed Mirror for redundancy Parity for cheep redundancy. Parity has a calculation overhead. A slow raid card or OS RAID 5 will kill the machine. Mirroring in theory writes at the same speed but can read like a stripe. But has the cost of halving the disk space. Stripe is fast and cheep but has no redundancy and increases the chances of data loss. If you have 4 disks you have 4x the speed but you only need to loose 1 drive to kill all the data RAID 4 wastes disk space RAID 5 use one of several different algorithms depending on the card or OS. Cards. They vary, not all are capable of what you are told RAID can give you, auto hot spare, live rebuild etc. Speed may also vary. SCSI is faster than SATA. SCSI has many little tricks up its sleeve for speed. Like spindle sync which is advantageous for video playback. But this is rare and the card and drives must be matched. I have only built one spindle sync machine that was a dedicated post production machine, cost about $60k, a genuine case of RAID 0. Today speed and RAID is not what it seems because of the large amount of cash on the drives RAID may not be any quicker in many application or if drives and card mismatch the application. RAID cards tend guarantee reliability not speed. As time passes newer drive will be slowed down by old cards. This can happen in a period of months. CCTV. Tend to write several video streams to on array of disks. So you have a constant write happening, when you read you read one or many streams, jumping between the streams or between the read and the write stream. SCSI has out of order execution, this could possibly help in performance, I am not to sure if ATA now has this I think it is included but not to sure if it is as smart as SCSI. Without a doubt there would be some card and disk testing required to find what's best for CCTV servers. I can't say exactly what it is but the safe way to go for a large setup is to use a NVR SQL server for admin and push all your streams to SANS. (I am talking big installation here). Because of the nature of the streams and how they are recalled on disc I would suspect speed issues from multiple playback being the first bottleneck. So limiting the number of cameras or streams per SANS would be the trick. Just looking from a design bang for buck low maintainance scalability perspective the most efficient way to set up a decent size CCVT is on an existing well built SQL server using SANS for video storage. Drive terminology, these definition get clouded once you start clustering and creating virtual drives or partitions over separate network storage. So I will use these definitions from the view of a single server. Virtual Disk = A group of drives that appear as one Physical partition = a partition that may consist of many disks but is physical independent of other partitions. Logical partition = physical partition or drive may have many logical partitions. How to allocate drive in your server. Rory even though you are not looking at a fully blown server you can still imitate this. First Physical Partition. Two hard drive in RAID 1 (mirrored) with 3 logical partitions 1 for operating system 2 for Swap file 3 for SQL Log files, and log files Second Physical Partition. Three or more drives in a RAID 5 configuration with 2 or more partitions 1 for install files and sever specific applications 2 for network share, to move admin file to and from the sever 3 for data (SQL Data) 4 for Video Stream Data In a normal SQL build 4 wouldn't exist and 1 and 2 can be combined In a dedicated CCTV NVR 1,2,3 can be combined as they are small In an Enterprise CCTV NVR I would use all 4 partitions however 4 might end up on SANS For SQL. the SQL data and the SQL log files need to go on separate physical partitions. So if your drives with SQL Data die you can rebuild from last backup then run the log files that will bring you back up to the minute. I am currently specking a high transaction SQL server and we are toying with a separate arrays for the SQL Log files, and the DBtemp file to enhance speed. CCTV NVR's hardly use the SQL database so this would be overkill for this application. Your small home machine Put your OS and swap file on one disk along with your database etc (See notes about separating database log files from database below) Put your Video on the RAID 0,1,5 fast disks (with database log files or Database but not both) Partition your OS drive 3 ways so swap file and logs are on their own partitions. Otherwise the logs can grow and stall your OS drive and bring the machine down. Yes you do setup logs so this doesn't happen but I have attended more than one server where the logs have gone crazy and bought the server down due poor build standards. Why set up this way, think about the disk head. You don't want them jumping from swap file to video steam, then writing your database By the way on a NVR your live stream buy passes the server so there is no overhead for viewing. I never bothered looking deeply into DVR's but you would have to work out if there are DMA issues with the server. Ineffective use of DMA controllers would mean the CPU could get hit up for interrupts. I am sure this has been worked out but if not there could be some CPU could come under fire. While some of the above setups may look expensive you can see how you can emulate this quite simply and cheeply. There is more to backing up datbases than just tape and buy using two physical partition (disks) to store your Data and logs separately you bring your backups up to the minute. Hope this is helpful.

Unmanned: yes Vandal resistant: no Self Contained: semi Tower-based: yes Wireless: yes Solar Powered: no Surveillance unit and system: no We have a two major issues which our tower systems must overcome. One is the problem safety creates when trying to deliver high availability. The other is the ability to nail down real-estate. I am eliminating climbable towers. Replacing them with four pneumatic telescopic towers on trailers. The trailers have a work platform on top so that we can work from the top of the trailer. All of the trailers are on the edge the pit or on high ground so you need the mast to get over the trucks to one direction but in the other you only need to mount gear 3m off ground level. they are first and foremost comms systems that happen to have a couple of cameras and encoders on them. They use wireless bridges as backbone and two separate mesh systems branching out from there. There is a master trailer that also has fibre running to it and is to have an Orthogon as backhaul. The fibre utilises fibre flow that allows us to go up to 1km without pits. The mesh systems can come in off any of the three trailers to the master for redundancy and the master trailer has redundant everything. All power is supplied by diesel gensets as the power consumption it too high for solar. To use solar we would need too much real-estate making the system only semi mobile. We need to move them for blasts. One of the mesh systems has another 11 solar trailers dedicated to that system alone. Back bone bridges are 5.8GHz, Meshes are 2.4GHz, High speed wirelss bridges are 5.4GHz. Vandal resistance is unnecessary as we are very remote and sealed off by security.

DVD, Satelite encoders are not a part of the network. When I talk about security I am talking about network security. Server updates patches etc. So assuming the reason for deploying a NVR or DVR is you want to use your normal clients machines to for viewing. Therefore you want your sever on the network. You have 50 severs + and you want to do this with minimum fuss. If you have a piece of hardware in a server you can not assume it will be safe to update. You must build a test environment for that server or that group of servers. If you don't do this .....why? I know plenty of IT professionals and organisation that don't know how to build servers properly. Just cause it works doesn't mean its built right. I have two servers that where built by third party IT companies that need rebuilding. One is a SQL server that has the wrong drive configuration. The other is a custer server that I don't even want to start where the problems begin. The vendor just doesn't build enough servers to invest in a team that really know what they are doing. My brother audits network security for a living and the number of companies including IT companies who fail server audits is significant. Recently he audited a large Web page building company, They failed on server audits miserably. I don't expect people in the CCTV industry, vendors and intergraters to get server builds and support right. Its not their main line of business. I leave that up to our server team and they do a very good job.

Kensplace. My total budget for shared systems is $4m. My view are different because I come from an IT background and deal with many different systems. Because I have several systems all adding up to $4m then I can create synergies to soak up the cost of infrastructure to run the CCTV system on. And CCTV is far simpler than most of the other systems I deal with. My CCTV system sits on $300k of shared infrastructure with about $75k dedicated to CCTV alone. If I didn't have three other systems on that infrastructure the CCTV would have to wear the extra $300k (Remote power, mesh and wirless bridges). My needs may seem different but infact they are very similar. Centralisation of systems and administration. Production line mentality (see Model T Ford) Security, reliability and serviceability. Too often people look at the initial capital cost and don't see the ongoing support cost or training or lost time to testing and deploying patches and updates. I don't see how I am putting my eggs in one basket. I can deploy the CCTV system to several different servers. I rely on no one piece of hardware and the synergy between my different system has allowed me to build redundancy into my networks. Can you be more concise? As far as the MS comment goes. Tell me what solution should I use to run my VNR. And what hardware will it run on. And if it all goes wrong. Well its been running for a year now. And it takes up less than 1% of my time.

IT doesn't want servers with non standard hardware in them. And it doesn't want any exceptions to the rule. The CCTV industry doesn't have an argument to be that exception. NVR's can be built on stock standard servers no rogue hardware. I am working at the moment to move three other systems off servers built by third parties. These third parties do not know how to build or support servers properly and they have become security issues. So when you put in a DVR are you considering the customers needs or your own. Are you making sure your server is identical to their existing servers no extra card just their standard servers. Or is that not your problem. This tread was entitled " I haven't really been sold on NVR's yet." Well you won't be until you start looking at the big picture. Look at it from IT's perspective. CCTV is not the only system out there wanting to use IP.

Everything you say there is true. It will be interesting to see how this things works out for this new set of technologies. What is actually deivered and what is not. One of my biggest drivers is trying to get everything on one set of management tools. This pushes us closer to the big names, while the smaller companies tend to have better technologies.

5.4 is leagal in Many contries. Some countries require Radar Detection and avoidance. And there are different power ratings for different countries. I major system I deal with is Modular Mining who were early to the WLan market. They tried to develope there own stuff then ended up going Cisco several year ago. Cisco is not the best stuff but this system works and I don't have to touch it. Modular developed a specialised antenna and they work quite well. They also turned down the speed at the Trucks to 2Mb/s to increase reliability. They only send text so that is enough speed. They also increaced the Radios to 2W. It might be to deal with all the dust in the pit. Or they might just want to flood any other users out of the band. Orthogon developed the technology and Motorola bought them out. So Orthorgon were claiming NLOS before Motorola were on the scene. They use 2 channels and some technology that can reassemble packets that have bounced off other objects etc. Suggest you read their material for a full explanation. I don't think they tell anyone exactly how they do it. When I get one I might give it the full test and see how it goes over dumps. I don't expect it to work NLOS over hills of dirt but I will give it a go. You have probably seen me crap on about tire 1 vendors, Cisco and a like. I know they don't do the best stuff but when dealing with big companies it's quite important to use these vendors. Many small vendors claim to have their security worked out, but quite often its not there. Auditing the security of network products is outside most of our skill sets.

Some very good points for debate. And I nearly did miss something as well and nearly bought a 5.8GHz version. I was just pointing out that 5.4 is a bit of an unknown and to check your country regulations. Yes I totally agree a clean signal is everything. However people who have been in the game awhile have boosted their signals. The Modular system we use which is a property mesh using Cisco gear has 2W radios instead of 200mw. They have been developing their mobile equipment system for 14 years. And as you said power increases reliability. Reliability is what speed is dependent on. I am pretty sure Orthogon disable the 300mb/s if full power is not achieved. It may not be something they have to do, they might to it price point their 150 system against their 300 systems. I will check on this for you, and let you know if this is the case or not. It's worth noting that Orthogon is true non-line of sight. This may be the reason for the excessive power requirements, to achieve the reliability and speed. I am purchase the Orthogon gear in 8-12 weeks. I know of a few other sites using it and know of a site with issues with it. I will post you to let you the findings. I will also check to see if there is any other high speed bridges on the market. And I am looking at laser with 5.4GHz backhaul. As for pricing, yep its expensive but our security and grade requirements are high and the budget allows for it.

That is not always correct, many DVR products cater for this and for intgergration to many administrative authentication server processes. I didn't say DVR's can't be intergrated into active directory, I said they pose a significant security risk if they are. While DVR's may cater for Active directory the fact that they are on a different box with different hardware from the rest of your servers means all of your testing for patches and upgrades has to be done separately. Where as NVR can be put on your hardware on your standard server build with your standard version of SQL. If your DVR is on different hardware to the rest of your servers you can't automatically rollout updates, they must be tested. Yes if you have several DVR's you can pushout updates after the first one is tested but the issues is the time and organisation required to test the first one. There is also a significant security risk in not using Tier 1 or 2 hardware as the developer my be slow to market. To put things in perspective if you are a small company with one site and have 10 servers chances are you will only have 2 or 3 server operating systems/hardware builds with other services like SQL and Exchange over the top. If you introduce a DVR that will increase your server builds by one. If you have several sites that one can grow to several. So it is important to eliminate as many build instances as possible. If you go for a NVR that is SQL based you can load the software onto an identical build as your SQL server. Another option is to load the SQL component onto an existing server and put in a network disk array. There is little network load on the SQL side of NVR's. The other big advantage of NVR's is you increase the usage of existing systems. I.E. The SQL server so you can justify upgrades earlier and moving to higher end servers. For larger companies, IT service providers can charge as much as $2000 per month per server, $24k per year . Plus extra charges for the new instance since new hardware has been introduce. Redundancy. The NVR system we have can be loaded onto 18 of our 20 servers. And 4 of those servers are identical in hardware so we can direct load the set-up from backup. We currently looking at VMware and again the NVR system is totally compatible. The whole concept of VMware is a contrary to the existence of propriety service and storage systems (DVR). So when you go to recommend an DVR to a small company, Ask them what kind of servers their SQL and Mail are on, What kind of service they are getting from their IT service provider. If either of these are is sub standard then suggest to find a better service provider, upgrade the severs to something decent and then put in a NVR instead. Utilise the synergy of the project together to deliver something far better. While you personally might not believe the stability and functionality of the NVR are any better than the DVR, you have opened up the door for them to bring their other services up to a decent standard and fattened the budget for the project. Yes there will be times when there is no synergies or budget. So DVR is a better choice. But the fact remains NVR is far better technology and the true costs and benefits are not always seen by the vendor or the client. I would highly suspect there are more DVR systems out there that should have been NVR than the contrary. I also respect the fact that most small companies server, OS and security standards fall well short of the mark and its not the CCTV integrators job to deliver these services, nor are they in a position to deliver these or recommend these services. I'm only pointing out where we should be heading. Before anyone comments that they can support a server or an integrate DVR on to AD and support it substantially cheaper than above the prices please make sure your are ISO17799 compliant.

Quick question, which DVRs have you had experience with? BTW, it's not called analogue, its CCTV, it can be a mix of Digital and analogue. Sorry for not answering. I only just saw your post. Simple answer is none. But why would I. I run a several system that covers 40-50 km2 comprising of 15 mobile IP trailers. 2.4, 5.8, 5.4 GHz wireless LAN. 2-way radio, gensets, solar panels, battery voltage, hundreds of different sensors on Trucks, Shovels, Drills, Slope radars for monitoring wall movement, Seismic sensors and Cameras All on IP. These all come back to 20 servers in a data room which is monitored from a control room . The cost of the mining operation is $300m per year so we want to know exactly what is happening where. The cameras are not used for security just auditing. The entire system cost $4m and has taken 2 years to setup and tune. I walk into Perth office 1100km away and plug my laptop in and get all the cameras perfectly over the existing link without spending an single sent extra on the pre-existing infrastructure. Why we are not interested in DVR's. We don't want any non standard servers where can be avoided. We can't integrate our active directory into a DVR without substantial security risks. Where as the NVR is stock standard MS SQL so we can integrate active directory and then we don't need to administer any security, We set up groups of cameras, Access Groups, Then give the existing AD user groups access to the Access Groups. Then you just forget it. When a new geologist comes along they are put in the Geology AD group and automatically get access to the Cameras that Geology have Viewing, PTZ or Review rights. Even if a DVR can be administered by AD they are not part of the sever SOE. That means you can't automatically roll out security updates to it. This is a real hassle. Imbedded server software in propriety systems is based on existing server systems and is prone to security flaws just the same. Any decent IT department should stop these serves from interacting with the AD. So you loose the seamless integration into the network. Our long term plan is to locate a master control room in Perth from where we can push out our technology to 10 - 15 mines all over Australia. We are looking at using VMware on massive blade servers so we can load and unload servers as we wish. Tack on Sans and away you go. Hot spare, redundant, scaleable, serviceable, everything. This makes sense because we can use 4 blades to do the job of 200 severs. I go out of my way to standardise everything to maximise flexibility and opportunity. DVR is not standard. NVR can be. Its not about which is the best system for CCTV its about the synergies you can get between all your systems. Rory when you put a DVR in for a customer how many other non CCTV systems are you catering for?

Yeh your right there Rory I did assume IP when the topic is wireless. Have to agree with WirelessEye. Don't use 900 unless you have to. I inherited a 900Mhz non IP camera system that was interfering with GPS in our pit. I still have several vendors using 900 for different non camera systems and I am weening them off it. Replacing it with a big fat IP backbone on various frequencies and channels. 900 is reserved for 2-way radios.

Just to elaborate. While most wireless hardware works, working is not good enough. Being part of a large multinational its a real headache to get wireless hardware to jump through the hoops for approval. For integrators it must be a real nightmare. You just get use to setting up one device then your next customer tells you you can't use it on their site. I constantly have third party vendors coming to site with different telemetry systems that don't fit our standards. "But we have it running down the road at such and such." I tell them to develop to the toughest standards so that their solution will suit all sites. That's why I say no-one from the CCTV industry is good at wireless. As an integrator you don't want 30 different solutions. So my advice is align your solution with a large tight company. A big multinational Mining, Banking, Casino or Airport company. I also agree that Cisco and the other big names don't have the best stuff. But they do get through the corporate hoops and the interface are compatible with enterprise systems. Sometimes these large corporations want Cisco because their switches and routers are Cisco and they want to manage them from the one interface. That's a pretty good reason. We are currently working with Tropos to get their Mesh through the corporate hoops. Delivery date is still a couple of months away and it will be interesting to see if they can deliver. If not I will look at other systems.

No-one in the CCTV space is good at wireless...period. Stick to Cisco, Orthogon (Motorola) Tropos. Etc. There are still issues with WAP2 and other security protocols even with the best. And at some point it needs to come back to a switch. You need to be thinking high temperature, low temperature, Viop capabilities, low power consumption, variable voltage, Qos compatibility, packet filtering, backplane speed, manageable devices, again Cisco, Nortel. You need to be thinking carrier grade, military grade hardware. Don't put your cameras and wireless in the same basket. Put your wirless in the basket with your switches routers and servers. And your security servers should be in the same basket as your mail server and SQL servers.

Pretty hard to fault DVTel lattitude

Rory has some good advice on performance although codecs change pretty quickly. I have had good reliability out of mine in a very tough environment. The server software is great. I haven't looked at any others but I can't imagine anyone doing it much better. The database is well designed, all the third party products are also done well. Very stable, scaleable and standardised.

If your cameras are effected by wind movement. For instance if they are mounted on a pole as opposed to the side of a building, Then the codec is not as efficient in encoding the picture. Codec's only need change the pixels in the picture that change. If nothing in the picture changes then they are very efficient. I had some cameras mounted on the leg of a comms mast. As the mast swayed in the wind as all masts do. The legs twisted changing the direction of the camera. I fixed this by building an new mounting that attached to two legs eliminating the twist. This halved the bandwidth of the camera.

I would recommend you focus on the server not the camera. Server software can use many different cameras. So you want something that can take a mix of cameras as time goes on. You don't want to end up with a camera that requires a specific piece of software to operate. I am using DVTel and the server and client software is very good, well designed and bullit proof. (I have an enterprise IT background not CCTV.) however I am looking at different brands of encoders at the moment. I am sure that several of the other severs are very good as well. DVtel do have three server levels and they realy make their money off the encoder and camera conectivity. So for low quantities of cameras they are very cheep. Also if you are looking at IP you should be thinking Client/Server software. Not a single PC. Again the licencing for clients is very reasonable.

Don't forget camera movement. If your cameras are not mounted on solid objects i.e. comms masts, light poles, they will create larger files.

I have seen a couple of people deal with solar like me. This sets up a whole different range of requirements for a new segment of the market. I am spending $50k just to get two cameras into the field so there is money in it for any camera developer. I am in the safety and productivity arena not security. So the rules are slighly different. The industry is mining so it is a big new market for the cctv industry. Here's what we need. Low weight, as we are mounting the camera on masts. We are leaning towards pneumatic masts and steering away from climable masts. so low weight is important. I am about to order 2 x 15m with 40kg head weight. The cost of these are $30k each. Low power. 24AC is just out of control for Solar power. I have to build sky lab to power 2 cameras. Powerful zoom. We are looking up to 4km away. CC direct to digital. Analogue is as good as dead for IP customers. simplify and remove the analogue legacy. Upgradeable Codec. So our biggest constraint is power and weight. I spent $120k on a camera project with just 5 cameras. But the cameras themselves are only worth $4k. I justify the expence by using the synergy of the remote trailers for other IP projects. I have just had another $70k approved for refirbishment of 2 remote trailers and $300k for 2 new trailers. The only thing stopping me buying 30 cameras is the weight and power consumption.

I am currently using Pelco Esprit PTZ's. I am looking at installing a couple more on remote trailers. As I am looking at useing pnumatic masts of about 20m tall the cost of the mast is about $35k in order to take the head weight of 2 cameras and a microwave unit. The Pelco Esprit's weigh in at 9kg I require a decent zoom lens and I doubt there are any dome's capable of the required zoom. We are looking at Haulpacs 2km away across a pit. and are power hungry. If I can drop the weight of the cameras I can reduce the cost of the mast significantly. Any Ideas?

IP is a way better technology, but you really need the synergy of other projects to raise the quality to justify its cost so that you receive the resources required to set up the network properly. The average company network administrator lacks the skills and resources required to set up a IP network for a security system. Sorry guys but you can set up far more advanced monitoring, redundancy and security on a IP system that you will ever be able to on an analogue system. Claims to the contrary only strengthen the argument that network administrators and people setting up IP video systems lack skill and resources to do the job properly.

If you are looking at the maximum number of cameras you will need to look at your entire network. If you are multicasting 2 streams per encoder at 4-sif 25pfs and say they each stream created a 2mb/s stream rated. Then you must look at the lowest speed device on your network. For instance if you have a printer with a 10mb/s jet direct box on it then you shouldn't go above an aggregate bandwidth of say 6mb/s or 1.5 cameras. Better off using the one stream for viewing and recording this allows you to go from 1.5 cameras to 3 cameras. Better still get rid of all 10mb/s devices off you network. I would also recommend designing your network around the cameras and filtering out back feed via port filtering on your switches. You should do this around all wireless gear anyway. Yes you will need to have all managed switches with Layer 3 control to do this. Watch out for other low bandwidth devices. Old printers, old Jet direct ports, IP based card swipes, non closet hubs and switches used as workarounds, wireless devices. As a rule don't purchase anything that has less than 100mb/s and make sure all switches and managed and have port filtering. Do not purchase any wireless devices that can't port filter on both the radio and ethernet side.

Some good information there. This why I joined this board in the first place, to learn off other peoples experience. Couple of questions. Which encoder did you use. Did you find any other brand of encoder was better. When you mention frame dropping, how many frames are you talking about? How long was it dropping for, how many cameras where you viewing. Does the frame freeze or go black? Exactly what is you application. Tell us more about it and what are the constraints. Distances, Frames per second, recording etc. Comments I don't think any vendor will guarantee against frame dropping as it is dependent on the clients network. The majority of customers don't have their networks set up correctly. I am a bit puzzled by the frame dropping. I can run my encoders flat out with no frame dropping. I can also run several flat out with no frame dropping. You should be able to diagnose if the dropping in in the encoder, network or computer. I am interested in your application as I am about to put in a system that checks fragment size of rocks in a bucket and also checks the bucket for lost teeth. Looking at using Tropos Wireless LAN for these applications.