HTPC for Plex with Windows Storage Spaces – Part 3

HTPC build for Plex three part series:

1. Hardware build and Storage Spaces
2. Plex server and clients
3. Performance

I’ve had a single disk Home Theater PC (HTPC) running Plex for a while now but with my ReadyNas nearing the end of its useful life, I decided to kill two birds with one stone: build an updated HTPC with drive redundancy to also take over the functions of my aging NAS. My HTPC stays on 24/7 anyway so this makes perfect sense. My design goals for this were to build a small, quiet, low power, data redundant and sufficiently performing box that I can stuff into my TV cabinet. The extent of the duties for this HTPC will be video streaming and file sharing/ backup, no gaming. This series details my build, Plex server, Plex clients, Windows Storage Spaces, as well as the performance of the storage subsystem.

Performance

In these performance tests I want to focus on the main activities my HTPC will be undertaking: file read/ write operations and streaming. I tested using both Parity and Mirror Spaces to demonstrate the capabilities of each.

WD Red Baseline (Control)

First to set a baseline for WD Red 3TB HDD, here is the observed write performance with a single 40GB file write operation (from C:\ to Z:\). The copy took around 4.5 minutes and the drive topped out around 145 IOPS. Subsequent read performance tests top out around the same level. Considering these disks have been reported to spin at 5400 RPMs, frankly that’s really not too bad.

Windows reported ~142MB/s transfer speed:

These drives produce absolutely ZERO audible noise. No clicking, no head seeking noise, no rotational noise…nothing. With the cover off of this box, all that is audible is the 3 spinning fans (case, CPU, PSU). Under the TV cabinet, my build is dead silent.

File copy between Mirror and Parity Space

Test constants:

C:\ = SSD
N:\ = Mirror space
M:\ = Parity space

This test demonstrates the performance capabilities of a Parity Space using the WD Red disks. Disk performance copying multiple files from a mirror space (N:\) to a parity space (M:\) was fairly poor, averaging 33 write IOPS on the parity space. Observed read performance on the source 2-way mirror space was low at 25 IOPS on average, but that’s all it was being asked to do. This is somewhat expected however, as one of the caveats with parity resiliency is reduced write performance.

Once again, the Windows file copy dialog tracks very closely to the observed maximum write performance in Perfmon.

Power consumption of the system under test varied between 50 to 75 watts. Very good!!

Write performance of Mirror and Parity Spaces:

Test constants:

C:\ = SSD
D:\ = Mirror space
M:\ = Parity space

Here you can clearly see the write performance disparity between a two-way mirror and parity space. Copying a 4.5GB file from SSD (with very high read performance) to my two-way mirror space yielded very reasonable write performance according to the Windows file copy dialog. The overhead of the mirror operation appears to be costing around 20 IOPS.

The write activity of the physical disks participating in the mirror.

That same 4.5GB file written from SSD to my parity space (M:\) yielded significantly lower results (almost 3.5x lower):

Here is a more detailed view of the write performance against the parity space:

Read performance of Mirror and Parity Spaces:

Test constants:

C:\ = SSD
D:\ = Mirror space
M:\ = Parity space

Copying the same 4.5GB file from each space back to the SSD yielded better results overall. The read performance of the parity space during this operation is better but still below what the mirror space or even native drive are capable of:

Copying the file from the mirror space to the SSD was higher performing than the parity space and on par with native disk read performance, but the gap isn’t as wide here.

Plex Streaming Performance: Single File

Test constants:

-Physical disk 1 and 2 comprise a mirror Space
-Plex clients in use: Roku
-Media in use: single file, highly compatible, 1080p

Streaming being a highly sequential mostly read operation, there isn’t a great tax put upon the system resources. Multiple streams and transcoding complicate this a bit. The following chart shows the performance of a single video stream from my HTPC using a mirror Space to my Roku client. Interesting to note that the C:\ drive is busier than both disks in the mirror space, but all reads are sourced from a single disk.

Plex Streaming Performance: Single File, skipping around

Test constants:

-Physical disk 1, 2 and 3 comprise a mirror Space
-Plex clients in use: Chromecast
-Media in use: single file, highly compatible, 720p

Trying to force spaces to utilize all disks within a vDisk, I manually skipped around four times within a sample media file. Here you can see that with every color change within the performance chart is where I jumped to a different time within the media file. Almost every time I did this, Spaces offered up a different disk to be read from. The one exception is during the period between 7:40 and 7:43 where I performed a jump but the same disk was used. Otherwise, all three disks in  my mirror Space were used to read the file.

Plex Streaming Performance: Multiple Streams from One File

Test constants:

-Physical disk 1 and 2 comprise a mirror Space
-Plex clients in use: Roku, Chromecast, PS3 (DLNA)
-Media in use: single file, highly compatible, 1080p

To satisfy my curiosity, regardless of how infrequently this situation might actually occur, I wanted to see what the impacts were if I kicked off multiple streams of the the same file. I chose a mostly compatible file so we get the benefits of Direct Play here. Three simultaneous streams requiring transcoding would probably not work so well. There is a CPU spike when the third stream is launched and minor spikes on disk 2 for each stream event. You’ll note here that all reads are coming from disk 2. Looking at each TV screen individually and subjectively, the playback was completely normal.

Plex Streaming Performance: Multiple Streams from One File, 3 Disk Mirror

Test constants:

-Physical disk 1, 2 and 3 comprise a mirror Space
-Plex clients in use: Roku, Chromecast, PS3 (DLNA)
-Media in use: single file, highly compatible, 1080p

Just to see if there is any impact to performance, I ran this same test again but with three physical disks in my mirror Space. I would have expected my reads to be coming from at least two disks but as evident here, disk 1 is doing almost all of the work. Interesting to note that overall spikes are much lower now with read performance hovering around 1 IOPS. The takeaway here is that this third disk in my two-way mirror Space doesn’t add much from a performance perspective.

Plex Streaming Performance: Multiple Streams from Multiple Files

Test constants:

-Physical disk 1 and 2 comprise a mirror Space
-Plex clients in use: Roku
-Media in use: three files, one incompatible requiring transcoding, 1080p

The following chart shows the effects when additional streams are added using three different media files, one requiring transcoding. You can see that system resource usage is relatively low with the first two streams, things change dramatically with the introduction of the third file. Transcoding means heavy CPU usage as evident here. Disk activity with 3 different files being accessed simultaneously jumps up quite a bit too. 

Zooming in here looking at the disk IO, you can see once again that almost all read requests are satisfied from a single disk. Hmm, where’s my striping performance??!

Here is the Plex transcoder in action:

Network Performance

Network performance of the Plex server with a single HD media stream is very reasonable. There are spikes north of 11Mbps but for most of the duration the  transmitting bandwidth stayed around 2Mbps.

Conclusions:

• The WD Red HDDs are a very quiet, very low power option that yield decent disk performance. Performance is more than acceptable for an HTPC that doubles as a NAS.
• Two-way mirror Spaces are the highest performing option in Storage Spaces but come with the highest disk cost as well (2x). Read performance is on par to that of a native disk with Spaces adding no discernable overhead, writes cost ~20 IOPS in overhead. If you have HDD capacity to spare, this is the resiliency option you want!
  • While writes clearly hit all disks in a mirror Space, observed read operations from streams are satisfied from a single disk in the Spaces pool. Jumping around within a media file does force reads from all disks in a Space.
  • 3 disks in a Storage Space really doesn’t buy you much other than additional capacity. With a 1-column two-way mirror you still only have two copies of data, on two physical disks. Read and write performance is not increased here.
• Parity spaces will work fine for Plex and video streaming in general, as video streaming is sequential and read performance is acceptable. Parity spaces suffer massively in reduced write performance so copying files to or moving files around on your HTPC will be much slower. The trade off for poorer write performance in a parity space is more overall usable capacity (1.5x consumed in a parity space vs 2x in a mirror space).
• Plex makes excellent use of system resources and can handle just about anything you can throw at it. The Plex server doesn’t even break a sweat with highly compatible media types, even with multiple streams. Transcoding is CPU intensive and should work fine for a single stream, multiple streams may tax your system and degrade the viewing experience.

This post originated at Exit | the | Fast | Lane – weestro.blogspot.com