All testing was performed with default (disabled cache). Further, cache settings have little effect on NVMe RAIDs on Z170. Additionally, our minimum latencies were 6us *longer* in an array vs. single SSD, so clearly no caching taking place.
Yup, we had a scale error as our Excel-fu was not as strong as we'd hoped when we made the custom format for the axis, and I totally fell for the error. I've updated the article with corrections.
The SSD controller already does a form of this, as it is talking to multiple flash memory dies over multiple channels. RAID is just another layer to get even more performance out of more parallelism (and as we figured out in testing, to considerably drop the latency under load).
1. That is a false claim - Gamenab didn't even cite the correct FPGA model when he made that DRM claim. 2. G-Sync is actually good down to 1 FPS - it adaptively inserts additional redraws in between frames at rates below 30, as to minimize the possibility of judder (incoming frame during an already started panel refresh pass). FreeSync (it its most recently demoed form) reverts back to the VSYNC setting at the low end. Further, you are basing the high end of G-Sync only on the currently released panels. Nothing states the G-Sync FPGA tops out at 144. 3. I use the word 'experience' because it is 'my experience' - I have personally witnessed most currently shipping G-Sync panels as well as the FreeSync demo at this past CES. I have also performed many tests with G-Sync. Source: I have written several articles about this, including the one linked in this post. 5. I believe the reason it is not yet released is because Nvidia wants to be able to correctly cover more of the range (including the low range / what happens when the game engine hitches).
Gamenab stumbled across the leaked driver and tried to use it to spread a bunch of conspiracy theory FUD. I hope most people here can correctly apply Occam's razor as opposed to the alternative, which is that he supposedly designed those changes, those changes going into an internal driver build that was inadvertently leaked and happened to apply to the exact laptop he already owned.
1. The FPGA *was* required for the tech to work on the desktop panels it was installed in. 2. FreeSync (as I've witnessed so far) as well as the most recent adaptive sync can not achieve the same result across as wide of a refresh rate range that G-Sync currently can. 3. Nvidia could 'make it work', but it would not be the same experience as can be had with a G-Sync module, even with an adaptive sync panel (as evidenced by how this adaptive sync panel in this laptop intermittently blanks out at 30 FPS or when a game hitches. 4.... 5. The driver was not a release driver, and was not meant to call the experience it gives 'G-Sync'. It was meant to be internal.
Conclusion - Adaptive sync alone is not the same experience you can currently get with a real G-Sync panel, which is why any possible future G-Sync that does not need a module it's not yet a real thing.
Apple's description of the zeroing format method we used fits the description of what we wanted in terms of resetting the SSD to a clean state
Zeroing is not the same operation as TRIM. TRIM marks a block as unused, and if you read it you'll either get random data, or zeros (probably the later). Zeroing marks it as in-use, and if you read it you'll get zeros. The SSD's wear management algorithm will move the latter around as though it were real data, whereas it knows the former is "empty" so it won't bother (so the SSD will be faster). In other words, they don't seem to be using a "clean state" at all, which would explain why there's no difference.
Not only that, but writing to all free space of many SSD's will *drop* their IOPS performance since the drive now has to track *all* sectors in the LBA remap table. This is especially true with Intel drives (even the 2nd gen). Additionally, without TRIM, most drives will then continue to track all LBA's as long as used in that same Mac.
Secondly, the SSD in the Macbook Air really isn't very fast at all
A Macbook Air is just about the worst test of SSD performance, as its SATA and other busswork is run in a much reduced power mode, meaning the bottleneck is not the SSD at all. A worst-case degraded SSD in an Air will still be faster than the other bottleneck in that system.
Allyn Malventano, CTNC, USN Storage Editor, PC Perspective
I saw a self-destructed sample of this unit at CES in January. It did not self destruct from an opening attempt, as opening those is quite easy. The drive is enclosed by a simple clear plastic shell (not epoxy filled). The 'destruction' was caused by presumably supplying voltage in excess of the USB spec. You could literally pry the plastic off of the USB drive with the included knife, and it would work just fine (sans enclosure).
Along those lines, Anand suspected the PCB was similar to the new JMicron unit I reviewed recently. This prompted me to add another page to the article detailing the similarities between the drives:
I've got a copy of the fusion-IO faq from early 2008 that reads as follows:
> Will the ioDrive be a bootable device? > This feature will not be included until Q3 2008...Then it was promised for the Duo (and never happened)....Then it was promised for the ioXtreme and even it was released without the ability.
Don't get me wrong, I'm a huge fan of fusionIO, but you can only fool a guy so many times before he gives up hope on a repeatedly promised feature.
> Not really. You're limited to the speed of the individual chips and the number of parallel storage lanes.
There's the thing. Most SSD's are only using the legacy transfer mode of the flash. The newer versions of ONFi support upwards of 200MB/sec transfer rates *per chip*, and modern controllers are using 4, 8, or even 10 (Intel) channels. Once these controllers start actually kicking the flash interface into high gear, there will be no problem pegging SATA or even PCI-e interfaces.
Totally with you on the Colossus not being great on random-IO, that's why we reviewed one!: http://www.pcper.com/article.php?aid=821&type=expert&pid=7 The cause is mainly that RAID chip. It doesn't pass any NCQ, TRIM or other ATA commands onto the drives, so they have no choice but to serve each request in a purely sequential fashion. The end result is even with 4 controllers on board, the random access of a Colossus looks more like that of just a single Vertex SSD.
- We included some early C300 results with the benches. The C300 will read faster (sequentially) under SATA 6Gb/sec, but it is simply not as in most other usage. - Fusion-IO - good luck using that for your OS (not bootable). Fast storage is, for many, useless unless you can boot from it.
The 'compatibility mode' you speak of will be no slower than the same drive being used under a newer OS. All it does is shift the mapping so that a non-aligned XP partition functions in an aligned manner as far as the physical sectors go.
I think you're missing something about IOPS. With a 256K block size, you'd be lucky to crack 1000 IOPS over a SATA 3Gb/sec link. At such a large block size you hit the interface bandwidth limit way before you hit any IOPS limit.
Multithreaded database applications do not hit a drive with sequential 256K block requests. Under load, there will be several of those requests occurring simultaneously. Given the timing, a non-NCQ drive may receive the parallel requests rapidly alternating among multiple 256K streams in differing locations. The now highly random stream will bring non-NCQ drives to their knees, while an X25 will just keep right on cruising at very close to 100 MB/sec.
Slashdot Mirror
You're kidding, right? 60 to 90 is a noticeable jump in smoothness, and many people can distinguish between 90, 120, 144, and even 165 Hz.
All testing was performed with default (disabled cache). Further, cache settings have little effect on NVMe RAIDs on Z170. Additionally, our minimum latencies were 6us *longer* in an array vs. single SSD, so clearly no caching taking place.
PC Perspective's new testing demonstrates the triple RAID-0 array having just 1/6th of the latency of a single drive.
That was with a queue depth of 16. Not exactly representative of a normal desktop user.
It's reasonable for peak power user load. Folks running / considering triple SSD RAIDs are not exactly 'typical desktop users' :)
Yup, it's been corrected. Should have been 6 micro (u) sec.
Yup, we had a scale error as our Excel-fu was not as strong as we'd hoped when we made the custom format for the axis, and I totally fell for the error. I've updated the article with corrections.
That's pretty much it. The trick was showing it properly, which has not previously been possible without our new test method.
Allyn Malventano
Storage Editor, PC Perspective
The SSD controller already does a form of this, as it is talking to multiple flash memory dies over multiple channels. RAID is just another layer to get even more performance out of more parallelism (and as we figured out in testing, to considerably drop the latency under load).
Allyn Malventano
Storage Editor, PC Perspective
1. That is a false claim - Gamenab didn't even cite the correct FPGA model when he made that DRM claim.
2. G-Sync is actually good down to 1 FPS - it adaptively inserts additional redraws in between frames at rates below 30, as to minimize the possibility of judder (incoming frame during an already started panel refresh pass). FreeSync (it its most recently demoed form) reverts back to the VSYNC setting at the low end. Further, you are basing the high end of G-Sync only on the currently released panels. Nothing states the G-Sync FPGA tops out at 144.
3. I use the word 'experience' because it is 'my experience' - I have personally witnessed most currently shipping G-Sync panels as well as the FreeSync demo at this past CES. I have also performed many tests with G-Sync. Source: I have written several articles about this, including the one linked in this post.
5. I believe the reason it is not yet released is because Nvidia wants to be able to correctly cover more of the range (including the low range / what happens when the game engine hitches).
Gamenab stumbled across the leaked driver and tried to use it to spread a bunch of conspiracy theory FUD. I hope most people here can correctly apply Occam's razor as opposed to the alternative, which is that he supposedly designed those changes, those changes going into an internal driver build that was inadvertently leaked and happened to apply to the exact laptop he already owned.
ExtremeTech picked apart his BS in more detail: http://www.extremetech.com/ext...
1. The FPGA *was* required for the tech to work on the desktop panels it was installed in. ...
2. FreeSync (as I've witnessed so far) as well as the most recent adaptive sync can not achieve the same result across as wide of a refresh rate range that G-Sync currently can.
3. Nvidia could 'make it work', but it would not be the same experience as can be had with a G-Sync module, even with an adaptive sync panel (as evidenced by how this adaptive sync panel in this laptop intermittently blanks out at 30 FPS or when a game hitches.
4.
5. The driver was not a release driver, and was not meant to call the experience it gives 'G-Sync'. It was meant to be internal.
Conclusion - Adaptive sync alone is not the same experience you can currently get with a real G-Sync panel, which is why any possible future G-Sync that does not need a module it's not yet a real thing.
Care to tell us how you know that? Better yet, care to cite it?
Third pic down: http://www.ev1.org/
*EVERY* SSD is a 'specialized RAID package'.
Allyn Malventano, CTNC, USN
Storage Editor, PC Perspective
I've been using one of these for over a year. Handy for having your OS on a 4x SSD RAID. Uses only one 5.25" bay:
http://www.newegg.com/Product/Product.aspx?Item=N82E16816710003
Be sure to get the beefier model (with the fans) if you want to use 4x VRaptors.
Allyn Malventano
Storage Editor, PC Perspective
Apple's description of the zeroing format method we used fits the description of what we wanted in terms of resetting the SSD to a clean state
Zeroing is not the same operation as TRIM. TRIM marks a block as unused, and if you read it you'll either get random data, or zeros (probably the later). Zeroing marks it as in-use, and if you read it you'll get zeros. The SSD's wear management algorithm will move the latter around as though it were real data, whereas it knows the former is "empty" so it won't bother (so the SSD will be faster). In other words, they don't seem to be using a "clean state" at all, which would explain why there's no difference.
Not only that, but writing to all free space of many SSD's will *drop* their IOPS performance since the drive now has to track *all* sectors in the LBA remap table. This is especially true with Intel drives (even the 2nd gen). Additionally, without TRIM, most drives will then continue to track all LBA's as long as used in that same Mac.
Secondly, the SSD in the Macbook Air really isn't very fast at all
A Macbook Air is just about the worst test of SSD performance, as its SATA and other busswork is run in a much reduced power mode, meaning the bottleneck is not the SSD at all. A worst-case degraded SSD in an Air will still be faster than the other bottleneck in that system.
Allyn Malventano, CTNC, USN
Storage Editor, PC Perspective
They make them without the blade:
http://www.swissarmy.com/multitools/Pages/Category.aspx?category=presentation+pro&
Allyn Malventano
Storage Editor, PC Perspective
I saw a self-destructed sample of this unit at CES in January. It did not self destruct from an opening attempt, as opening those is quite easy. The drive is enclosed by a simple clear plastic shell (not epoxy filled). The 'destruction' was caused by presumably supplying voltage in excess of the USB spec. You could literally pry the plastic off of the USB drive with the included knife, and it would work just fine (sans enclosure).
Also, it would be nice if PCWorld at would at least get the name of these things correct:
http://www.swissarmy.com/multitools/Pages/Category.aspx?category=presentation+pro&
Perhaps the USB-only part is dubbed 'Secure', but you won't ask for that name when you want to buy one.
Allyn Malventano
Storage Editor, PC Perspective
Along those lines, Anand suspected the PCB was similar to the new JMicron unit I reviewed recently. This prompted me to add another page to the article detailing the similarities between the drives:
http://www.pcper.com/article.php?aid=878&type=expert&pid=11
Regards,
Allyn Malventano
Storage Editor, PC Perspective
I've got a copy of the fusion-IO faq from early 2008 that reads as follows:
> Will the ioDrive be a bootable device? ...Then it was promised for the Duo (and never happened). ...Then it was promised for the ioXtreme and even it was released without the ability.
> This feature will not be included until Q3 2008
Don't get me wrong, I'm a huge fan of fusionIO, but you can only fool a guy so many times before he gives up hope on a repeatedly promised feature.
Allyn Malventano
Storage Editor, PC Perspective
> Not really. You're limited to the speed of the individual chips and the number of parallel storage lanes.
There's the thing. Most SSD's are only using the legacy transfer mode of the flash. The newer versions of ONFi support upwards of 200MB/sec transfer rates *per chip*, and modern controllers are using 4, 8, or even 10 (Intel) channels. Once these controllers start actually kicking the flash interface into high gear, there will be no problem pegging SATA or even PCI-e interfaces.
Allyn Malventano
Storage Editor, PC Perspective
Matt,
Totally with you on the Colossus not being great on random-IO, that's why we reviewed one!:
http://www.pcper.com/article.php?aid=821&type=expert&pid=7
The cause is mainly that RAID chip. It doesn't pass any NCQ, TRIM or other ATA commands onto the drives, so they have no choice but to serve each request in a purely sequential fashion. The end result is even with 4 controllers on board, the random access of a Colossus looks more like that of just a single Vertex SSD.
Allyn Malventano
Storage Editor, PC Perspective
- We included some early C300 results with the benches. The C300 will read faster (sequentially) under SATA 6Gb/sec, but it is simply not as in most other usage.
- Fusion-IO - good luck using that for your OS (not bootable). Fast storage is, for many, useless unless you can boot from it.
Allyn Malventano
Storage Editor, PC Perspective
Numonyx announced some good advances in PCM a few months back:
http://www.pcper.com/comments.php?nid=7930
Allyn Malventano
Storage Editor, PC Perspective
The 'compatibility mode' you speak of will be no slower than the same drive being used under a newer OS. All it does is shift the mapping so that a non-aligned XP partition functions in an aligned manner as far as the physical sectors go.
http://www.pcper.com/comments.php?nid=8113
Allyn Malventano
Storage Editor, PC Percpective
NSSC = Naval Submarine Support Center
Naval Sea Systems Command = NAVSEA
I think you're missing something about IOPS. With a 256K block size, you'd be lucky to crack 1000 IOPS over a SATA 3Gb/sec link. At such a large block size you hit the interface bandwidth limit way before you hit any IOPS limit.
Multithreaded database applications do not hit a drive with sequential 256K block requests. Under load, there will be several of those requests occurring simultaneously. Given the timing, a non-NCQ drive may receive the parallel requests rapidly alternating among multiple 256K streams in differing locations. The now highly random stream will bring non-NCQ drives to their knees, while an X25 will just keep right on cruising at very close to 100 MB/sec.
Allyn Malventano
Storage Editor, PC Perspective