Slashdot Mirror
New PCIe SSDs Load Games, Apps As Fast As Old SATA Drives
crookedvulture writes Slashdot has covered a bunch of new PCI Express SSDs over the past month, and for good reason. The latest crop offers much higher sequential and random I/O rates than predecessors based on old-school Serial ATA interfaces. They're also compatible with new protocols, like NVM Express, which reduce overhead and improve scaling under demanding loads. As one might expect, these new PCIe drives destroy the competition in targeted benchmarks, hitting top speeds several times faster than even the best SATA SSDs can muster. The thing is, PCIe SSDs don't load games or common application data any faster than current incumbents—or even consumer-grade SSDs from five years ago. That's very different from the initial transition from mechanical to solid-state storage, where load times improved noticeably for just about everything. Servers and workstations can no doubt take advantage of the extra oomph that PCIe SSDs provide, but desktop users may struggle to find scenarios where PCIe SSDs offer palpable performance improvements over even budget-oriented SATA drives.
are they talking about old hard disks or older SSDs?
So for a segment of the market, data throughput is no longer a competitive advantage.
Big, established players sometimes have trouble adapting to that kind of competitive shift; they are used to optimizing on one dimension and their engineers are amazing at it, but the market goes in a different direction.
It sometimes gives newcomers with smaller capital bases and different technologies that would seem silly by high-end standards the ability to disrupt markets.
A PCIe SSD opens up the sole SATA slot for the backup disk in the small form factor PCs that are currently in vogue.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Most folks who need the throughput of a PCI-E SSD won't use it for just gaming. These same users are likely power users. Everything from running test VMs locally to Video / Audio editing would see a huge improvement from this tech.
Loading apps? games? That's nice and all, but those are far from the only use cases of fast storage media.
Personally, the new PCI-E SSDs have gotten a good amount of use from me as ZFS cache drives, where they've been wonderful for saturating 10gbps Ethernet.
Different SSD, different target...
What would you expect? Loading games and applications is mostly about reading a large block as data as fast as possible and your CPU processing it. The CPU is the larger limit if not the actual transfer speed. Random IO (where these are much faster) is not that big of an issue for most games.
You're testing worthless *crapps*, not real programs.
Particularly, an X-25M 3gbps SATA drive. Which was pretty fast a few years ago. These are, in practical terms, no faster. I doubt enough data is being moved to see the difference.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
Desktop users won't notice the difference yet but considering the bottleneck of practically all modern systems is the hard drive it's probably best to throw more bandwidth at it rather than less
Since so many games make you sit through crappy videos, copyright screens and other garbage for thirty seconds while they start up, or at least make you hit a key or press a mouse button to skip them and that damn 'Press Any Key To Start' screen that they couldn't even take five minutes to remove when porting from a console, faster load time is pointless once you've eliminated the worst HDD delays.
A guy named Amdahl had something to say on the subject. SSDs excel at IOPS, but that buys you little if you're not IOPS-constrained.
Examples of things that eat operations as fast as you can throw them at 'em: databases, compilation, most server daemons.
Examples of things that couldn't care less: streaming large assets that are decompressed in realtime, like audio or video files. Loading a word processing document. Downloading a game patch. Encoding a DVD. Playing RAM-resident video games.
It should be a shock to roughly no one that buffing an underused part won't make the whole system faster. I couldn't mow my lawn any faster if the push mower had a big block V8, nor would overclocking my laptop make it show movies any faster.
TL;DR non-IO-bound things don't benefit from more IO.
Dewey, what part of this looks like authorities should be involved?
Why use a PCI Express slot when you can use SATA anyway?
Why OpalCalc is the best Windows calc
While I'm sure there are some people who use the current crop of PCIe SSDs to max out databases, builds or whatever, the number of people for whom it makes a real difference is pretty small. For the overwhelming number of people there's just another, different bottleneck they're now hitting or the speed difference isn't noticeable.
It currently seems to be hitting a bit of a benchmark-mania where people run disk benchmarks just for the numbers without any actual improvement in usable performance in most areas.
We've reached the limits of the flash technology which drives both the SATA and PCIe versions of the storage device, at least in terms of how fast the data can be received from the media (the nand flash). This is not surprising. Flash is not all that fast and it quickly becomes the limiting factor on how fast you can read data out of it.
Just moving from SATA to PCIe wasn't going to change the underlying speed of the media. The slowest device in the chain is what rules the overall speed. We've just moved past where the drive interface is the limiting factor.
So the story here really is, that we have reached the limits on the Nand Flash, at least on read performance.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
I don't understand why people still don't understand the difference between latency and bandwidth, and the fact that a huge amount of the desktop IO load is still a few hundred MB/sec. So, the pieces large enough to take advantage of the higher bandwidth is a smaller (and growing smaller) portion of the pie.
Next time you start your favorite game look at the CPU/DISK IO. Its likely the game never gets anywhere close to the max IO performance of your disk, and if it does its only for a short period.
Anyway, its like multicore, beyond a fairly low core count most desktop type operations are better off with faster CPU's rather than more of them.
And just like desktop benchmarks, the guys running benchmarks seem lothe to heavily weigh single thread operations, or queue depth 1 1k IO loads in the overall performance picture even though its a large portion of actual system performance running everyday tasks.
I mean, why would anyone think images would load faster? The cpu is doing enough transformative work processing the image for display that the storage system only has to be able to keep ahead of it... which it can do trivially at 600 MBytes/sec if the data is not otherwise cached.
Did the author think that the OS wouldn't request the data from storage until the program actually asked for it? Of course the OS is doing read-ahead.
And programs aren't going to load much faster either, dynamic linking overhead puts a cap on it and the program is going to be cached in ram indefinitely after the first load anyway.
These PCIe SSDs are useful only in a few special mostly server-oriented cases. That said, it doesn't actually cost any more to have a direct PCIe interface verses a SATA interface so I these things are here to stay. Personally though I prefer the far more portable SATA SSDs.
-Matt
If what is done with the data as it streams to/from disk is the bottleneck, it doesn't matter if it's sitting in RAM for you before you need it, you'll still be bottlenecked.
Of course, if you're waiting for disk I/O then there will be a difference.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
The thing is, PCIe SSDs don't load games or common application data any faster than current incumbents—or even consumer-grade SSDs from five years ago.
The SATA bus gets saturated for sequential reads and writes so of course PCIe SSDs can trump SATA SSDs here. But, generally speaking, the controller silicon on PCIe SSDs is no faster than their SATA counterparts so they offer no improvement for random reads and writes. Still orders of magnitude better than spinning rust, though.
The PCIe devices are faster; but (since they also tend to be either substantially similar to SATA devices; but packaged for the convenience of OEMs who want to go all M.2 on certain designs and clean up the mini-PCIe/SATA-using-mini-PCIe's-pinout-for-some-horrible-reason/mini-SATA/SATA mess that crops up in laptops and very small form factor systems; or tend to be markedly more expensive enterprise oriented devices that focus on IOPS) it isn't clear why you'd expect much improvement on application loading workloads.
SSDs are at their best, and the difference between good and merely adequate SSDs most noticeable, under brutal random I/O loads, the heavier the better. Those are what make mechanical disks entirely obsolete, cheap SSD controllers start to drop the ball, and more expensive ones really shine. Since application makers generally still have to assume that many of their customers are running HDDs(plus the console ports that may only be able to assume an optical disk and a tiny amount of RAM, and the mobile apps that need to work with cheap and mediocre eMMC flash), they would do well to avoid that sort of load.
HDD vs. SSD was a pretty dramatic jump because even the best HDDs absolutely crater if forced to seek(whether by fragmentation or by two or more programs both trying to access the same disk); but there aren't a whole lot of desktop workloads where 'excellent at obnoxiously seeky workloads' vs. 'damned heroic at obnoxiously seeky workloads' makes a terribly noticeable difference. Plus, a lot of desktop workloads still involve fairly small amounts of data, so a decent chunk of RAM is both helpful and economically viable. Part of the appeal of crazy-fast SSDs is that the cost rather less per GB than RAM does, while not being too much worse, which allows you to attack problems large enough that the RAM you really want is either heroically expensive or just not for sale. On the desktop, a fair few programs in common use are still 32 bit, and much less demanding.
I have an Evo 840 for my OS and I put my games on a RAID1 array built from 2, 1TB Western Digital black drives with 64MB of cache. The Windows pagefile and temp directory are on a second RAID1 array with older drives that have 32MB of cache.
I play a lot of Battlefield 4 and I am frequently one of the first players to join the map, even when I am playing on a server with others who have SSD drives.
When I am moving files around my system, I often get ~120MB/s read speed out of the RAID1 array.
While this is obviously not an apples to apples comparison, I am happy to be getting similar performance and more space for considerably less money per gigabyte. I am using the built-in Intel SATA RAID controller.
Read and write speeds have mostly nothing to do with the reason why everything is so snappy since the time SSDs started their life in the market.
IOPs have mostly nothing to do with it either.
Yes, both factors have an influence but it is an incredibly negligible, small impact.
The answer lies in the access times between hard drives and solid state drives. Instead of latency being measured in milliseconds, it is being measured in microseconds. Just 1 microsecond is equal to 0.001 milliseconds. That is three orders of magnitude faster response time. In this case, "faster" really means latency, not how many cars can drive side-by-side simultaneously in a slice of time.
If we had magnetic hard drives that had the same latency, we would be seeing very similar if not identical results that SSDs show.
I would like to see solid state drives with latencies in the nanoseconds -- that would be interesting (for a brief time). 1 nanosecond is also three orders of magnitude faster than a microsecond.
"New PCIe SSDs Load Games, Apps As Fast As Old SATA Drives"
So I'll stick to my cheaper and higher capacity "old SATA" drives thank you..
I wonder if the reason that load times aren't much faster is because the apps are phoning home (at internet speed), checking copy protection and such and because the apps waits for a response, of course faster disk times aren't going to decrease the click-to-play time. Fucking DRM.
That's just it. Their speeds are not "much higher." They're only slightly faster. The speed increase is mostly an illusion created by measuring these things in MB/s. Our perception of disk speed is not MB/s, which is what you'd want to use if you only had x seconds of computing time and wanted to know how many MB of data you could read.
Our perception of disk speed is wait time, or sec/MB. If I have y MB of data I need read, how many seconds will it take? This is the inverse of MB/s. Consequently, the bigger MB/s figures actually represent progressively smaller reductions in wait times. I posted the explanation a few months ago, the same one I post to multiple tech sites. And oddly enough Slashdot was the only site where it was ridiculed.
If you measure these disks in terms of wait time to read 1 GB, and define the change in wait time from a 100 MB/s HDD to a 2 GB/s NVMe SSD as 100%, then:
A 100 MB/s HDD has a 10 sec wait time.
A 250 MB/s SATA2 SSD gives you 63% of the reduction in wait time (6 sec).
A 500 MB/s SATA3 SSD gives you 84% of the reduction in wait time (8 sec).
A 1 GB/s PCIe SSD gives you 95% of the reduction in wait time (9 sec).
The 2 GB/s NVMe SSD gives you 100% of the reduction in wait time (9.5 sec).
Or put another way:
The first 150 MB/s speedup results in a 6 sec reduction in wait time.
The next 250 MB/s speedup results in an extra 2 sec reduction in wait time.
The next 500 MB/s speedup results in an extra 1 sec reduction in wait time.
The next 1000 MB/s speedup results in an extra 0.5 sec reduction in wait time.
Each doubling of MB/s results in half the reduction in wait time of the previous step. Manufacturers love waving around huge MB/s figures, but the bigger those numbers get the less difference it makes in terms of wait times.
(The same problem crops up with car gas mileage. MPG is the inverse of fuel consumption. So those high MPG vehicles like the Prius actually make very little difference despite the impressively large MPG figures. Most of the rest of the world measures fuel economy in liters/100 km for this reason. If we weren't so misguidedly obsessed with achieving high MPG, we'd be correctly attempting to reduce fuel consumption by making changes where it matters the most - by first improving the efficiency of low-MPG vehicles like trucks and SUVs even though this results in tiny improvements in MPG.)
Examples of things that couldn't care less: streaming large assets that are decompressed in realtime, like audio or video files. Loading a word processing document. Downloading a game patch. Encoding a DVD. Playing RAM-resident video games.
Yes, any one of those things. However, if you're downloading a game patch while playing a game and maybe playing some music in the background, at the same time as perhaps download a few torrents or copying files, whatever... SSD's kick ass.
Why? Because singularly those things aren't IO-bound, but once you start doing 2+ things that require semi-hefty disk access then on an HDD you're going to have a lot of thrashing and speed goes out the window.
Can anyone explain to me why a seek time of 50 microseconds, 200,000+ IOPS read speed, and 1.5GB/s + throughput can't load game files faster and why that's specific to PCI-E SSDs only? That sounds completely ridiculous.
While my interaction with storage is "how long did it take for this operation to finish" the answer to that can vary dramatically on a hard disk depending on type and frequency of I/O I was doing (whereas the difference between best and worst values narrows with flash).
Your table doesn't capture the difference in wait time between reading only reading a 1GByte ISO in big chunks that's been laid out sequentially and serving up multiple torrents from big files that are over different parts of the disk simultaneously. You aren't always in the worst case and if the data is already cached in RAM you may be totally unable to perceive a difference because the waiting was decoupled from the request.
Telling people that "wait time" describes what they're seeing feels like it's trying to push latency and throughput into one number when both need to be distributions describing particular patterns of (potentially parallel) I/O and that's not even getting into queue depth. I guess there are parallels to telling people to describe things in terms of load average too...
In SSD tests I'd like them to try RAGE.
This game may have been criticized for various good reasons, however, the engine is a bit unusual in a sense that the textures are huge and continuously streamed from the disk. Disk performance made a big difference in gameplay, not just in loading times.
NOTE: I'm speaking for myself here, and not for my company, but I have been working full time in the games industry for 23 years.
Most games use pack-files (sometimes called packages) that are large binary blobs on disk that are loaded contiguously in a seek-free manner. Additionally, these blobs may have ZIP or other compression applied to them (often in an incremental chunked way). The CPU's can only process the serialization of assets (loading) at a certain speed due to things like allocation of memory from the kernel and graphics drivers (which on secure OS's typically involves remapping and clearing pages). There are additional CPU constraints for the decompression, and for the serialization "linker" phase to associate assets in a package and present them to the game engine.
All this stuff takes time, and in a game with streaming (loading while game-play is going on), there are a limited number of CPU cycles as well as memory bandwidth to process the serialization after running the game engine.
These processing constraints impose a limit on the speed at which data can be loaded and consumed by the engine. And in many game engines on a typically powered PC, that number may be anywhere from 50-200MB/s but probably averaging closer to 100-150MB/s. Since this is in the linear contiguous read speed of many hard drives, as long as the package file is not fragmented on the disk, using an SSD will result in minimal speedup during this type of loading process.
In their methodology they don't mention anything about clearing the RAM on the machine. Modern OS's have gotten pretty good at caching, and if you're test methodology consists of loading the same program a few times and averaging the result, chances are you're mostly measuring RAM retrieval speeds. No surprise that the results are mostly the same. Interesting to note that your DO see a difference on initial boot times.
PCIE SSD, SATA SSD, SATA drives ok why are we referencing the sata ssds in 2 ways. It makes it seem like they are claiming no increase over old sata drives (spinning rust) and not sata ssds.
No SSD is faster than CPU, GPU, or RAM. Period.
However...
Where before the bottleneck was the physical disk spinning platters, this is no longer the case. Now it is more about the interconnects, in not only how the various pieces are brought together, but also the logical method. So you have hardware that not only have physical interconnect limitations, but also things like timings, parallelism, order, priority and all the things that determine which bits go through a pipe and which wait their turn.
The good news, is that before people didn't much worry about say ATA etc... because it didn't really matter as whatever speed it could manage would be much more than that of the capacity of the HD anyway. Now with the advent of SSD, people are starting to look at how to get the data where it needs to go faster, which using the PCI is an example of (or at least of alternatives). In this case, it has been shown that it isn't really a solution (at least yet). However now that people have the focus on that, I expect some developments to be made in the coming years. The difficult part has always been the inerconnectness of these things in that you have to coordinate your logic of how data moves between various components.
Anyway I took a course on it a long time ago, which only dealt with very simplistic examples, but even those were pretty confusing to me other than to get the basic gist of it.
The way I look at it, is now the narrow pipe between things is the bottleneck, however simply making a wider pipe will not solve your problem, you have to look at how data is fundamentally ordered to go through that pipe for best results.
Anonymous Coward was asking if the "old SATA drives" referred to old SSD drives that use SATA (which wouldn't be too surprising if it were almost as fast), or old rotating hard disks that use SATA (which would be really surprising to find it faster than SSD.) Google results for the X25-m say yes, it's an SSD, just a bit older one that uses SATA instead of PCIe.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks