Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

wesk702

macrumors 68000
Original poster
Jul 7, 2007
1,809
368
The hood
Wanted to get a scratch drive for audio rec/prod to tether to my nMP. Just wanted to see some cheap but good solutions considering I spend tiso much on my nMP.

Looking for TB or TB2
Fastest speed, to keep audio and probably other file so there to for quick access.
Do not want something where the drive always has to spin up for a few seconds before I access it.
 
Wanted to get a scratch drive for audio rec/prod to tether to my nMP. Just wanted to see some cheap but good solutions considering I spend tiso much on my nMP.

Looking for TB or TB2
Fastest speed, to keep audio and probably other file so there to for quick access.
Do not want something where the drive always has to spin up for a few seconds before I access it.

What capacity? What about something like this?

http://oyendigital.com/hard-drives/store/TNN-SSD-240-SL.html

Or look at a Promise J4 and buy your own SSDs.

Seagate GoFlex Thunderbolt products are another option.
 
I'm thinking about scratch drives (SSD) for a nMP and/or iMac, too.

I notice you want an external SSD. Is it because you will max out your internal storage with OS & apps?

The reason I ask is that I was always lead to believe one should separate scratch from OS/apps/data. With the speeds of the internal PCIe SSD being so incredibly fast, might we be at a time where it makes some sense to use the internal storage for scratch as well?

Accessing the OS/apps at the same time as scratch may no longer be a bottleneck as it once was with spinning disks. Just a guess.

I always want to keep data separate, but I'm currently debating external SSD or larger internal storage for scratch.

Thanks.
 
I'm thinking about scratch drives (SSD) for a nMP and/or iMac, too.

I notice you want an external SSD. Is it because you will max out your internal storage with OS & apps?

The reason I ask is that I was always lead to believe one should separate scratch from OS/apps/data. With the speeds of the internal PCIe SSD being so incredibly fast, might we be at a time where it makes some sense to use the internal storage for scratch as well?

Accessing the OS/apps at the same time as scratch may no longer be a bottleneck as it once was with spinning disks. Just a guess.

I always want to keep data separate, but I'm currently debating external SSD or larger internal storage for scratch.

Thanks.

This is a good point. A lot of the old school thinking about scratch drives being separate is now obsolete with SSDs.
 
This is a good point. A lot of the old school thinking about scratch drives being separate is now obsolete with SSDs.

I'm still understanding that using your main drive dual as a scratch isn't optimal. Degrades more overtime aside from your everyday usage.

Also looking for 1-2TB scratches
 
I'm still understanding that using your main drive dual as a scratch isn't optimal. Degrades more overtime aside from your everyday usage.

Also looking for 1-2TB scratches

Is the degradation issue more a theoretical (for most users) than practical worry? I fully agree that more write cycles on any SSD will wear it down faster, but with modern drives, TRIM, and provisioned free space, what I see is that most SSDs will far outlive the useful life of the computers that they're in. If we're talking an expected 10-, 15- year lifespan of the drives this may be more of an issue.

I know the above is more of a statement that I am making but I mean it as more of a question as to whether what I've read is true.

On another, related note, I've been trying to figure this out but have been unsuccessful regarding bottlenecks and TB enclosures.

To use a specific example, let's say one chooses to run one Sonnet Tempo Pro SSD card with 2 drives configured as separate drives in a TB PCIe enclosure. For the sake of this thread, one is data and the other is scratch.

Sonnet quotes read & write of 450 & 325 MB/s for 1 drive in a TB enclosure, and 700/560 for those 2 drives in a RAID0 configuration. Makes sense. Should be less than the bandwidth for TB.

If one has data AND scratch to write at the same time, will one see 2 equal streams @ 325 or would it be a combined 560 (280 per stream)?

Would the scenario change if one had 4 single SSDs in that enclosure? 4x325 = 1.3GB/s ... would seem to exceed the maximum of TB1.

A 4-drive RAID on Tempo Pro cards inside a Mac Pro is capable of 1710/1320 (according to Sonnet), so the cards are not the bottleneck, but they would slow down in a TB enclosure.

Kind of just wondering if the slowdown that one would experience is different for a multiple-drive RAID is linear if data is being written to all drives at once. I'm guessing there could be a bit of extra overhead if writing to multiple single drives.

Probably a non-issue but perhaps relevant if one is doing something like a 3- or 4-drive RAID AND a scratch drive in a single enclosure -- or on the same TB channel.
 
This is a good point. A lot of the old school thinking about scratch drives being separate is now obsolete with SSDs.

In terms of trying to remove concurrent data access to the same drive ( pragmatically being high random access) then yes. In terms of throughput a single SSD dealing with 3-9 concurrent streams to the same device will still outperform 2-3 of most HDDs.

In terms of segregating wear-and-tear that hasn't changed. SSDs wear out over time just like HDDs do. If constantly going to be beating on a SSD with scratch work it makes more sense to separate that from OS , App, and 'normal' file access/churn.

Throwing 3-4 radically different wear patterns at a SSD probably doesn't help it long run.
 
I'm still understanding that using your main drive dual as a scratch isn't optimal. Degrades more overtime aside from your everyday usage.

TRIM (which Apple uses on it's built-in SSDs) will ensure there's no degradation.

And any concerns about limiting the lifespan of an SSD are a complete myth.

Here's a stress test review of a couple of Samsung SSDs.

The outcome:

If we take the 764 TiB and an average of 10 GiB of writes per day, we arrive at a lifespan of 214 years.

:eek: :D


Is the degradation issue more a theoretical (for most users) than practical worry? I fully agree that more write cycles on any SSD will wear it down faster, but with modern drives, TRIM, and provisioned free space, what I see is that most SSDs will far outlive the useful life of the computers that they're in.

Word. ;)

----------

In terms of trying to remove concurrent data access to the same drive ( pragmatically being high random access) then yes. In terms of throughput a single SSD dealing with 3-9 concurrent streams to the same device will still outperform 2-3 of most HDDs.

In terms of segregating wear-and-tear that hasn't changed. SSDs wear out over time just like HDDs do. If constantly going to be beating on a SSD with scratch work it makes more sense to separate that from OS , App, and 'normal' file access/churn.

Throwing 3-4 radically different wear patterns at a SSD probably doesn't help it long run.

Yeah... In a workstation, it's extremely unlikely for a user to exceed a queue depth beyond 6 (90% of the time it's QD=1). And with the IOPS of modern SSDs, they scale nicely with QD. So there's no reason to separate scratch from OS/Apps... the QD's simply won't exceed the drives ability to respond.
 
TRIM (which Apple uses on it's built-in SSDs) will ensure there's no degradation.

thanks for posting that. bummer…as i'd like to have my SSDs last two hundred fifteen years. i'm right on that cusp! ;-)

seriously, though, inability to enable TRIM via USB3 is a bit of a deal-breaker for me and may help some to justify the TB premium.
 
thanks for posting that. bummer…as i'd like to have my SSDs last two hundred fifteen years. i'm right on that cusp! ;-)

seriously, though, inability to enable TRIM via USB3 is a bit of a deal-breaker for me and may help some to justify the TB premium.

Good point, I wonder if TRIM will work over TB with enclosures like the R4.
 
Good point, I wonder if TRIM will work over TB with enclosures like the R4.

my searches suggest that if SATA/SAS drives are connected via thunderbolt, then TRIM can be enabled (presumably via TRIM Enabler, not automatically).

from what i see, USB3 SSDs canNOT have TRIM enabled.

i'd suspect it works for enclosures.

some say TRIM is less relevant with controllers on modern SSDs; i am less certain about that and would prefer to have it enabled if possible, particularly for a drive that may see heavy write/erase cycles.
 
my searches suggest that if SATA/SAS drives are connected via thunderbolt, then TRIM can be enabled (presumably via TRIM Enabler, not automatically).

from what i see, USB3 SSDs canNOT have TRIM enabled.

i'd suspect it works for enclosures.

some say TRIM is less relevant with controllers on modern SSDs; i am less certain about that and would prefer to have it enabled if possible, particularly for a drive that may see heavy write/erase cycles.

Yeah, I agree it's not necessary. I have a trio of SSDs in RAID0 on a PCIe controller (that 2720 we've been chatting about) and of course in RAID0 you can't have TRIM no matter what... and those drives are still performing very similarly to new after a year (albeit with relatively light usage).

The fact that the nMP comes with a large (as you need) and fast SSD without needing to resort to RAID0 for that size/speed is another benefit... you can run TRIM on it to ensure it's performing optimally at all times unlike any RAID0 array of SSDs. :)
 
..and of course in RAID0 you can't have TRIM no matter what... and those drives are still performing very similarly to new after a year (albeit with relatively light usage).

this wasn't an 'of course' for me. didn't know that. i didn't really think about it but assumed TRIM was enabled on a drive-by-drive basis before setting up the RAID and the RAID would inherit it. interesting.

for single SSDs, USB3 may be more viable, esp for scratch. wonder which (TB or USB3) has more latency. that could be the issue.

i'd assume the internal PCIe has the least latency (=most relevant for frequent, small writes?).

The fact that the nMP comes with a large (as you need) and fast SSD without needing to resort to RAID0 for that size/speed is another benefit...

do we know this for sure? i ask simply because devices like the OWC accelsior -- i have assumed -- are basically 2 sets of flash run in a RAID0 configuration. i have one here, unopened, as i was thinking of going that route, but i don't want to test.

perhaps if the OS sees any drive as a single drive, then it should be TRIM-enable-able, even if they've done something crafty to speed things up behind the scenes?
 
Is the degradation issue more a theoretical (for most users) than practical worry? I fully agree that more write cycles on any SSD will wear it down faster, but with modern drives, TRIM, and provisioned free space, what I see is that most SSDs will far outlive the useful life of the computers that they're in. If we're talking an expected 10-, 15- year lifespan of the drives this may be more of an issue.

I know the above is more of a statement that I am making but I mean it as more of a question as to whether what I've read is true.

As the Flash vendors go to higher density (smaller 'cells' ) Flash several of the techniques about are merely contributing to treading water. The smaller cells wear out faster. So part of the overprovision is for the cells they expect to blow out over normal usage. TRIM isn't panacea that most folks make it out to be. There is still going to be write amplification; it is just can be smaller with TRIM enabled.


Scratch of 1GB per day is no big deal (SSDs are not fragile). 10-30GB per day is borderline. 100GB per day would definitely be an issue.

In the context of a Mac Pro and 16-64GB RAM sizes is that it is not very likely scratch falls into the first group above. Scratch is substantially smaller than RAM which begs question why the app just doesn't use RAM. As the scratch usage meets and exceeds the RAM capacity folks are more likely to fall into the larger ranges above. The reason why stuff isn't being held in RAM is because it is quite large. That gets into abnormal wear patterns that normal SSDs aren't designed against.

A 4-drive RAID on Tempo Pro cards inside a Mac Pro is capable of 1710/1320 (according to Sonnet), so the cards are not the bottleneck, but they would slow down in a TB enclosure.

TB 2 is in the same ballpark.

"... So far I’ve been able to sustain 1.38GB/s of transfers (11Gbps) over Thunderbolt 2 on the Mac Pro. Due to ... "
http://anandtech.com/show/7603/mac-pro-review-late-2013/13

That is a single controller. If match two TB v2 enclosures to two Tempo cards it is possible to equal that with some deliberate usage of two TB buses/controllers.
( the two x4 slots on the older Mac Pro are switched so there is only x4 PCI-e v2 bandwidth even if using two Tempo cards. )



Kind of just wondering if the slowdown that one would experience is different for a multiple-drive RAID is linear if data is being written to all drives at once. I'm guessing there could be a bit of extra overhead if writing to multiple single drives.

Depends upon how smart the drive controller is. Typically the more capable ones can juggle the command queue so that there is quite low "overhead". If the Mac Pro CPU is being used by a simple software driver then there is more.


Probably a non-issue but perhaps relevant if one is doing something like a 3- or 4-drive RAID AND a scratch drive in a single enclosure -- or on the same TB channel.

RAID of HDDs it isn't an issue for the 3-6 drive range. RAID of SSD is kind of questionable as it may not really be speed that is driving the striping but an issue of capacity. If need 2TB of SSD scratch space it really is the issue that 2TB SSDs aren't available (and/or at affordable pricing ) far more so than speed.
 
this wasn't an 'of course' for me. didn't know that. i didn't really think about it but assumed TRIM was enabled on a drive-by-drive basis before setting up the RAID and the RAID would inherit it. interesting.

Yeah, ATA commands are not passed to drives in a RAID array. I know Intel was working on something around this in their Windows AHCI drivers, but I wouldn't expect to see this on OS X. I haven't been keeping up on where this is at.

for single SSDs, USB3 may be more viable, esp for scratch. wonder which (TB or USB3) has more latency. that could be the issue.

i'd assume the internal PCIe has the least latency (=most relevant for frequent, small writes?).

Scratch is likely to benefit most from good small block random I/O performance and low latency as you say.

Personally, I wouldn't use USB3 for that. I would only use USB3 for archives and backups or maybe a media library... occasional use storage. Anything on my workflow would need to be built-in SSD or Thunderbolt connected.

do we know this for sure? i ask simply because devices like the OWC accelsior -- i have assumed -- are basically 2 sets of flash run in a RAID0 configuration. i have one here, unopened, as i was thinking of going that route, but i don't want to test.

perhaps if the OS sees any drive as a single drive, then it should be TRIM-enable-able, even if they've done something crafty to speed things up behind the scenes?

The Accelsior is indeed a RAID0 array of two SSD blades... ScottishCaptain did some benchmarking of it and it doesn't have great small block random I/O performance... he preferred the Sonnet for this kind of I/O... search for his threads on it for more insights.
 
thanks for your insights.

TB 2 is in the same ballpark.

"... So far I’ve been able to sustain 1.38GB/s of transfers (11Gbps) over Thunderbolt 2 on the Mac Pro. Due to ... "
http://anandtech.com/show/7603/mac-pro-review-late-2013/13

That is a single controller. If match two TB v2 enclosures to two Tempo cards it is possible to equal that with some deliberate usage of two TB buses/controllers.
( the two x4 slots on the older Mac Pro are switched so there is only x4 PCI-e v2 bandwidth even if using two Tempo cards. )

did anandtech do that with a 4xSSD RAID0?

point taken. i guess in the case of a TB2 enclosure that allows multiple PCIe slots (2-3) and one could have multiple drives per slot, once one bumps up into the TB2 bandwidth (sounds like 1.38GB/s), then adding any cards or drives to that enclosure (whether or not they are in the RAID) is a bad idea.




thank you!
 
did anandtech do that with a 4xSSD RAID0?

Yes. It probably leaves some SSD bandwidth "on the table", but it is fast enough for a huge spectrum of folks.

Some specific external enclosure that just took x4 PCI-e M.2(NGFF) or sataExpress drive(s) could probably max out with just one drive that just avoids legacy SATA altogether.




i guess in the case of a TB2 enclosure that allows multiple PCIe slots (2-3) and one could have multiple drives per slot, once one bumps up into the TB2 bandwidth (sounds like 1.38GB/s), then adding any cards or drives to that enclosure (whether or not they are in the RAID) is a bad idea.

Depends upon what kind of PCI-e SSDs it takes. The drives in the MBP are a variant on the x2 PCI-e M.2(NGFF) designs. Four of those probably wouldn't throttle too badly. But the x4 PCI-e SSDs only really going to need one very good one.
 
Depends upon what kind of PCI-e SSDs it takes. The drives in the MBP are a variant on the x2 PCI-e M.2(NGFF) designs. Four of those probably wouldn't throttle too badly. But the x4 PCI-e SSDs only really going to need one very good one.

i appreciate the information.

if one is saturating the connection, would it matter what type of drives are being used?

it does seem that there is a point where one can only add so much to one TB(2) enclosure…or one TB(2) controller.

thanks much. i've learned a bunch here.
 
cool…sounds like they're bridging 2 TB1 ports, then?

No. More like they have a SATA III ( 6Gb/s) controller in there. 6Gb/s => 750 MB/s. 800MB in 1.3 secs is 616 MB/s. Using to SATA III connections to get a sustained 600+ MB/s rate two the devices.

The SSDs are probably more affordable because the aren't ultra bleeding edge which gives them a better price point (after paying to wrap TB infrastructure around them. )

The "good news" is more so the number of vendors offering a solution in this space is going up. At some point someone is going to jump in at a lower price point to get volume. That's the problem in the JBOD (no RAID just disk bays/sleds) space for the moment. Too few vendors and all of the options are bit high or have RAID also ( which increases costs ).
 
Third party ram never has TRIM enabled already correct?

Gotta get me some TRIM

----------

Pegasus J2 256GB.

Would love me some PROMISE gear, but so expensive. They all in the same ballpark? In search of 256-500gb SSD, with TB1 minimum for cheap as possible.
 
No. More like they have a SATA III ( 6Gb/s) controller in there. 6Gb/s => 750 MB/s. 800MB in 1.3 secs is 616 MB/s. Using to SATA III connections to get a sustained 600+ MB/s rate two the devices.

well, if so the writing is poor. they speak of 2 SATAIII drives. there is no mention that i see of *two* SATAIII connections. they do say the TWO thunderbolt ports are used together.

"Pry open the company's new DriveStation Mini Thunderbolt SSD and you would find not one, but two 2.5-inch SSDs toting a SATA III 6Gb/s interface tucked away inside. That's alongside two Thunderbolt ports that, when used together, can provide read/write speeds of around 615MB/s and 760MB/s respectively, according to Buffalo."



perhaps i'm missing something, but the description on the page you linked is misleading if what you say is true.

----------

Third party ram never has TRIM enabled already correct?

Gotta get me some TRIM

----------



Would love me some PROMISE gear, but so expensive. They all in the same ballpark? In search of 256-500gb SSD, with TB1 minimum for cheap as possible.

any thunderbolt enclosure is going to be pricey. i see several options that allow a user to choose their drives between $500 & $1000, and promise has some models that sit in that range.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.