Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
MapReduce >> mail # user >> Why they recommend this (CPU) ?


+
Patai Sangbutsarakum 2012-10-11, 16:22
+
Jay Vyas 2012-10-11, 17:46
+
Russell Jurney 2012-10-11, 17:56
+
Ted Dunning 2012-10-11, 18:38
+
Russell Jurney 2012-10-11, 19:03
+
Patrick Angeles 2012-10-11, 19:36
+
Goldstone, Robin J. 2012-10-11, 19:47
+
Ted Dunning 2012-10-11, 19:56
Copy link to this message
-
Re: Why they recommend this (CPU) ?
On 11 October 2012 20:47, Goldstone, Robin J. <[EMAIL PROTECTED]> wrote:

>  Be sure you are comparing apples to apples.  The E5-2650 has a larger
> cache than the E5-2640, faster system bus and can support faster (1600Ghz
> vs 1333Ghz) DRAM resulting in greater potential memory bandwidth.
>
>  http://ark.intel.com/compare/64590,64591
>
>
mmm. There is more $L3, and in-CPU sync can be done better than over the
inter-socket bus -you're also less vulnerable to NUMA memory allocation
issues (*).

There's another issue that drives these recommendations, namely the price
curve that server parts follow over time, the Bill-of-Materials curve, aka
the "BOM Curve". Most parts come in at one price, and that price drops over
time as a function of: volume parts shipped covering
Non-Recoverable-Engineering (NRE costs), improvements in yield and
manufacturing quality in that specific process, ...etc), until it levels
out a actual selling price (ASP) to the people who make the boxes (Original
Design Manufacturers==ODMs) where it tends to stay for the rest of that
part's lifespan.

DRAM, HDDs follow a fairly predictable exponential decay curve. You can
look at the cost of a part, it's history, determine the variables and then
come up with a prediction of how much it will cost at a time in the near
future. It's these BOM curves that was key to Dell's business model -direct
sales to customer meant they didn't need so much inventory and could
actually get into a situation where they had the cash from the customer
before the ODM had built the box, let alone been paid for it. There was a
price: utter unpredictability of what DRAM and HDDs you were going to get.
Server-side things have stabilised and all the tier-1 PC vendors qualify a
set of DRAM and storage options, so they can source from multiple vendors,
so eliminating a single vendor as a SPOF and allowing them to negotiate
better on cost of parts -which again changes that BOM curve.

This may seem strange but you should all know that the retail price of a
laptop, flatscreen TV, etc comes down over time -what's not so obvious are
the maths behind the changes in it's price.

One of the odd parts in this business is the CPU. There is a near-monopoly
in supplies, and intel don't want their business at the flat bit of the
curve. They need the money not just to keep their shareholders happy, but
for the $B needed to build the next generation of Fabs and hence continue
to keep their shareholders happy in future. Intel parts come in high when
they initially ship, and stay at that price until the next time Intel
change their price list, which is usually quarterly. The first price change
is very steep, then the gradient d$/dT reduces, as it gets low enough that
part drops off the price list never to be seen again, except maybe in
embedded designs.

What does that mean? It means you pay a lot for the top of the line x86
CPUs, and unless you are 100% sure that you really need it, you may be
better off investing your money in:
 -more DRAM with better ECCs (product placement: Chip-kill), buffering, :
less swapping, ability to run more reducers/node.
 -more HDDs : more storage in same #of racks, assuming your site can take
the weight.
 -SFF HDDs : less storage but more IO bandwidth off the disks.
 -SSD: faster storage
 -GPUs: very good performance for algorithms you can recompile onto them
 -support from Hortonworks to can keep your Hadoop cluster going.
 -10 GbE networking, or multiple bonded 1GbE
 -more servers (this becomes more of a factor on larger clusters, where the
cost savings of the less expensive parts scale up)
 -paying the electricity bill.
 -keeping the cost of building up a hadoop cluster down, so making it more
affordable to store PB of data whose value will only appreciate over time.
 -paying your ops team more money, keeping them happier and so increasing
the probability they will field the 4am support crisis.

That's why it isn't clear cut that 8 cores are better. It's not just a
simple performance question -it's the opportunity cost of the price
difference scaled up by the number of nodes. You do -as Ted pointed out-
need to know what you actually want.

Finally, as a basic "data science" exercise for the reader:

1. calculate the price curves of, say, a Dell laptop, and compare with the
price curve of an apple laptop introduced with the same CPU and at the same
time. Don't look at the absolute values -normalising them to a percentage
is better to view.
2. Look at which one follows a soft gradient and which follows more of a
step function.
3. add to the graph the intel pricing and see how that correlates with the
ASP.
4. Determine from this which vendor has the best margins -not just at time
of release, but over the lifespan of a product. Integration is a useful
technique here. Bear in mind Apple's NRE costs on laptop are higher due to
the better HW design but also the software development is only funded from
their sales alone.
5. Using this information, decide when is the best time to buy a dell or an
apple laptop.
I should make a blog post of this, "server prices: it's all down to the
exponential decay equations of the individual parts"

Steve "why yes, I have spent time in the PC industry" Loughran

(*) If you don't know what NUMA this is, do some research and think about
its implications in heap allocation.

+
Russell Jurney 2012-10-13, 07:22
+
Aaron Eng 2012-10-11, 19:15
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB