Overclock.net › Forums › Components › Hard Drives & Storage › SSD › Samsung 840 EVO read speed drops on old-written data in the drive
New Posts  All Forums:Forum Nav:

Samsung 840 EVO read speed drops on old-written data in the drive - Page 292

post #2911 of 3279
Quote:
Originally Posted by Sheyster View Post

I think what they did is code the firmware to "look ahead" and mitigate based on read patterns. This is why we see instant (but not 100% full speed) read improvement. My guess is they ARE detecting when the drive is being benchmarked, and mitigating on the fly. If the firmware was truly magical like some seem to think, we'd see 100% read speed improvement immediately, which is not the case.

Seems easy enough to test.

A. Take drive with stale data.
B. Copy stale data to second drive while recording speed and time to copy.
C. Install firmware.
D. Immediately copy stale data to different folder on same second drive while recording speeds and time to copy.
E. Compare results from B and D. If there is an improvement on par with what the benchmarks show, then they aren't "quake/quack"ing the benchmarks.
post #2912 of 3279
Quote:
Originally Posted by SATDK View Post

You are under the mistaken impression that your software (and any other) can't be fooled by a few lines of code.

Check for programs X,Y,Z. Do this.

Easy to do and is the level that Samsung has fallen too many times before. Any benchmark program including your utility doesn't do anything with the data, it merely returns 'data was read'. Therefore no error correction or bypassing of such needed.

    This is quite feasible on a device like a phone, where Samsung was caught doing this in the past.  But, things are different for a SATA storage device like a SSD.  Storage devices themselves have no information about who is asking for the data.  And even if they did, the requester would always be NTFS.sys, and not different programs.  So a simple SSD firmware update cannot introduce funny rules to change behavior for real file testers like SSD Read Speed Tester and File Bench.  However, the following is possible:
  • HD Tune (and other surface scanners) could easily be detected since they start reading sequentially from the beginning of the drive to the end.  Nothing else ever naturally does this.  The big question: But if Samsung is doing this, why do we still have so many "After" HD Tune screenshots that are still erratic and slower than 500 MB/s?
  • Even though there is no way the SSD would know what program caused a particular read request, Magician could conceivably get this information and do something with it, either with RAPID, or by passing some information to the SSD itself.  Slim proposition, but technically feasible.  We need more benchmarks from people who updated the firmware but have uninstalled Magician (or never installed it in the first place).
    But there's no faking tests like this one.  And it would be practically impossible to create the second image in this test by pretending to read data faster by returning errors or invalid data (the only way if the SSD can't really read that fast).
 
 
Quote:
Originally Posted by SATDK View Post

My theory also explains the new BSOD's, btw. While your position is based on a Samsung that wants to do their best for it's customers and they have blatantly shown time and again that is not what they're here to do.

    I would like to know more about this (particularly the first part).
 
 
Quote:
Originally Posted by SATDK View Post

Step back from how unlikely it is for Samsung to do such dastardly deeds and then maybe you too will see how all (or at least some) of your support for Samsung is misplaced.

You and others here should not be defending Samsung, that is their job. But they're not and that is the first clue that their goals are not as altruistic as you and a few other here think they are.

    I am not supporting/defending Samsung, and they are not paying me a cent to write any of this.  In fact, I personally have several 840 EVOs, and have installed numerous others for customers and will be recalling them (over time) to upgrade the firmware, at my expense.  Unfortunately, I have yet to see one personally that has been seriously affected—I'd love to run some tests of my own!
    My only purpose with these type posts is to address the unsubstantiated speculation and fear mongering with facts.  If it were not Samsung and I saw the thread, I'd be doing the same thing.  Please don't forget that it was me who wrote the now well known SSD Read Speed Tester specifically to put the heat on Samsung in the first place with very easy to visualize benchmark graphs.
 
 
Quote:
Originally Posted by SATDK View Post

And because of this, I'm sure that we'll be discussing this same/related issue in a few months from now again. Because fix #3 will be in the wild for an issue that originated in the middle of 2013.

    And let me go on record and say that we will not be seeing this issue again in several months.
My desktop PC
(14 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i7-3770K Gigabyte P67A-D3-B3 NVIDIA GeForce 8400 GS  1x Corsair 8 GB 
Hard DriveHard DriveHard DriveOS
Kingston SV300S3 WesternDigital WD10EZEX Samsung HD154UI Windows 7 Ultimate SP1 x64 
MonitorMonitorKeyboardPower
Daewoo L947BK Gateway FPD1530 HTK-2001 Dynex DX-400WPS 
MouseAudio
Kensington K72400 Realtek ALC889 
  hide details  
Reply
My desktop PC
(14 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i7-3770K Gigabyte P67A-D3-B3 NVIDIA GeForce 8400 GS  1x Corsair 8 GB 
Hard DriveHard DriveHard DriveOS
Kingston SV300S3 WesternDigital WD10EZEX Samsung HD154UI Windows 7 Ultimate SP1 x64 
MonitorMonitorKeyboardPower
Daewoo L947BK Gateway FPD1530 HTK-2001 Dynex DX-400WPS 
MouseAudio
Kensington K72400 Realtek ALC889 
  hide details  
Reply
post #2913 of 3279
Quote:
Originally Posted by Sheyster View Post


I think what they did is code the firmware to "look ahead" and mitigate based on read patterns. This is why we see instant (but not 100% full speed) read improvement. My guess is they ARE detecting when the drive is being benchmarked, and mitigating on the fly. If the firmware was truly magical like some seem to think, we'd see 100% read speed improvement immediately, which is not the case.

 

If they were doing something like this, such as using some extra bandwidth of the controller to read ahead, would it not show up as an increase in power consumption?  After all bandwidth = power consumption.  Didn't Malvento specifically test for this and note it in one of his earlier posts?  I'm not sure how he did it since he didn't go into detail, but I did in one of my earlier posts if anyone wants to test this theory.  Breaking the ground connections to insert a small series resistor may not be the most ideal way, but I still think it is the easiest to do using just one DVM set to read millivolts.  The other way would be to put in two resistors, one each of the two power connections, to do the same thing but you will either need a two channel scope or two DVMs that can read accurately at the millivolt scale.  Those types of meters don't update very frequently so you would need to run an extended test to get an average reading.  The ideal sense resistor would be a 1 ohm so that 1mV = 1 mA using ohm's law.  10 ohms would be more practical for most cheap DVMs.  A digital storage oscilloscope DSO with a deep memory would be the best tool for this since they can add the two channels and do the math to give you an integrated total voltage (power) measurement.

post #2914 of 3279
The magician can be easy fooled by enabling compression on temp file Magician_Vol_File.dat , and score skyrocket smile.gif

post #2915 of 3279
Quote:
Originally Posted by Haswelled View Post

If they were doing something like this, such as using some extra bandwidth of the controller to read ahead, would it not show up as an increase in power consumption?  After all bandwidth = power consumption.  Didn't Malvento specifically test for this and note it in one of his earlier posts?  I'm not sure how he did it since he didn't go into detail, but I did in one of my earlier posts if anyone wants to test this theory.  Breaking the ground connections to insert a small series resistor may not be the most ideal way, but I still think it is the easiest to do using just one DVM set to read millivolts.  The other way would be to put in two resistors, one each of the two power connections, to do the same thing but you will either need a two channel scope or two DVMs that can read accurately at the millivolt scale.  Those types of meters don't update very frequently so you would need to run an extended test to get an average reading.  The ideal sense resistor would be a 1 ohm so that 1mV = 1 mA using ohm's law.  10 ohms would be more practical for most cheap DVMs.  A digital storage oscilloscope DSO with a deep memory would be the best tool for this since they can add the two channels and do the math to give you an integrated total voltage (power) measurement.
Many SSD firmwares do some form of read-ahead (as do HDD's). It's a common practice in an attempt to anticipate what the next request from the host might be. In the case of the EVO slow down issue, read-ahead can't fix this issue, as those testing it are performing sequential writes much larger than any read-ahead cache would be capable of. Read-ahead only helps with response time where the host is reading at a rate slower than the SSD is capable of (i.e. QD=1 sequential reads). Silicon Motion controllers have a more aggressive read-ahead, which gives them a slight edge in low queue depth sequentials (at the cost of having less cache memory available to optimize for writes or mixed workloads).
As for the shunt, 1 Ohm is *way* too high of a resistance. I use precision 0.01 or 0.02 Ohm shunts , with special pre-amps (50x or 100x) designed to also reduce line-level noise prior to sending the signal to the DAQ. You also need to feed supply voltage into the power measurement, as slight voltage changes translate to changes in actual power draw. An example of this power consumption testing in use: http://www.pcper.com/reviews/Storage/PCIe-SSD-Roundup-Samsung-SM951-NVMe-vs-AHCI-XP941-SSD-750-and-More/Power-Consumption
post #2916 of 3279
Quote:
Originally Posted by Haswelled View Post

If they were doing something like this, such as using some extra bandwidth of the controller to read ahead, would it not show up as an increase in power consumption?  After all bandwidth = power consumption.  Didn't Malvento specifically test for this and note it in one of his earlier posts?  I'm not sure how he did it since he didn't go into detail, but I did in one of my earlier posts if anyone wants to test this theory.  Breaking the ground connections to insert a small series resistor may not be the most ideal way, but I still think it is the easiest to do using just one DVM set to read millivolts.  The other way would be to put in two resistors, one each of the two power connections, to do the same thing but you will either need a two channel scope or two DVMs that can read accurately at the millivolt scale.  Those types of meters don't update very frequently so you would need to run an extended test to get an average reading.  The ideal sense resistor would be a 1 ohm so that 1mV = 1 mA using ohm's law.  10 ohms would be more practical for most cheap DVMs.  A digital storage oscilloscope DSO with a deep memory would be the best tool for this since they can add the two channels and do the math to give you an integrated total voltage (power) measurement.

I'm basically speculating based on the observed behavior right after the firmware update, without running the optimization tool. Notice I used "think" and "guess" in my post. wink.gif

I kind of wonder if Samsung thought anyone would actually install the firmware and NOT run the advanced optimization tool. If you do it the way Samsung wants you to do it, the problem is fully masked before you run a single benchmark. As we know, many people have installed the firmware, not run optimization, and started to see immediate improvement when running a benchmark. The assumption was the D firmware isn't doing much unless the system is idle. However, if someone flashes the D firmware, reboots and immediately runs a benchmark, they seem improvement, albeit not a full recovery. Indications are ~ 300-350 MB / sec. What can we infer from this? Sounds to me like there is some sort of active discovery and mitigation going on in real time.
Edited by Sheyster - 5/18/15 at 12:59pm
EconoGamer#
(16 items)
 
  
CPUMotherboardGraphicsRAM
i7 4790K 5 GHz (delidded) ASRock Z97 Extreme4 nVidia Titan Xp Team Xtreem 16GB/2400 
Hard DriveHard DriveCoolingOS
Corsair Force GT 120G SSD (OS) Crucial MX200 500G SSD (Games) Corsair H75 Hydro Cooler Windows 10 x64 
MonitorKeyboardPowerCase
Acer Predator Z35 Corsair K95 RGB Platinum Corsair HX750 v2 80+ Gold Thermaltake Core X9 (M0dd3D!) 
MouseMouse PadAudioAudio
Logitech G403 wireless XTrac Ripper XL (cloth) Realtek ALC1150 (on-board) Audio Technica ATH-MSR7 Headphones 
  hide details  
Reply
EconoGamer#
(16 items)
 
  
CPUMotherboardGraphicsRAM
i7 4790K 5 GHz (delidded) ASRock Z97 Extreme4 nVidia Titan Xp Team Xtreem 16GB/2400 
Hard DriveHard DriveCoolingOS
Corsair Force GT 120G SSD (OS) Crucial MX200 500G SSD (Games) Corsair H75 Hydro Cooler Windows 10 x64 
MonitorKeyboardPowerCase
Acer Predator Z35 Corsair K95 RGB Platinum Corsair HX750 v2 80+ Gold Thermaltake Core X9 (M0dd3D!) 
MouseMouse PadAudioAudio
Logitech G403 wireless XTrac Ripper XL (cloth) Realtek ALC1150 (on-board) Audio Technica ATH-MSR7 Headphones 
  hide details  
Reply
post #2917 of 3279
Quote:
Originally Posted by SATDK View Post

You are under the mistaken impression that your software (and any other) can't be fooled by a few lines of code.

Check for programs X,Y,Z. Do this.

Easy to do and is the level that Samsung has fallen too many times before. Any benchmark program including your utility doesn't do anything with the data, it merely returns 'data was read'. Therefore no error correction or bypassing of such needed.

You have a gross conceptual error, in that without Magician installed, there is no physical way the SSD itself can be aware of which program is accessing it. Magician is not required. The update passed to me prior to public release was the ISO version. My initial testing was all done without Magician installed, as I updated the firmware from a DOS USB device. Without any Samsung software at the Windows level, all requests to the SSD would be via the Windows Kernel.

All an SSD does is respond to read or write requests. It has no way of knowing which program is reading the data. The request looks identical regardless of which program (or the Windows Kernel, etc) is accessing the data.

Also, why are you guys going so far as conspiracy theories? Trying to conceive physically impossible / far fetched ways for Samsung to trick you is quite frankly a waste of time and effort. This one appears fixed. Start beating that drum if they slow down again, or divert your efforts to drawing attention to the mSATA version or the other 840 TLC models that also see the slow down and have not yet seen a patch.
post #2918 of 3279
Quote:
Originally Posted by malventano View Post


Many SSD firmwares do some form of read-ahead (as do HDD's). It's a common practice in an attempt to anticipate what the next request from the host might be. In the case of the EVO slow down issue, read-ahead can't fix this issue, as those testing it are performing sequential writes much larger than any read-ahead cache would be capable of. Read-ahead only helps with response time where the host is reading at a rate slower than the SSD is capable of (i.e. QD=1 sequential reads). Silicon Motion controllers have a more aggressive read-ahead, which gives them a slight edge in low queue depth sequentials (at the cost of having less cache memory available to optimize for writes or mixed workloads).
As for the shunt, 1 Ohm is *way* too high of a resistance. I use precision 0.01 or 0.02 Ohm shunts , with special pre-amps (50x or 100x) designed to also reduce line-level noise prior to sending the signal to the DAQ. You also need to feed supply voltage into the power measurement, as slight voltage changes translate to changes in actual power draw. An example of this power consumption testing in use: http://www.pcper.com/reviews/Storage/PCIe-SSD-Roundup-Samsung-SM951-NVMe-vs-AHCI-XP941-SSD-750-and-More/Power-Consumption

 

You are correct now that I that I think about it.  1 ohm x 1 amp = 1 volt drop, which is too much considering all or almost all of that will be on the 5v rail.  I usually build such circuits with the sense resistor in the active gain stage and I was also trying to keep things in the realm of widely available parts for the average user.  Ideally, a .01 ohm precision .1% resistor running into the two inputs of an instrumentation amplifier built with four matched .1% precision resistors with a precision op-amp and secondary gain stage should be used.  This arrangement would also reduce your common mode line level noise you are talking about.  I went to your link but didn't see a schematic of your test circuit, but I'll take your word for it as you obviously know what you're doing.  Which NI DAC and software were you using?

post #2919 of 3279
Quote:
Originally Posted by Haswelled View Post

You are correct now that I that I think about it.  1 ohm x 1 amp = 1 volt drop, which is too much considering all or almost all of that will be on the 5v rail.  I usually build such circuits with the sense resistor in the active gain stage and I was also trying to keep things in the realm of widely available parts for the average user.  Ideally, a .01 ohm precision .1% resistor running into the two inputs of an instrumentation amplifier built with four matched .1% precision resistors with a precision op-amp and secondary gain stage should be used.  This arrangement would also reduce your common mode line level noise you are talking about.  I went to your link but didn't see a schematic of your test circuit, but I'll take your word for it as you obviously know what you're doing.  Which NI DAC and software were you using?
They make specialized shunt differential amps that eliminate the need for making your own quad resistor bridge - no biasing needed at all actually. The slightest variance in any of those resistors (even within 1%) throws the results considerably. I forget which DAQ it is but all of their products are good. I use the software that comes from the same guys (National Instruments).
post #2920 of 3279
Quote:
Originally Posted by Techie007 View Post

    This is quite feasible on a device like a phone, where Samsung was caught doing this in the past.  But, things are different for a SATA storage device like a SSD.  Storage devices themselves have no information about who is asking for the data.  And even if they did, the requester would always be NTFS.sys, and not different programs.  So a simple SSD firmware update cannot introduce funny rules to change behavior for real file testers like SSD Read Speed Tester and File Bench.  However, the following is possible:
  • HD Tune (and other surface scanners) could easily be detected since they start reading sequentially from the beginning of the drive to the end.  Nothing else ever naturally does this.  The big question: But if Samsung is doing this, why do we still have so many "After" HD Tune screenshots that are still erratic and slower than 500 MB/s?
  • Even though there is no way the SSD would know what program caused a particular read request, Magician could conceivably get this information and do something with it, either with RAPID, or by passing some information to the SSD itself.  Slim proposition, but technically feasible.  We need more benchmarks from people who updated the firmware but have uninstalled Magician (or never installed it in the first place).
    But there's no faking tests like this one.  And it would be practically impossible to create the second image in this test by pretending to read data faster by returning errors or invalid data (the only way if the SSD can't really read that fast).
 
 
    I would like to know more about this (particularly the first part).
 
 
    I am not supporting/defending Samsung, and they are not paying me a cent to write any of this.  In fact, I personally have several 840 EVOs, and have installed numerous others for customers and will be recalling them (over time) to upgrade the firmware, at my expense.  Unfortunately, I have yet to see one personally that has been seriously affected—I'd love to run some tests of my own!
    My only purpose with these type posts is to address the unsubstantiated speculation and fear mongering with facts.  If it were not Samsung and I saw the thread, I'd be doing the same thing.  Please don't forget that it was me who wrote the now well known SSD Read Speed Tester specifically to put the heat on Samsung in the first place with very easy to visualize benchmark graphs.
 
 
    And let me go on record and say that we will not be seeing this issue again in several months.


Quote:
Originally Posted by malventano View Post

You have a gross conceptual error, in that without Magician installed, there is no physical way the SSD itself can be aware of which program is accessing it. Magician is not required. The update passed to me prior to public release was the ISO version. My initial testing was all done without Magician installed, as I updated the firmware from a DOS USB device. Without any Samsung software at the Windows level, all requests to the SSD would be via the Windows Kernel.

All an SSD does is respond to read or write requests. It has no way of knowing which program is reading the data. The request looks identical regardless of which program (or the Windows Kernel, etc) is accessing the data.

Also, why are you guys going so far as conspiracy theories? Trying to conceive physically impossible / far fetched ways for Samsung to trick you is quite frankly a waste of time and effort. This one appears fixed. Start beating that drum if they slow down again, or divert your efforts to drawing attention to the mSATA version or the other 840 TLC models that also see the slow down and have not yet seen a patch.



I see that continuing to attack the users is still the angle we're playing here. Conceptual errors, bat-crap crazy, farfetched, anything but entertaining the possibility that Samsung is using anything and everything in it's power to cover up this huge $*up. Instead of simply acknowledging that Samsung might actually have done something wrong and continues to do so with, if not criminal intent (I'm sure their lawyers could spin this into 'we did everything in our power to fix this for our valued customers'), then ethical and I think, professional negligence.

No. No gross conceptual errors on my part. Nobody stated magician was the virus Samsung loaded on our systems, the firmware can do all this by itself. If I can plug in a USB drive and it can run a program (I'm not here to argue details, choose your own programs that run by default off of a USB drive and, it doesn't have to be a virus) on it's own, then yes, it is possible, conceptually and not so far fetched after all.

Just like they did with their phones.

Nothing shown here can refute the possibility of the facts I'm stating. Tests can be rigged (even on our own samples of an affected SSD). Any utility, even ones like SSD Speed Reader and FileBench can be detected via the firmware. The EVO does have it's own controller, firmware and ram after all.

My goal is not to win against you people. That is not my goal. I simply want Samsung to fix this properly and I don't believe they have, if they're even capable of doing so.

If nothing else, I want Samsung to officially and publicly state the issue these paperweight SSD's have and let the users decide if we should continue using them or not. No more speculation by uninformed sources on the 'net of how and why. No more theories based on drifting cell voltages and instant firmware cures. Just the facts ma'am, and I'll be on my way.

The bare facts, straight from Samsung. I don't think I'm asking too much and I'm sure this is what almost everyone else wants too from Samsung, transparency.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: SSD
Overclock.net › Forums › Components › Hard Drives & Storage › SSD › Samsung 840 EVO read speed drops on old-written data in the drive