Well, I agree from a pragmatic standpoint it doesn't matter if 950MB/s is all you want. A raided solution may be exactly what you asked for. This topic came up because I mentioned that the new Mac Pro have added something superior to SATA II from a performance standpoint.
The problem with generalizing you standpoint is that the raided solution doesn't scale well at all.
Not quite. We all would love to have 'faster', but what we don't necessarily want is to pay extra for a 'faster' in one part of a system when it isn't tangibly beneficial, because of performance bottlenecks elsewhere within the system that result in no net change.
To this end, since there's no TB media that's capable of exceeding 950+MB/s performance, we have an upper pratical limit on how fast is fast enough .. or more concisely, how fast is worth paying for today (cost as an independent variable).
Sure, within the 3-5 year lifecycle window of a 2013 MP we will want to consider how likely it is for faster TB devices to come about, but considering that the way that we get to 950 today is with a 4 x SSD RAID0, the technology path forward isn't necessarily obvious (or cheap): the capability may become available, but history shows us that it will invariably be at a price only afforded by those who need to be on the bleeding edge.
Again we need to look at how this got brought up into the thread. I'm not saying that the RAID solutions are not capable. But they are limited by the speeds of SATA III, if you want to go beyond the rated 950MB/s you need to add yet another disk.
And TB also goes to "add another disk", implimented through the binding of its controller into a larger logical unit --> and the reason why is because that's where the performance bottleneck is.
FWIW, between these two, we should be acknowledging that there's a big difference between "State of the Art" and "State of the Shelf".
Again, this is quite a different topic. I'm not saying that these solutions aren't fine for what they do, but it would be idiotic for Apple to use such a solution for a new design. It works well and is cost effective in the current Mac Pro, and that's fine.
And at that level I agree. In fact, I've even explicitly suggested 'SSD Blades' as an engineering design consideration in 'Future Mac Pro' discussions from a year or two ago...and I believe that I even suggested stealing them from the existing Apple laptop parts bin. However, even this is merely offering one engineering solution approach to a capability requirement for improving system responsiveness through higher storage I/O bandwidth...and another "skin the cat" engineering approach could have been to provision the MP with an extra 64GB of RAM and having the firmware create a RAM drive and load the entire OS there during boot-up.
I also happen to have this experience. You may claim that the requirements are set to high, that's one thing. But to engineer a solution to meet the requirements is exactly how it's suppose to work.
No, I wasn't talking about requirements that were too high: I was talking about requirements which were inappropriate because they dictated a specific engineering solution and because these inappropriate dictations conflicted. I can't disclose the specific product, so please endulge in this automotive analogy:
VP#1: put in a 3L gas engine .. its the best
VP#2: put in a 5L diesel engine .. its the best
VP#3: put in a 4L V6 engine .. its the best
...(4 thru 6 - ditto)
VP#7: put in a 2L turbo engine .. its the best
Since we can only install one motor, just how do you think we were going to satisfy all seven requirements?
And if you're thinking that this is "stupid" requirements, you're absolutely correct ... and my point is that it still happens anyway.
EDIT: Reading this again, I don't get why you think this is even remotely related. Are you suggesting that Apple's customers somehow proposed the engineering solution for their SSD?[/quote]
No. It is common knowledge that the biggest bang for the buck today is for solid state media ... and even though we know that that's ultimately going to be the engineering solution, that is not our capability requirement.
As the saying goes in the land of Performance Specifications, they could make it out of Bubblegum and if it works, I have no reason to complain.
Where we do get into trouble with requirements generation and vetting is when a savvy customer says "My requirement is no less than 900MB/s because I know you can accomplish this with a PCIe SSD." The reason why this requirement is flawed is because the customer hasn't really analyzed the "why" behind what he says he needs...at best, it is a derivative requirement.
To use another automotive analogy, it would be like a race car driver saying, "You must give me 800HP because I know you can" rather than saying, "I need to turn laps at faster than X in order to win the race". The reason why the latter is the better capability requirement is because one can meet the 800HP requirement without improving lap times (example: heavier engine hurts handling, making the corners slower).
We have already established that SATA III is a bottleneck for storage, many require faster storage, hence why you got yourself the PCIe based solution. Going beyond SATA III, SATA-IO have already specified a new standard built on PCIe.
True, but it doesn't provide any tangible benefit for non solid state spinning media ... ie, HDDs, as they're bottlenecked down at ~200 per interface node. While we can agree that solid state is the future, it is simply still too cost-prohibitive for use cases where a lot of storage capacity is required. Where we currently stand ("State of the Shelf") is that the lower end of the storage capacity capability demand is presently going to solid state, as well as some of the extremely high fringe bleeding edge. The classical "Desktop Power User" is going to be the last to transition, which is a key demographic for the Mac Pro. My personal assessment would be that we're still easily 3+ years out from such a system going to pure solid state, which puts it at the end of the likely useful lifecycle of a 2013 machine.
-hh