public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Ross Younger <wry@ecoscentric.com>
To: Jonathan Larmour <jifl@jifvik.org>
Cc: "Rutger Hofman" <rutger@cs.vu.nl>,
	"Jürgen Lambrecht" <J.Lambrecht@televic.com>,
	"eCos developers" <ecos-devel@ecos.sourceware.org>,
	"Deroo Stijn" <S.Deroo@televic.com>
Subject: Re: NAND technical review
Date: Mon, 19 Oct 2009 10:53:00 -0000	[thread overview]
Message-ID: <4ADC452B.5040706@ecoscentric.com> (raw)
In-Reply-To: <4AD6A7EC.8080703@jifvik.org>

Jonathan Larmour wrote:
> I wonder if Ross has any performance data for E he could contribute?

I have done a little benchmarking and so have _some_ numbers to hand, but
the goalposts are moving and my figures are a bit old and must be treated
with caution...

On the EA LPC2468 board (Samsung K9 NAND chip), with the state of my code on
July 8, compiling with -O2 and asserts off, my NAND benchmarker reported
average page read times[*] of 3578us per page, programming 2680us, and
erasing 1848us. These stack up against the fastest-possible raw chip times
(which I computed from the "typical" times on the datasheet) of 88.5, 363.5
and 2000us.

[*] full page (2k) plus OOB

This led to a YAFFS throughput data rate, on a recently-erased NAND array,
of up to 480kB/s in reading and 578kB/s in writing. (Actual rates vary
depending on the size of chunk you pass to read() and write().)

It seems worthwhile to share numbers for the customer port I've been working
on; not because they're of direct use to the eCos project, but to show what
a difference the hardware makes.

The board is based on the Samsung S3C2410X ucontroller and carries the same
Samsung K9 NAND chip as on the EA LPC2468. Now, this CPU has a dedicated
NAND controller with hardware ECC... After I taught the library to use h/w
ECC I immediately saw a 46% speedup on reads and 38% on writes when compared
with software ECC. I've also added an option to do a partial loop unroll in
the read and write cycles which gives a further 4% boost on reads and 15% on
writes. The current (work-in-progress) numbers I have from the benchmarker
are 452us per page read, 623us per write and 1934us per erase; YAFFS
throughput is similarly impressive at 4690 kB/s in reads and 3432 kB/s in
writes. (Charles Manning has stated publicly several times that if you want
YAFFS to be fast, you should start by looking at the speed of your NAND driver.)

Of course, we're not comparing apples with apples here; the S3C2410X is an
ARM9 whose CPU clock runs at 200MHz, but the EA LPC2468 is an ARM7TDMI
running at just 48MHz, but even so the speed-up given by hardware ECC
demonstrates that option to be a no-brainer.

BTW: Some profiling and souping up is on my todo list, and some more
benchmarking will probably happen at that time. When I implement hardware
ECC support on the STM3210E I intend to produce some before and after numbers.


Ross

-- 
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.                  www.ecoscentric.com

  parent reply	other threads:[~2009-10-19 10:53 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-02 15:51 Jonathan Larmour
2009-10-06 13:51 ` Ross Younger
2009-10-07  3:12   ` Jonathan Larmour
2009-10-07 16:22     ` Rutger Hofman
2009-10-08  7:15       ` Jürgen Lambrecht
2009-10-15  3:53         ` Jonathan Larmour
2009-10-15 11:54           ` Jürgen Lambrecht
2009-10-15  3:49       ` Jonathan Larmour
2009-10-15 14:36         ` Rutger Hofman
2009-10-16  1:32           ` Jonathan Larmour
2009-10-19  9:56             ` Ross Younger
2009-10-19 14:21             ` Rutger Hofman
2009-10-20  3:21               ` Jonathan Larmour
2009-10-20 12:19                 ` Rutger Hofman
2009-10-21  1:45                   ` Jonathan Larmour
2009-10-21 12:15                     ` Rutger Hofman
2009-10-23 14:06                       ` Jonathan Larmour
2009-10-23 15:25                         ` Rutger Hofman
2009-10-23 18:03                           ` Rutger Hofman
2009-10-27 20:02                           ` Rutger Hofman
2009-11-10  7:03                           ` Jonathan Larmour
2010-12-11 19:18                             ` John Dallaway
2010-12-22 14:54                               ` Rutger Hofman
2009-10-15 15:43         ` Rutger Hofman
     [not found]     ` <4ACDF868.7050706@ecoscentric.com>
2009-10-09  8:27       ` Ross Younger
2009-10-13  2:21         ` Jonathan Larmour
2009-10-13 13:35           ` Rutger Hofman
2009-10-16  4:04             ` Jonathan Larmour
2009-10-19 14:51               ` Rutger Hofman
2009-10-20  4:28                 ` Jonathan Larmour
2009-10-07  9:40   ` Jürgen Lambrecht
2009-10-07 16:27     ` Rutger Hofman
2009-10-13  2:44     ` Jonathan Larmour
2009-10-13  6:35       ` Jürgen Lambrecht
2009-10-15  3:55         ` Jonathan Larmour
2009-10-13 12:59       ` Rutger Hofman
2009-10-15  4:41         ` Jonathan Larmour
2009-10-15 14:55           ` Rutger Hofman
2009-10-16  1:45             ` Jonathan Larmour
2009-10-19 10:53           ` Ross Younger [this message]
2009-10-20  1:40             ` Jonathan Larmour
2009-10-20 10:17               ` Ross Younger
2009-10-21  2:06                 ` Jonathan Larmour
2009-10-22 10:05                   ` Ross Younger
2009-11-10  5:15                     ` Jonathan Larmour
2009-11-10 10:38                       ` Ross Younger
2009-11-10 11:28                         ` Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
2009-11-10 12:16                           ` Chris Holgate
2009-11-12 18:32                         ` NAND technical review Ross Younger
2009-10-13 14:19       ` Rutger Hofman
2009-10-13 19:58         ` Lambrecht Jürgen
2009-10-07 12:11   ` Rutger Hofman
2009-10-08 12:31     ` Ross Younger
2009-10-08  8:16   ` Jürgen Lambrecht
2009-10-12  1:13     ` Jonathan Larmour
2009-10-16  7:29 ` Simon Kallweit
2009-10-16 13:53   ` Jonathan Larmour
2009-10-19 15:02   ` Rutger Hofman

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=4ADC452B.5040706@ecoscentric.com \
    --to=wry@ecoscentric.com \
    --cc=J.Lambrecht@televic.com \
    --cc=S.Deroo@televic.com \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=jifl@jifvik.org \
    --cc=rutger@cs.vu.nl \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).