by Zsolt Kerekes,
editor - June 24, 2011 |
The memory chip count ceiling around
which the SSD controller
IP is optimized - predetermines the
achieving system-wide goals like
|All enterprise flash SSDs (and those
built using other types of non
volatile memories too) can be said to belong into one of two fundamental
architectural groups which I call - "big" and "small".
(Who said my SSD articles were complicated?)
simplicity you can think about the dividing line between these as follows.
- small SSD architecture - the controller is designed to work with a
small number of flash memory chips - 10 or less.
It will work with
more too - but
dice have already been rolled to predict everything else which will follow
on from the "small" architecture decision.
What are the characteristics of the 2 SSD types above?
- big SSD architecture - the SSD design has been optimized for a
typical installed set of maybe 1,000 memory chips.
It could be a lot
less - maybe even as few as a hundred - or it can be more. Once again - the "big"
architecture design decision sets the pattern of everything else about the SSD.
In big designs it's also not uncommon for the vendors to talk about having
multiple SSD controllers. In reality some of these are data movement engines -
with more limited roles than the "can do almost everything"
controllers in small architectures. That's because these big architecture
designs tend to be spread around spatially and due to transmission line effects
and delays routing around the SSD card set - it's necessary to spread the data
movers around among the memory chips where they can do most good with least
Not surprisingly "small" architecture SSD
controllers are the essential building blocks for physically small SSDs -
ranging from SSDs on a chip
- up through to 2.5"
and 3.5" form
factors. Due to their small footprint they are the most flexible to deploy.
And they don't stay in those slots as singles. They also can appear in arrays on
cards like PCIe SSDs
and in rackmount SSD
Meanwhile - most - but not all - large architecture SSDs
started life in rackmounts and (some) worked their way down into PCIe SSDs too.
table below gives you some examples of the best known companies in each of these
|It's interesting to see that in the "big"
set you can see companies in the same set here which are in disjoint sets when
you view them from the
legacy vs new
dynasty classification. |
And they are also in different sets
again when you look at the
RAM flash cache
classifications - when SandForce and Fusion-io come together in the "skinny"
Understanding those differences tells you everything you
need to know about the strengths and weaknesses of these products in
different markets and applications.
Of course most of you don't know
enough about computer architecture, performance optimization, flash memory
physics, reliability and the SSD market to model how those factors interact -
and there's no reason why you should. But without understanding those things
you take a big gamble
every time you choose an SSD supplier or company to invest in.
- the law of large numbers means that if enough people make similar choices -
then those become the
right decision - because the market is a good filter to all new design
projects and business plans.
But if you're still trying to figure out
why is the big vs small model can be useful - here's one example.
the small model - the controller designer does the best job s/he can to
optimize the performance and reliability of the individual SSD. That's all which
can be done. Because it's sold as a single unit and has to work on its own.
another designer comes along and puts a bunch of these small SSDs into an array
(for example in a COTS
rackmount) then the small architecture SSDs become a component inside
someone else's (usually small but next level up) controller. (I call this next
level small - because most RAID
architectures are optimized around 10 drives rather than 1,000 - which takes us
into cloud territory).
I lose you - the disadvantage of stacking up arrays of small
architecture SSDs (compared to large architecture) are:-
In theory and in practise large architecture SSDs are faster and
more reliable than similarly sized arrays assembled from small SSDs.
that - the small architecture arrays can sometimes cost less - because the small
SSDs work in other applications too (which the large SSDs can't address)
therefore bringing the unit costs and risks down.
controller architecture is not the same as "big topology" or "big
SSD topology is independent of SSD controller
architecture. For example Big Topology - can be
Big Data can be implemented
around either type of SSD controller. But I've shown earlier in this article -
why big data can cost more if it is implemented by small controller
architecture modules - due to the inefficiencies in using raw flash memory
- having hundreds of PCIe SSD cards in clusters - as supported at the chip
level by PLX Technology.
But PLX's PCIe fabric chips are used by leading SSD companies in both the small
and large controller architecture camps.
If you're not very technical and still trying to grasp the
important differences I've defined in this article - here's an analogy you may
find useful. A collection of short stories doesn't work the same way as a novel.
leave it there for now.
|selected reader comments
and responses to the above article|
- I think there are subsequently two types of big implementations, ones where
centralized and ones where RAID and cache are decentralized.
RamSan-500 is an example of a big implementation with centralized RAID and
cache. Where the RamSan630 is an example of one with distributed RAID.
The benefit of a distributed RAID solution is that it keeps a RAID controller
from becoming the system bottleneck and offers a huge boost to performance. The
disadvantage to the distributed RAID is that the device ends up having different
reliability characteristics and architecture implications than the centralized
version people are used to (from typical storage arrays).
|more SSD architecture ideas
Availability, scalability, integration and
manageability matter just as much as performance -
How ONFI3 flash channels relate to high throughput
PCIe SSD design -
by Cadence (pdf).
|auto tiering SSDs|
the SSD Heresies
SSD controller chips
SSD Jargon Explained
SSD Reliability Papers
SSDs - the big
way to the petabyte SSD
SSD's past phantom demons
Imprinting the brain of
sudden power loss
RAM Cache Ratios in
new way of looking at Enterprise SSDs
capacity - the iceberg syndrome
Are MLC SSDs Safe
in Enterprise Apps?
the Problem with
Write IOPS - in flash SSDs
SSD Myths and
Legends - "write endurance"
Challenges in flash SSD Design
Market Trends in the
Rackmount SSD Market
an introduction to SSD
Data Recovery Concepts
future of enterprise data storage (circa 2020)
RAM SSDs versus Flash
SSDs - which is Best?
principles of bad
block management in flash SSDs
How Bad is - Choosing the
Wrong SSD Supplier?
Can you trust flash SSD
Clarifying SSD Pricing -
where does all the money go?
Z's Laws - Predicting
Future Flash SSD Performance
Why Consumers Can Expect
More Flaky Flash SSDs!
Can you believe the
word "reliability" in a 2.5" SSD ad?
Fast Purge flash SSDs -
when "Rugged SSDs" won't do the job
Calling for an
End to Unrealistic SSD vs HDD IOPS Comparisons
||Megabyte was worried
about the random access time in his new bulk storage solution.
small controller architecture too|
|When it comes to
RAID was better than what
it replaced in the 1980s but if you started again with the internet
connectivity and processors we have today and started to design big arrays of
disks from first principles then you wouldn't see just the RAID systems you see
That's because RAID is small controller architecture too.
optimizes over maybe 5 to 10 disks.
If, instead you optimize
reliability etc over 100 disks then you get better efficiency. That's why
Google designed its own disk managment system. The cost savings at the million
plus disk level are worthwhile.
The cloud thinking alternative to
RAID arrays is also what you see in systems from
It's exactly the same principle in SSDs.
around less than 10 flash chips whereas
Violin optimize around
|more SSD design related articles|
Adaptive R/W and
DSP in flash SSD IP
consequences in SSD design
factors which influence
and limit flash SSD performance
|Violin video - advantages
of own controllers|
|Editor:- January 23, 2012 - I commented recently
that the top 10 SSD
companies in Q4
2011 all had one thing in common (apart from the fact they make SSDs)...|
all have their own proprietary
architecture which they can use to optimize products for some applications
and markets (even if some of them also use other controllers too).
video - Violin's,
CTO Software Jonathan Goldick
talks about the benefits they get from having their own controller.
more SSD videos.|
|the SSD story - market
survival of the fittest?|
emerging size of
the flash SSD market as you see it today was by no means inevitable. It owes a
lot to 3 competing storage media competitors which failed to evolve fast enough
in the Darwinian jungle of the storage market in the
One of these 3 contenders is definitely on the road to extinction -
but could one of the other 2 still emerge to threaten flash SSDs?
recently published article -
SSD's past phantom
demons explores the latent market threats which hovered around the flash SSD
market in the past decade. They seemed real and solid enough at the time.
|| Getting a realistic
perspective of flash SSD's past demons (which seemed very threatening at the
time) may help you better judge the so-called "new" generation of nv
memory contenders - which are also discussed in the article. ...read the article|
sudden power loss|
|Why should you care
what happens in an SSD when the power goes down? |
This important design
feature - which barely rates a mention in most SSD datasheets and press releases
- has a strong impact on
SSD data integrity
This article will help you understand why some
SSDs which (work perfectly well in one type of application) might fail in
others... even when the changes in the operational environment appear to be