The Inland Performance Plus 2TB SSD Review: Phison's E18 NVMe Controller Tested
by Billy Tallis on May 13, 2021 8:00 AM ESTAdvanced Synthetic Tests
Our benchmark suite includes a variety of tests that are less about replicating any real-world IO patterns, and more about exposing the inner workings of a drive with narrowly-focused tests. Many of these tests will show exaggerated differences between drives, and for the most part that should not be taken as a sign that one drive will be drastically faster for real-world usage. These tests are about satisfying curiosity, and are not good measures of overall drive performance. For more details, please see the overview of our 2021 Consumer SSD Benchmark Suite.
Whole-Drive Fill
 |
|||||||||
| Pass 1 | |||||||||
| Pass 2 | |||||||||
The SLC write cache on the 2TB Inland Performance Plus lasts for about 225GB on first pass (about the same cache size as 980 PRO, but a bit faster), and about 55GB on the second pass when the drive is already full. Performance during each phase of filling the drive is quite consistent, with the only significant variability showing up after the drive is 80% full. Sequential write performance during the SLC cache phase is higher than any other drive we've tested to date.
 |
|||||||||
| Average Throughput for last 16 GB | Overall Average Throughput | ||||||||
The post-cache performance is a bit slower than the fastest TLC drives, but overall average throughput is comparable to other top TLC drives. The Inland Performance Plus is still significantly slower than the MLC and Optane drives that didn't need a caching layer, but one or two more generational improvements in NAND performance may be enough to overcome that difference.
Working Set Size
 |
|||||||||
As expected from a high-end drive with a full-sized DRAM buffer, the random read latency from the Inland Performance Plus is nearly constant regardless of the working set size. There's a slight drop in performance when random reads are covering the entire range of the drive, but it's smaller than the drop we see from drives that skimp on DRAM.
Performance vs Block Size
 |
|||||||||
| Random Read | |||||||||
| Random Write | |||||||||
| Sequential Read | |||||||||
| Sequential Write | |||||||||
There are no big surprises from testing the Inland Performance Plus with varying block sizes. The Phison E18 controller has no problem handling block sizes smaller than 4kB. The random write results are a little rough especially when testing the drive at 80% full, but it's hardly the only drive to have SLC cache troubles here. Like many other drives, the sequential read performance doesn't scale smoothly with the larger block sizes, and the drive really needs a larger queue depth or very large block size to deliver great sequential read performance.
Facebook
Twitter
RSS
118 Comments
View All Comments
GeoffreyA - Thursday, May 20, 2021 - link
"templates can do some crazy stuff. Looking up SFINAE will quickly take you down the rabbithole"
I gave it a try and, Great Scott, it's already looking like Mad Hatter territory. Will take a while to decipher all that. Even "using" and "auto" are starting to look puzzling.
"I always used a few typedef"
typedefs were a must to combat all those colons and endless right angle brackets.
mode_13h - Thursday, May 20, 2021 - link
> > move-constructors"> I suppose those are the counterparts of copy constructors
> for an object that's about to sink into oblivion.
This touches on something very interesting about C++, which is that certain operations on objects have well-specified semantics and the compiler is allowed to make substitutions, on that basis. This is very un- C-like, where the compiler only calls the functions you tell it to. Sure, it can optimize *out* some functions, but there's never a case where it just decides to call something different (but semantically equivalent) to what you coded.
A move constructor (or move assignment) is allowed to assume that the only subsequent operation on the original object is destruction. So, if an existing object owns some heap-allocated memory, it can be transferred to the new object. However, it's not required to do so -- copying the data is also valid. In any case, the original object must be left in some state that still allows its destructor to successfully execute.
GeoffreyA - Thursday, May 20, 2021 - link
"the original object must be left in some state that still allows its destructor to successfully execute"I think I'd copy the pointers or handles over and set them to null in the original object. That ought to do it. Let's hope they don't use move constructors when they start "copying" people or things. Might be painful.
mode_13h - Friday, May 21, 2021 - link
> I think I'd copy the pointers or handles over and set them to null in the original object.Exactly. Transfer ownership to the new object and set the original to it empty state. That's the typical approach. And, for any data members that have their own move constructors, you invoke those.
> Let's hope they don't use move constructors when they start "copying" people or things. Might be painful.
Kind of like the Star Trek "transporter", though. Getting back into the familiar realm of metaphysics, I'd never send myself through one. I believe you'd die and simply create a copy who thinks they're you.
GeoffreyA - Sunday, May 23, 2021 - link
I think so too and don't like the idea of copy + destroy == teleport. The "clone think it's me" motif brings up moral questions. If I were cloned, who is the real me? Certainly, the original; but from the clone's point of view, he's the main fellow and is out to prove it. I suspect cloning hints at a breaking down of our everyday notion of self as unique instance. Three Eiffel Towers aren't a problem but would be a strange sight.I feel this whole thing hints at something deeper in reality. Conceivably, "move" might be impossible to implement at some primitive level. Perhaps all moves, in the universe, were implemented as copy + delete (or reassigning pointers). Even the flow of time could have been done this way, constantly copying, with changes, and throwing away the old. Taken further, I reckon that "move" could be a high-level concept; and at some pre-spacetime level, there's no location/locality.
mode_13h - Sunday, May 23, 2021 - link
> I feel this whole thing hints at something deeper in realityI'm not qualified to comment on that, but it reminds me of the FSA theory of spacetime.
Also, reminds me of the recent discovery that quantum leaps aren't instantaneous, as previously thought. I'm pretty sure I didn't even know they were supposed to be instantaneous.
GeoffreyA - Sunday, May 23, 2021 - link
I remember reading about that, not too long ago, and being pleasantly surprised that there was some touch of determinism to it as well. That was a revelation."instantaneous, as previously thought"
Not too sure about quantum leaps but think that comes from collapse of the wave function, which is supposedly an instantaneous, non-local process. Some interpretations reject collapse though.
GeoffreyA - Monday, May 17, 2021 - link
I am pre-C++11 and out of touch with programming in general, sadly. And this may seem madness but I'm still using VC++ 6.0, during those rare times I touch a bit of code.I see C++ as a beautiful, potent language (along with the STL), despite its messiness. Its data abstraction and hiding mechanisms offer real advances over C. But a tincture of the latter's philosophy will add much to any C++ program. And I reckon that templates are where its real power lies. I mean, the idea of some function or iterator knowing nothing about some object, yet being able to operate on it. Some QuickSort could be sorting something it hasn't got a clue about, yet works because the objects defined the comparison operators. I've felt there's something strangely haunting about some of these mechanisms in C++, especially templates and virtual functions, as if they bore some elusive analogy to the mechanisms underlying reality. Who knows?
mode_13h - Tuesday, May 18, 2021 - link
> I'm still using VC++ 6.0OMG. Do yourself a favor and check out MS Visual Studio Community Edition.
https://visualstudio.microsoft.com/vs/community/
I don't have any experience with it, as I use GCC (and now Clang) directly, but I'm betting you'll never go back to VC++ 6.0, after you try it.
> I am pre-C++11
https://en.cppreference.com/w/
It actually has references for both C and C++. MSDN now has all their C & C++ language + standard library references online, too.
However, when I want to write something simple, I usually reach for Python. It's not the simple language you could learn in an afternoon, like it was 2 decades ago, but you can quickly pick up enough to be off and running in very little time, indeed.
GeoffreyA - Wednesday, May 19, 2021 - link
Much obliged!I actually tried VC++ 2010 some years ago, the Express version. Heard of the Community Edition too, and thought it was just another Express; but looking at it now, I see that's not the case. Who knew MS had got so generous? Well, I'm excited and will certainly give it a try when I can. Hopefully, import or recreate my 6.0 projects. And thanks for that language reference as well. I had always overlooked it and relied on the MSDN docs. It looks good. (Funny enough, I see that C++11 added an array<T, n> class. I remember I wrote my own long ago and the interface turns out to be roughly the same as that one.)