Pulling ahead of the RAID 5 Pack: QNAP TS-509 Pro Reviewed

[thiggins]

The QNAP TS-509 Pro sets new performance highs. But at almost $900, ya gotta pay big to play. [article link]

QNAP state that they don't support Jumbo Frames becuase it is a limitation of the hardware NIC. They found that the trade off is that they get better performance without JF support using this NIC chipset rather than a slower one with JF support.

Also, they have said that they will support cameras in an upcoming firmware release due to customer requests for the feature.

[boerner]

Nice review, as always. I would be really curious to see how FreeNAS (both the 0.6 and 0.7 variant) run on it (if at all). Also would love to see how OpenSolaris would work.

[Dennis Wood]

Tim, first of all thanks for the all the review information and the inspiration for our own little test lab. We're working on building/reviewing an NAS system for video editing and archiving as it would seem that gigabit ethernet is almost there for a cost effective workflow. What we've found is that our results more or less match up with what you're seeing with a few important exceptions.

We've been doing extensive testing over the last week of just about every scenario possible in terms of writing and reading from RAID 0 and RAID 5 arrays not only on the same box, but over gigabit LAN as well between workstations and the NAS. The tests involve a batch file that incorporates the iozone tests, a five GB file set copy, and a ffmpeg encode splitting an MP4 file into two streams and writing them from the source drive/array to the target drive/array. Every scenario is tested in both directions, logged and time stamped at each step so that we could evaluate what was happening.

The Intel NAS we're testing (with 4 x 1TB Seagate ES2 drives) is showing real world transfer speeds of 60MB/s but we are only seeing this in the downstream direction from the NAS to a RAID 0 array (3 drives, Nvidia chipset). Once the results are tabulated we'll post them up. The ffmpeg encode results are very intriguing.

We've purchased the QNAP TS509 which should be here in a week or so and we'll compare. The Intel NAS has been load tested from multiple clients so we can compare to the QNAP using dual gigabit ports in the load balancing scenario. We're using a Gigabit smart switch that supports trunking (watered down 802.3ad) and have two workstations with dual gigabit onboard ports supporting teaming. Should be interesting :-)

Cheers,
Dennis Wood

[thiggins]

Thanks for the info, Dennis. Are you saying that gigabit Ethernet is almost as good as direct attached?
You might want to look at the Fast Large File Transfers on Windows Shares? Jumbo Frames? article.

[8steve8]

i happened to see a visitor from this page to a post i have with a song in it, seemed bizzare...

i think you have the wrong url:

ETHERNET PERformance:
http://www.alternativerecursion.info/?p=48

RAID Performance:
http://www.alternativerecursion.info/?p=31

[Dennis Wood]

Great read that. The link didn't work but google came up with this: http://www.alternativerecursion.info/?p=48 I have a G2S laptop with Vista SP1 which is not too impressive over the LAN...however the registry change suggested there is something we'll test.

In response to your question, yes, we're seeing 40MB/s transfer rates from the Intel NAS to a RAID 0 box (Asus P2N32 MB with dual gigabit LAN in team config) with Nvidia's version of RAID 0 striped across 3 drives. The only result that is better, is when writing from a RAID 5 to a RAID 0 on a workstation with the Intel based Asus P5W motherboard. That one uses an intel RAID chipset (we're using 3x300GB drives in RAID5) as well as a Jmicron used for the RAID 0 (two 320GB drives in RAID 0)

The measured test uses about 5.3GB consisting of 122 files taken directly from a Sony EX1 SxS card. These files are MP4 HD video files ranging in size from a 30MB to about 1 GB and the related metadata. The switch being used is a Dlink 1216 which supports jumbo frames, and all of our test workstations are config'd that way. I have no way of telling what the Intel NAS is using, but I'm assuming as per your review, it's not using jumbo frames. What's interesting is that one of the "cheap" workstations just uses a Dlink 530T card and we're measuring decent results. Here's a few numbers:

1.
Intel NAS to RAID 0 Workstation (Asus P5W, C2Duo, onboard Intel RAID 0, 2x300GB drives)
59.5MB/s file transfer, and ffmpeg encode at 32MB/s

RAID 0 Workstation (Asus P5W, C2Duo, onboard Intel RAID 0, 2x300GB drives) to Intel NAS
47.9MB/s file transfer, and ffmpeg encode at 21MB/s

2.
Single Drive workstation to Intel NAS
26MB/s file transfer, and ffmpeg encode at 18.7MB/s

Intel NAS to Single Drive Workstation
31MB/s file transfer, and ffmpeg encode at 19MB/s

3.
Intel RAID 5 to RAID 0 on same Workstation (Asus P5W, C2Duo, onboard Intel RAID 0, 2x300GB drives)
68MB/s file transfer, and ffmpeg encode at 51MB/s

Intel RAID 0 to RAID 5 on same Workstation (Asus P5W, C2Duo, onboard Intel RAID 0, 2x300GB drives)
60MB/s file transfer, and ffmpeg encode at 20.7MB/s

With both Nvidia onboard Raid 0 and Intel onboard Raid 0 (two different workstations) we're measuring nearly identical speeds of 40MB/s when writing from the Intel NAS to the respective workstation's RAID 0. The only thing faster we've found is from the RAID 5 Intel to an ESATA attached drive, or RAID 0 array...and that's only a bit faster ranging from 63MB/s to 70MB/s with ffmpeg encode rates exceeding 50MB/s. Because the ffmpeg script is splitting a 466MB file into two streams and writing them simulataneously, it's becoming obvious that a RAID 0 target is by far the best for this type of work.

[Dennis Wood]

I missed that RAID discussion Steve..and it's excellent. What we're seeing here in our testing is that RAID 5 absolutely kills our ffmpeg encode as two streams are written simulutaneously to an ICHR7 intel RAID5 (local). The Intel NAS we're testing handles the streams much better either due to the improved chipset it uses, or the fact that processing for the RAID5 writes is handled by the NAS, and not the workstation from which the encode originates. I'd agree...RAID 5 tests here showed similar dismal results during encodes: http://www.maximumpc.com/article/rai...red?page=0%2C4

Being that some of our renders typically take 8 hours, the performance hit of RAID5 in this scenario makes RAID0 by far the best option as a target for the encoded/streamed files.

Cheers,
Dennis.

[thiggins]

You certainly have a strong stomach to be doing video renders directly to a NAS vs. local storage!

It makes sense that RAID 0 is going to give you higher performance than RAID 5, since that is what it is designed for.

If you really want to do RAID5, I'd look into a controller card.

[Dennis Wood]

The goal is to have a workable solution where a video project and its source files sit on the NAS so that multiple workstations could access and edit them, leaving them on the NAS. Renders would likely be run (given our test results) so that any encodes are written from the NAS source files to the local RAID 0 drives and then archived later back to the NAS. An XDcam EX1 outputs 35mbps variable bit rate files at 1920x1080 resolution which would require a maximum of 5MB/s or so for each stream in an edit. Theoretically, the NAS should be fine to serve up the typical 3-5 streams that would be edited simultaneously. I should point out that studios with large budgets would likely just use a 10GB SAN, but we're trying to work something applicable for our target market..the budget minded independent filmmaker.

This may all change once we load test with a few workstations hitting it simultaneously. This is where the Qnap's dual gigabit ports and 802.3ad supportive switch "should" make a difference.

From the RAID card review I linked to earlier, it looks like even high performing PCIe RAID cards slowed their render tests considerably over the onboard RAID 0 option..and the fastest encode was in fact to a RAID 0 array based on the test motherboard's intel raid controller. This is a great example of where the numbers tell a very different story than what may have been predicted. I gave up using HDtach as the numbers it was providing are way to optimistic once compared tests using actual files, CPU loads etc.