Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Erwan Velu <erwan@enovance.com>
To: "Jens Axboe" <axboe@kernel.dk>,
	"Georg Schönberger" <gschoenberger@thomas-krenn.com>,
	fio@vger.kernel.org
Subject: Re: SSD write latency lower than read latency
Date: Wed, 17 Dec 2014 11:14:30 +0100	[thread overview]
Message-ID: <54915786.3010009@enovance.com> (raw)
In-Reply-To: <548EFB15.8080704@kernel.dk>


Le 15/12/2014 16:15, Jens Axboe a écrit :
> Your guess is exactly right, that's what most flash based devices 
> (worth their salt) do. That's also why sync write latencies are mostly 
> independent of the type of nand used, whereas the read latency will 
> easily reflect that. 
But here the runtime is very limited to 60. I can imagine that if we 
push the runtime to a longer time, the cache will not be enough to hide 
the real latency of the device. The cache is said to be 1GB by 
disassembling the device, maybe if we push the devices with bigger 
iodepth & a longer run, maybe we can show the performance of the NAND : 
once the cache is getting new data faster than it can write, the cache 
will be more occupied, if we can achieve at feeding it completely then 
we are done. I had the case with a poor MLC (128GB) that had 500MB of 
SLC cache. On some pattern I was hitting the MLC at 5MB/sec ...

Note that in theirs specs, the write latency (65µs) is very close to the 
read latency (50 µs):
http://ark.intel.com/products/75679/Intel-SSD-DC-S3500-Series-160GB-2_5in-SATA-6Gbs-20nm-MLC

On the pdf 
(http://www.intel.fr/content/dam/www/public/us/en/documents/product-specifications/ssd-dc-s3500-spec.pdf), 
we also see in the QoS sheet, that writes are said to be slower than 
reads (up to 10x with iodepth=32).


  parent reply	other threads:[~2014-12-17 10:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <298214297.62025.1418642489614.JavaMail.zimbra@thomas-krenn.com>
2014-12-15 11:48 ` SSD write latency lower than read latency Georg Schönberger
2014-12-15 15:15   ` Jens Axboe
2014-12-17  0:49     ` Matthew Eaton
2014-12-17 10:14     ` Erwan Velu [this message]
2014-12-17 15:00       ` Jens Axboe
2014-12-20  8:26         ` Georg Schönberger
2014-12-20 16:38           ` Alireza Haghdoost
2014-12-20 19:33           ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54915786.3010009@enovance.com \
    --to=erwan@enovance.com \
    --cc=axboe@kernel.dk \
    --cc=fio@vger.kernel.org \
    --cc=gschoenberger@thomas-krenn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox