Slashdot Mirror
With HDDs On The Ropes, Samsung Predicts SSD Price Collisions As NVMe Takes Over (tomshardware.com)
At its Global SSD Summit, Samsung shared its vision of the current state of SSD market and also outlined the future trends. The company noted that SSDs are steadily displacing HDDs in more applications, but NVMe is shaping up to be the dark horse that may put the venerable HDD to rest. From an article on Tom's Hardware: Samsung loves Google, and not just because it probably buys plenty of its SSDs. Samsung outlined its rather intense focus on Google Analytics for marketing purposes last year, and this year it pointed out that recent Google searches for "SSD upgrades" outweighed searches for "CPU upgrades." The historical trend indicates that this wasn't always the case (of course), but with 40 million searches for SSD upgrades this year, it is clear that SSDs are on the move. Performance stagnation in the CPU market is probably to blame here, as well, and we routinely advise readers to spend their hard-earned dollars on GPU and SSD upgrades before the CPU. The cellphone industry has long served as the prime example of an explosive growth market; it grew 19.1% in the last five years alone. SSDs, by contrast, grew 54%, and the steady downward pricing slope is a key factor. The all-important price-per-GB fell from $1.17 in 2012 to a mere $0.36 in 2016 (69% reduction). This is an average value, you can find SSDs for even less on the retail market. The SSD market grew 6x (to 130,000,000) from 2012 to 2016. Samsung's NAND shipments benefit from both the smartphone and SSD industries, and the company presented a chart that highlighted the changing NAND shipment mix. A higher percentage of flash heads into the SSD and Mobile segments every year as the percentage of UFD (USB Flash Drive), cards, and "others" decline.
can they explode like Samsung washing machines and phones? /me ducks
Since the summary says nothing about NVMe, here's a Wikipedia link
after the floods of 2011 in Thailand, the HDD market raised prices, consolidated companies to fix prices higher, and has been milking them ever since. Some HDD prices per GB today are almost as low as they were before the rains in 2011...
While SSDs have proven to fail less than HDDs, they have proven more susceptible to data corruption, and the worst part is, you have no idea. And the only remedy appears to be FS like ZFS, which unfortunately decimates performance.
We asked Samsung why desktop PC penetration is so low
All the big PC vendors see SSD as a huge markup and thus don't sell anywhere near what they could if they priced more reasonably. Instead of the upgrade to SSD being the retail price of the SSD minus the OEM cost of the HDD, the upgrade option is usually a good margin way over the retail cost of an SSD and never mind the cost of the HDD they would replace it with.
Steve, you must be buying Junk SSD's. I have used Intel and Samsung with 0 failures for years. If you want something to read about SSD's you should read this:
http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead
Wake me up when a SSD doesn't cost 10 times as much as a HDD for the same capacity.
Really, common users see a unit that costs 70$ (seagate 2TB 7200RPM) versus one that costs 550$ or more (crucial 2TB SSD, samsung's is 10x the listed HDD price) and they will gladly save their money.
I bought a crucial 500GB 2 years ago for little over 220$, and today the same drive is about 120$. So they are going down, but as more people adopt SSD, the HDD's price will go down as well.
Open Source Java Web Forum with LDAP authentication
While the overclocking and impecunious-PC-performance-chasing of my misspent youth makes me sad that this is the case; the "CPU upgrade = buy new computer" mentality isn't really all that irrational.
With laptops; it is effectively mandatory. Even in laptops with socketed CPUs, unless you went out of your way to buy the absolute worst version of a laptop with fairly high end options, you'll find that the fastest socket and TDP compatible CPU upgrade just isn't all that much faster. Plus, if it's a reasonably new laptop, buying the CPU that is a worthwhile upgrade will be pretty expensive; and if it is an old one it'll be cheap; but leave you with a laptop that is showing its age in both specs and wear and tear.
With desktops; you are also likely to have limited socket-compatible upgrade options, so getting a meaningful CPU boost often means swapping the motherboard as well(unless you started with the lousiest option for a given socket, in which case there might be meaningful improvements to be had); and if you hit the DDR2 to DDR3 or the DDR3 to DDR4 transition you'll need new RAM as well. PSU can probably be reused, unless it is particularly grim; and expansion cards, HDDs, optical drives, and case can be reused; but bumping the CPU speed in any serious way tends to mean ripping out most of the expensive parts(unless your GPU is fancy enough to count as the really expensive part of the system).
An SSD, by contrast, is an easy swap except on laptops that really hate you; and even on ancient systems limited to 1.5Gb/s SATA, the improvement in latency and IOPs over a mechanical drive is pretty dramatic; plus compatibility is almost universal unless your system is so old that you still have PATA; or you want to boot from an NVMe device.
No he made a typo. If he just bought an NVMe drive expect it to be at least 2000MB/s if not higher. The whole purpose of going to NVMe was because SATA became a major bottleneck.
At some point these things could conceivably reach speeds comparable to RAM. If you think of RAM as mostly a mechanism to hide the latency of the disk then, in the not so distant future, it could become redundant (and even a performance bottleneck). It should be interesting to see what kind of software and hardware paradigms come out of that.
Yes, but that is what the XPoint technology is trying to address. The NVMe technology is not designed to operate like ram and the latencies are still very high. Nominal NVMe latency for a random access is 15-30uS. The performance (1.5-3.0 GBytes/sec for normal and 5 GBytes/sec+ for high-end NVMe devices, reading) comes from the multi-queue design allowing many requests to be queued at the same time.
Very few workloads would be able to attain the required request concurrency to actually max-out a NVMe device. You have to have something like 64-128 random requests outstanding to max-out the bandwidth (fewer for sequential). Server-side services have no problem doing this, but very few consumer apps can take full advantage of it.
The NVMe design is thus more akin to being a fast storage controller and should not be considered similar to a dynamic ram controller in terms of performance capability.
Because of the request concurrency required to actually attain the high read capability of a NVMe device, people shouldn't throw away their SATA SSDs just yet. Most SATA SSDs will actually have higher write bandwidth than low-end NVMe devices (particularly small form factor NVMe devices). And for a lot of (particularly consumer) workloads, the NVMe SSD will not be a whole lot faster.
That said, I really love NVMe, particularly when configured as swap and/or a swap-based disk cache. And I love it even more as a primary filesystem. It's so fast that I've had to redesign numerous code paths in DragonFlyBSD to be able to take full advantage of it. For example, the buffer cache and VM page queue (pageout demon) code was never designed for a data read rate of 5 GBytes/sec. Think about what 5+ GBytes/sec of new file-backed VM pages being instantiated per second does to normal VM page queue algorithms which normally only keep a few hundred megabytes of completely free pages in PG_FREE. The pageout demon couldn't recycle pages fast enough to keep up!
Its a nice problem to have :-)
-Matt
Unless the project has only one source file, compiling isn't really single-thread bound. Most projects can be built make -j N. When we do bulk builds, that's what we see happening most of the time so with very few exceptions your project builds should be able to make use of many cpu cores at once.
The few exceptions are: (1) The link phase is typically a choke point and serializes to one thread, and (2) Certain source files might be so large relative to the others that everything else finishes and the build is twiddling its thumbs waiting for that one 200,000 line source file to finish compiling before it can move on to the link phase.
One other note - Builds are like 99.9% cpu driven. Storage bandwidth is almost irrelevant because there is almost no I/O involved in doing a build vs the cpu time required. Source files are already likely cached in memory. Temporary files don't last long enough to even have a chance to get written to disk (if not using tmpfs), and object files and executables are tiny relative to available storage bandwidth and asynchronously flushed as well (so nobody has to wait on them to be flushed to disk).
So, for example, when we do a bulk build of all 24000+ applications in ports, we use tmpfs mounts for all temporary files and our disk I/O is almost non-existent throughout the process. The only time we see busy storage is during maximum peak load when the running compiler binaries exceed available ram and the system pages a bit (you have to allow this in order to optimize the non-peak portions of the build to ensure that all system resources are fully utilized throughout the entire 22-hour-long bulk build).
-Matt