Previous posts at in-koherence have been rather skeptical of using SSDs as recording storage in DVRs. SSDs have a lifespan that is largely dictated by the amount of data written to them. This may not be much of a problem if you record one or two shows a day. However many users set up recordings for series which they might watch (but for some reason never find the time to…or maybe they decided it wasn’t such a great series after all, but who has time to cancel the subscription to the series?) This is amplified if multiple members of the household set up recordings on the DVR. The next thing you know it your four-tuner DVR is recording 20 hours of shows a day. For all its faults, the good old mechanical hard drive is superior in having a write limit that’s so high that it’s generally not considered.
But with rapidly falling prices, larger capacities (with correspondingly higher endurance ratings), and the increasing difficulty of finding non-SMR 2.5″ hard drives, the time has come to give SSDs a harder look. So we took a mid-grade SSD and ran the first SSD-based Project Entangle through its paces.
The Testbed: A-Data SU800 128 GB
The drive of choice for this experiment is the A-Data SU800 128 GB SSD. 128 GB is typically lower than what you’d use in a DVR, however since the main objective is to see how long it lasts the lower capacity (and correspondingly lower endurance) suits us well. Endurance tends to scale with capacity, so the results here are easily applied to the 256 GB, 512 GB, 1 TB, and 2 TB versions of the SU800 – these devices have endurances of 200 TBW, 400 TBW, 800 TBW, and 1,600 TBW respectively.
The SU800 utilizes IMFT (Intel-Micron) 3D TLC NAND and a Silicon Motion SM2258 controller. This isn’t the fastest SSD around, however it’s more than fast enough for handling a four-tuner DVR. More important is the SU800’s endurance rating, and the 128 GB version is rated for 100 TB of data written. Those of you with inquiring minds can take a look at Tom’s Hardware’s review of the SU800.
Measuring Write Amplification
While the 128 GB SU800 is spec’d with a 100 TB write endurance, that doesn’t necessarily mean you can store 100 TB of recordings to it. The endurance needs to be de-rated by the write amplification of the application.
Those of you familiar with write amplification can skip ahead, but for the rest of you…
Write amplification is the ratio of data actually written to a drive versus the amount of data that your application wrote to the drive. These two can differ for a number of reasons. One is the overhead of various layers in the storage system, such as the filesystem. In addition to storing the file itself, a filesystem stores information about the file such as when it was created, when it was last updated, when it was last accessed, what sectors on the disk the data occupies. etc. Depending on how the file is created and accessed these filesystem items may be updated very frequently, leading to a higher write amplification. A second source of write amplification is the application’s pattern of writes. As an extreme case, say an application appends one byte of data to a file every day. After 7 days, the application has written 7 bytes. However usually you can’t access data on a drive (SSD or mechanical hard drive) in one byte increments. Data is available in blocks. So to write that one byte, the block containing the byte needs to be read from the drive, the byte is altered, and the block is written back. Blocks are generally 4096 bytes for hard drives (older drives may use 512 bytes), and on SSDs may be larger depending on the flash block size.
In the case of SSDs it’s really the flash controller that knows how much data was written to the flash, and this can usually be accessed via the drive’s S.M.A.R.T. statistics. As an example, the SU800’s smart reports:
Device Model: ADATA SU800
Serial Number: 2I3020025196
LU WWN Device Id: 5 707c18 10069bb5e
Firmware Version: R0427ANR
User Capacity: 128,035,676,160 bytes [128 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
...
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
1 Raw_Read_Error_Rate ------ 100 100 000 - 0
5 Reallocated_Sector_Ct ------ 100 100 000 - 0
...
241 Total_LBAs_Written ------ 100 100 000 - 95378
242 Total_LBAs_Read ------ 100 100 000 - 4253
...
Device Statistics (GP Log 0x04)
Page Offset Size Value Flags Description
0x01 ===== = = === == General Statistics (rev 1) ==
0x01 0x008 4 8 --- Lifetime Power-On Resets
0x01 0x010 4 170 --- Power-on Hours
0x01 0x018 6 1955747064 --- Logical Sectors Written
0x01 0x020 6 9846037 --- Number of Write Commands
0x01 0x028 6 278770604 --- Logical Sectors Read
0x01 0x030 6 1093339 --- Number of Read Commands
...
In order to determine how much data was written, the relevant entries are “Total_LBAs_Written” and “Logical Sectors Written”. “Logical Sectors Written” is a count of the number of 512-byte sectors written, however seems to wrap around to 0 whenever it hits 4294967296 (2^32). The “Total_LBAs_Written” value appears to increment by one for each 32 MB written.
Project Entangle Write Amplification
While Project Entangle wasn’t designed with SSDs in mind, a lot of effort went into making writes to the drive efficient since writes to mechanical hard drives are rather expensive. While mechanical hard drives are constrained by how fast the platters rotate, the far larger constraint is their high access latencies. So it’s beneficial to minimize random accesses by reading and writing data in large chunks, minimizing filesystem metadata updates, and in general not peppering the drive with requests. These turn out to be advantageous for SSDs as well.
Over a period of about two weeks, 3,046,342,672,384 bytes, or about 3 TB, of recordings were stored to the Entangle’s filesystem. This is a sum of the size of all recording container files that were written. Over that same period, the SU800’s Total_LBAs_Written reported 3,069,469,601,792 bytes written. This gives us a write amplification of about 1.00759, or about 0.8%.
(Entangle container files use a box structure inspired by, but only loosely similar to ISOBMFF. They contain various metadata boxes and are approximately 0.6% larger than the transport streams they hold.)
Expected Lifetime
Based on the write amplification of 1.00759, if we de-rate the SU800’s endurance of 100 TB by 1% we can assume the drive is good for about 99 TB of recordings. In our test setup, that would get you about 64 weeks, or a bit more than a year. This isn’t very long, but when you consider that you’d probably use the 512 MB or 1 TB variant of the SU800, things look a bit better. The 1 TB version would last about 9 years given the same recording pattern.
| Model (capacity) | Endurance Rating (TBW) | Expected Testbed Lifetime |
|---|---|---|
| 128 GB | 100 TB | 64 weeks |
| 256 GB | 200 TB | 128 weeks |
| 512 GB | 400 TB | 256 weeks |
| 1024 GB | 800 TB | 512 weeks |
| 2048 GB | 1600 TB | 1024 weeks |
The key here is with the same recording pattern, so let’s take a close look at what the test setup recorded.
A total of 736 recordings were made over the two week period on 11 channels. More details can be found in the table below.
| Station | Description | Shows Recorded | Bytes Recorded | Hours | Average Bitrate (megabits/s) |
|---|---|---|---|---|---|
| KGODT | ABC (720p) | 157 | 689312272384 | 134.96 | 11.35 |
| KBCWDT | CW (1080i) | 120 | 458118934528 | 64.92 | 15.68 |
| KKPXDT | Ion (720p) | 121 | 502159536128 | 121.82 | 9.16 |
| KNTVDT | NBC (1080i) | 69 | 242235310080 | 55.15 | 9.76 |
| KOFYDT | Independent (720p) | 21 | 19422007296 | 10.3 | 4.19 |
| KPIXDT | CBS (1080i) | 106 | 694058561536 | 98.38 | 15.68 |
| KQEDDT | PBS (1080i) | 28 | 70307799040 | 21.01 | 7.44 |
| KQEDDT2 | PBS (1080i) | 29 | 103552552960 | 30.30 | 7.60 |
| KRONDT | Independent (720p) | 4 | 18535067648 | 4.06 | 10.13 |
| KTVUDT | FOX (720p) | 69 | 233586585600 | 56.53 | 9.18 |
| KBCWDT2 | Comet (480i SD) | 12 | 15054045184 | 12.34 | 2.71 |
As you can see, which channels your favorite shows are on can have a dramatic impact on how long your SSD will last. If you live in the SF Bay Area and are a big fan of CBS or CW, then you’ll be recording a lot of shows on high bitrate (15 Mbit/s) channels. On the other hand, if you mostly watch PBS and independent shows then your recordings will be in the 7.5 – 10 Mbit/s range. You’ll be able to record 50 – 100% more shows before your SSD reaches the end of its life.
And of course how many hours you record has a great impact. In this setup we recorded, on average, about 50 hours, or 53 shows, per day. This is probably more than the average user
The Live Cache Effect
So far we’ve talked about recordings. Many DVRs also offer a live cache. TiVos in particular are always recording. Even if you haven’t scheduled something to record, the DVR continues to record whatever channel the tuner was last on. This advantage of this continuous recording is that if you happen to turn on the TV and find yourself in the middle of an interesting show, you can rewind back in the cache and watch it from the beginning (or at least closer to the beginning, depending on how big the cache is). The cost of this feature is that the DVR is constantly recording. This isn’t such a big deal when you’re using a mechanical hard drive, but if you’re using an SSD then it will wear much faster.
To get an idea of how this affects longevity, let’s assume we have a four tuner DVR. So there are four live caches continuously recording. That’s 96 hours per day. Now given the workload in our testbed, we were already recording 50 hours per day, so the effect of live TV caching is to effectively halve the expected lifetime (assuming with the live cache we have the same mix of channels used in recording). So with live caching we get the following expected lifetimes:
| Model (capacity) | Endurance Rating (TBW) | Expected Testbed Lifetime |
|---|---|---|
| 128 GB | 100 TB | 33 weeks |
| 256 GB | 200 TB | 66 weeks |
| 512 GB | 400 TB | 132 weeks |
| 1024 GB | 800 TB | 264 weeks |
| 2048 GB | 1600 TB | 528 weeks |
Another, rather conservative, way to look at this, of course, is to assume that all of your channels are high-bitrate channels. This is the worst-case scenario since the DVR is constantly recording with all of its tuners at the highest possible bitrate. With ATSC 1.0 a single channel could utilize the full 19.4 Mbit/s of bandwidth available. The following table shows the expected lifetime if all four tuners were on 19.4 Mbit/s channels.
| Model (capacity) | Endurance Rating (TBW) | Expected Testbed Lifetime |
|---|---|---|
| 128 GB | 100 TB | 17 weeks |
| 256 GB | 200 TB | 34 weeks |
| 512 GB | 400 TB | 68 weeks |
| 1024 GB | 800 TB | 136 weeks |
| 2048 GB | 1600 TB | 272 weeks |
Even the 2048 GB version would last only about 5 years, although considering that the SU800’s warranty only lasts 3 years, this might be considered an acceptable lifespan. (Most consumer SSDs have warranties of five years or less – the SU900, similar to the SU800 except using 3D MLC instead of 3D TLC flash, comes with a 5 year warranty as does Samsung’s 860 EVO Pro.)
At the time of writing you can find the 1 TB SU800 on Amazon for $150, well within the reach of most consumers. That would give a dual-tuner box a 5 year lifespan. The 2 TB SU-800 is available for $340.
Conclusion
The key to choosing an SSD for a DVR is selecting one with an appropriate endurance. Higher capacity SSDs tend to have correspondingly higher endurances, although not all are created equal. For example, the 1 TB SU800 has an endurance rating of 800 TBW. On the other hand the Western Digital WD Blue 1 TB 3D NAND SSD (WDS100T2B0A) is rated at 400 TBW, or half that of the SU800.
In the ideal case, the SSD would allow continuous recording (or live caching) from all tuners in the DVR. The good news is that for two- and four-tuner DVRs affordable SSDs are now available. For a dual-tuner DVR an endurance rating of 800 TBW would be recommended, and for a four-tuner DVR 1600 TBW. These endurances would allow for five years of continuous operation and without any worry about the specific bitrates of the channels being recorded.