Upgraded From SATA to M.2 SSD - Comparisons

This is a comparison of relative performance of an older 250gB Samsung
840EVO using a SATA III interface and a newly-released 500gB Samsung 960EVO
using the M.2 form factor and PCI interface. Testing was performed on my
daily-driver Shuttle SH170R6 i7-6700 system with 32gB of memory and the
normal load of W10 background programs were running. I did pause the BOINC
client which will use 100% of the cores and threads when given the chance
and nothing else is going on but none of the other benchmarking
preparations such as erasing between runs etc. were performed.

The process of transferring the C: drive from one SSD to the other was
simple and fast using the proprietary Samsung transfer program.
Installation of the M.2 device is a bit counterintuitive in that you must
physically install the device before the mandatory driver (which you must
download, just like the transfer program) will consider installing itself;
I would have expected it to be the other way round. Looking at the pictures
doesn't begin to convey how small and delicate-looking the M.2 device is --
I felt as though I was working with mittens on while installing and
securing it with that tiny post/screw without removing the graphics card
blocking full access.

As for the tests, everything seems as I would expect from reading published
benchmarks except for the 4KiB Q=1 tests which didn't show any sort of
stunning improvement unlike the Sequential Read - sometimes not even twice
as fast. Don't know if there is any fine tuning to be done or if it is even
possible but there is no denying that some operations are stunningly fast
with the newer technology.

You pays your money and you takes your chances, I guess...

250gB 840EVO with SATA III interface:

Sequential Read (Q= 32,T= 1) : 545.582 MB/s
Sequential Write (Q= 32,T= 1) : 512.766 MB/s
Random Read 4KiB (Q= 32,T= 1) : 318.592 MB/s [ 77781.3 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 301.835 MB/s [ 73690.2 IOPS]
Sequential Read (T= 1) : 511.724 MB/s
Sequential Write (T= 1) : 487.336 MB/s
Random Read 4KiB (Q= 1,T= 1) : 36.686 MB/s [ 8956.5 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 96.140 MB/s [ 23471.7 IOPS]

Test : 100 MiB [C: 48.4% (106.8/220.8 GiB)] (x5) [Interval=5 sec]
Date : 2016/12/15 21:06:58
OS : Windows 10 Professional [10.0 Build 10586] (x64)

500gB 960EVO with M.2 PCI interface:

Sequential Read (Q= 32,T= 1) : 2707.609 MB/s
Sequential Write (Q= 32,T= 1) : 1795.993 MB/s
Random Read 4KiB (Q= 32,T= 1) : 640.562 MB/s [156387.2 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 561.352 MB/s [137048.8 IOPS]
Sequential Read (T= 1) : 1283.964 MB/s
Sequential Write (T= 1) : 1759.944 MB/s
Random Read 4KiB (Q= 1,T= 1) : 51.039 MB/s [ 12460.7 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 214.907 MB/s [ 52467.5 IOPS]

Test : 100 MiB [C: 22.2% (103.3/465.8 GiB)] (x5) [Interval=5 sec]
Date : 2016/12/20 10:21:48
OS : Windows 10 Professional [10.0 Build 10586] (x64)

The test softwa
-----------------------------------------------------------------------
CrystalDiskMark 5.2.0 x64 (C) 2007-2016 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

John McGaw wrote:
This is a comparison of relative performance of an older 250gB Samsung
840EVO using a SATA III interface and a newly-released 500gB Samsung
960EVO using the M.2 form factor and PCI interface. Testing was
performed on my daily-driver Shuttle SH170R6 i7-6700 system with 32gB of
memory and the normal load of W10 background programs were running. I
did pause the BOINC client which will use 100% of the cores and threads
when given the chance and nothing else is going on but none of the other
benchmarking preparations such as erasing between runs etc. were performed.

The process of transferring the C: drive from one SSD to the other was
simple and fast using the proprietary Samsung transfer program.
Installation of the M.2 device is a bit counterintuitive in that you
must physically install the device before the mandatory driver (which
you must download, just like the transfer program) will consider
installing itself; I would have expected it to be the other way round.
Looking at the pictures doesn't begin to convey how small and
delicate-looking the M.2 device is -- I felt as though I was working
with mittens on while installing and securing it with that tiny
post/screw without removing the graphics card blocking full access.

As for the tests, everything seems as I would expect from reading
published benchmarks except for the 4KiB Q=1 tests which didn't show any
sort of stunning improvement unlike the Sequential Read - sometimes not
even twice as fast. Don't know if there is any fine tuning to be done or
if it is even possible but there is no denying that some operations are
stunningly fast with the newer technology.

You pays your money and you takes your chances, I guess...

250gB 840EVO with SATA III interface:

Sequential Read (Q= 32,T= 1) : 545.582 MB/s
Sequential Write (Q= 32,T= 1) : 512.766 MB/s
Random Read 4KiB (Q= 32,T= 1) : 318.592 MB/s [ 77781.3 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 301.835 MB/s [ 73690.2 IOPS]
Sequential Read (T= 1) : 511.724 MB/s
Sequential Write (T= 1) : 487.336 MB/s
Random Read 4KiB (Q= 1,T= 1) : 36.686 MB/s [ 8956.5 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 96.140 MB/s [ 23471.7 IOPS]

Test : 100 MiB [C: 48.4% (106.8/220.8 GiB)] (x5) [Interval=5 sec]
Date : 2016/12/15 21:06:58
OS : Windows 10 Professional [10.0 Build 10586] (x64)

500gB 960EVO with M.2 PCI interface:

Sequential Read (Q= 32,T= 1) : 2707.609 MB/s
Sequential Write (Q= 32,T= 1) : 1795.993 MB/s
Random Read 4KiB (Q= 32,T= 1) : 640.562 MB/s [156387.2 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 561.352 MB/s [137048.8 IOPS]
Sequential Read (T= 1) : 1283.964 MB/s
Sequential Write (T= 1) : 1759.944 MB/s
Random Read 4KiB (Q= 1,T= 1) : 51.039 MB/s [ 12460.7 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 214.907 MB/s [ 52467.5 IOPS]

Test : 100 MiB [C: 22.2% (103.3/465.8 GiB)] (x5) [Interval=5 sec]
Date : 2016/12/20 10:21:48
OS : Windows 10 Professional [10.0 Build 10586] (x64)

The test softwa
-----------------------------------------------------------------------
CrystalDiskMark 5.2.0 x64 (C) 2007-2016 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

Your sequential is probably limited by Intel
architecture choices. The connector could allow 4*995 MB/sec,
while the choice of buffering eats into the efficiency.

https://en.wikipedia.org/wiki/M.2

"Computer bus interfaces provided through the M.2 connector
are PCI Express 3.0 (up to four lanes)"

http://www.plxtech.com/files/pdf/tec...yload_Size.pdf

"Intel desktop chipsets support at most a 64-byte maximum payload
while Intel server chipsets support at most a 128-byte maximum
payload. The primary reason for this is to match the cache line
size for snooping on the front side bus."

It would be interesting to see what it would do on
a different architecture. Maybe when Zen comes out,
there will be another kick at the can.

*******

As for the 4K random, it's the mismatch between the block
size of flash, and the 4K size choice, which causes a problem.
The drive has to work extra hard inside, dealing with fragmentation.
You're never going to see "sequential equals random" unless
Flash is redesigned. And the industry just doesn't think that way...
Flash chips are designed for capacity, and nothing else.
It's up to the (M.2) controller designer, to make the best of
a bad situation. And you cannot "hide it with a write cache"
unless the write cache is the same size as the flash.

*******

Still, those are very nice numbers. Too bad Windows NTFS
cannot handle more than around 4500 files per second in
a typical situation. The OS has been a bottleneck for
some time. We only get the true speed of things like
SSDs, in benchmarks.

I got one exaggerated result in Linux a few months ago,
by doing CreateFile on a TMPFS file system. And I
could create 186,000 small files per second on it. I'm still
trying to figure out a way to match that on Windows. And
this is one reason I cannot recommend RAMdisks to people,
as the bottleneck spoils the fun. An SSD is cheaper and
just as effective. What would it take to fix the bottlenecks
in Windows (there is more than one) ? I don't think anyone
at Microsoft cares. If they cannot fix Windows Update,
what else can't they fix ? :-)

Paul

Thanks for an informative posting.

On Sun, 25 Dec 2016 09:36:44 -0500, John McGaw
wrote:

500gB Samsung 960EVO

On 12/25/2016 11:51 AM, Paul wrote:
If they cannot fix Windows Update,
what else can't they fix ? :-)

Paul

What problem are you having with updates?

.. wrote:
On 12/25/2016 11:51 AM, Paul wrote:
If they cannot fix Windows Update,
what else can't they fix ? :-)

Paul

What problem are you having with updates?

You have got to be joking.

You've never hear of "wuauserv, wuaueng, 100% CPU" ?
Or thousands of corporate machines that have run out
of RAM, while a single CPU core is running 100% ?

This is all the work of Windows Update, the misery maker...

Broken OSes: WinXP, Vista, Win7, Win8, Win10 (recent find)

WinXP (no fix, bandaid available)
Vista (no fix, bandaid available, much misery)
Win7 (a couple KBs help, still may need bandaid)
Win8 (a couple KBs help (not the same KB numbers), still may need bandaid)
Win10 (I used Windows Update reset to fix it, it would not
stop looping on its own. May not be the same issue.)

Paul

On 12/25/2016 1:36 PM, Paul wrote:
. wrote:
On 12/25/2016 11:51 AM, Paul wrote:
If they cannot fix Windows Update,
what else can't they fix ? :-)

Paul

What problem are you having with updates?

You have got to be joking.

You've never hear of "wuauserv, wuaueng, 100% CPU" ?
Or thousands of corporate machines that have run out
of RAM, while a single CPU core is running 100% ?

Yes, have heard of them (a while back) but I've always
found solutions or workarounds

This is all the work of Windows Update, the misery maker...

Broken OSes: WinXP, Vista, Win7, Win8, Win10 (recent find)

WinXP (no fix, bandaid available)
Vista (no fix, bandaid available, much misery)
Win7 (a couple KBs help, still may need bandaid)
Win8 (a couple KBs help (not the same KB numbers), still may need bandaid)
Win10 (I used Windows Update reset to fix it, it would not
stop looping on its own. May not be the same issue.)

Paul

Those are all pretty indistinct descriptions. I haven't used
Vista or 8 and the 10 test-bed has been non problematic),
but haven't any lasting or other than fleeting issues with
manual updates (except for 10, I don't do automatic nor
immediate updates the moment they're available) on
either XP (no longer used) or 7. (I'm retired and haven't
used server software in the last decade) But to reiterate,
what problems (if any) are YOU currently experiencing
with 7?

.. wrote:

But to reiterate,
what problems (if any) are YOU currently experiencing
with 7?

Go to Windows update after Patch Tuesday. Click
the button to cause Windows Update to deliver
a list of updates (security/optional lists).
How long does it take to come back ? 24 hours ?
More than 24 hours ? What is your CPU utilization
during those 24 hours ? Is one CPU core railed to 100% ?
Do you see a SVCHOST doing it ? When you use Process
Explorer from Sysinternals.com, is wuauserv/wuaueng the
guilty party ? And so on...

I deal with helping people on a daily basis with
this, and it's a PITA. They expect answers, I can
help a bit with some of it, but with OSes like Vista,
it's almost impossible to give them a working Windows Update
session.

An individual here, works out the "bandaid" after
every Patch Tuesday. He's stopped doing Vista.

http://wu.krelay.de/en/

I keep Windows Update turned off on purpose, so my
machines here will not have a SVCHOST running off
the rails all day long. When I need to patch, I use
MBSA 2.3, see what security patches are needed,
download them from catalog.update.microsoft.com
and so on. I spent about 20 hours in September
patching things to where I wanted them, all by
hand.

Paul

On 12/25/2016 2:35 PM, Paul wrote:
. wrote:

But to reiterate,
what problems (if any) are YOU currently experiencing
with 7?

Go to Windows update after Patch Tuesday. Click
the button to cause Windows Update to deliver
a list of updates (security/optional lists).
How long does it take to come back ? 24 hours ?
More than 24 hours ? What is your CPU utilization
during those 24 hours ? Is one CPU core railed to 100% ?
Do you see a SVCHOST doing it ? When you use Process
Explorer from Sysinternals.com, is wuauserv/wuaueng the
guilty party ? And so on...

Old issue, figured out long ago. My request for updates response
is about 3 minutes since I fixed the last problem that was causing
hours of delay combined with high single core utilization on this
particular, old q6600 quad. I HAVE the fix for what you're describing
(your below link actually covers it as well) and most recently, last
month, provided it to a friend which also corrected for him an issue
I once had.

It is my opinion that MS is intentionally providing these obstacles
so as to get users to migrate to 10, which is very much inline with
previous practices they've employed. I've never used any of the OS
I mentioned for good reason and is among the advice, such as never
turn on AU, I've offered to others.

I deal with helping people on a daily basis with
this, and it's a PITA. They expect answers, I can
help a bit with some of it, but with OSes like Vista,
it's almost impossible to give them a working Windows Update
session.

An individual here, works out the "bandaid" after
every Patch Tuesday. He's stopped doing Vista.

http://wu.krelay.de/en/

I keep Windows Update turned off on purpose, so my
machines here will not have a SVCHOST running off
the rails all day long. When I need to patch, I use
MBSA 2.3, see what security patches are needed,
download them from catalog.update.microsoft.com
and so on. I spent about 20 hours in September
patching things to where I wanted them, all by
hand.

Paul

My bet would be that if one successfully follows the
advice on the aforementioned link, wrt7, lengthy waits
for updates wouldn't be a problem as they aren't for me.