Sorry if this is somewhat not specific to unraid, but I plan on building a server to be used for serving audio/video to my house. It will also be used to store HD security video which I do not want to disrupt/slow down the streaming traffic.

 

I plan on homerunning all Ethernet to a switch in the basement where all my hardware will be racked. I guess I need to know if I would have to add a second Nic on my server or some other solution so my 4+ HD cameras do not interfere with media streaming.

 

Thanks.

 

You probably have a gigabit (1000Mbps) network. Streaming (in or out) multiple hd videos will not be limited by the network. Depending on your cameras I would expect them to output somewhere in 10-15Mbps range at most. So even with 4 of them, you are looking 40-60Mbps which is almost nothing. Eg. Blu-ray has a maximum bitrate of 40Mbps so in theory you could stream ~25 of them through the gigabit interface.

Thanks. Do you see any bottlenecks in a system that may require saving ~4 HD camera streams while serving ~4 HD movies? Perhaps the drive read/write speeds? RAM?

 

This is worst case, but it would be good too plan ahead.

 

Drives are fast compared to HD stream requirements. Though unRAID's parity calculation and writing causes a speed decrease, you should be seeing 30-45MBps write speeds to the array. Compared to the 1-2MBps (10-20Mbps) for a single recorded HD stream you should have no problems. unRAID's memory consumption for basic disk operations (including SMB) is very limited.

 

I would not expect any problems with the 4 + 4 scenario.

There shouldn't be any issues with the available bandwidth ... especially if the security feeds are motion-activated (which means it's very unlikely all will be simultaneously active).

 

Nevertheless, due to the nature of UnRAID, I'd be inclined to install a cache drive and set the share for your security video to use the cache.    Then all of the writes will be to the cache drive, which is MUCH faster than writing to the protected array.

 

I have no personal experience on HD surveillance but I'm planning to do similar things so I researched this a bit. Page 127 on the following guide from Axis details bandwidth and storage requirements for HD surveillance:

http://www.axis.com/files/brochure/bc_techguide_47847_en_1305_lo.pdf

 

12.1.1

Bandwidth needs

In a small surveillance system involving fewer than 10 cameras, a basic 100-megabit (Mbit)

network switch can be used without having to consider bandwidth limitations. Most companies

can implement a surveillance system of this size using their existing network. When implementing 10 or more cameras, the network load can be estimated using a few rules of thumb:

- A camera that is configured to deliver high-quality images at high frame rates will use

approx. 2 to 3 Mbit/s of the available network bandwidth.

- With more than 12 to 15 cameras, consider using a switch with a gigabit backbone. If a

gigabit-supporting switch is used, the server that runs the video management software

should have a gigabit network adapter installed

 

Based on this using a cache drive to support 4 HD camera streams would be an total overkill performance wise. The 4 cameras would be using ~5% (1,5MBps out of 30MBps) of the minimum write capacity of the system. As an example I get (and you should too since I'm using basic components) consistent 45MBps for 3TB WD Green drives.

 

But with SSD cache you would benefit from smaller energy usage since writing directly to array would cause both the data and parity disk to be spinning all the time. With cache you can schedule a daily move from cache to array. And perhaps you could have some other use for the cache drive too.

The mover can run hourly or more with an SSD cache. It's small so frequent moves may be required. There should be no performance penalty when running the mover due to the Ethernet bottleneck.

Since the only point for using a cache drive in this particular use case was the energy consumption, it would make sense to schedule the mover as rarely as possible. Hourly mover would mean that the data and parity disks would be spun up most of the time, depending on the spin down delay of course. Which dilutes the whole point. Mover schedule would have to be a compromise between the energy consumption and risk of losing data on cache drive failure.

 

I'm not too familiar with the current SSDs' endurance for this kind of constant re-writing. You could also consider a 2,5" laptop spinning hard drive for the cache drive.