Showing posts with label hardware. Show all posts
Showing posts with label hardware. Show all posts

2014/03/30

The New Disruption in Computing

Since 2000, we've been progressively bumping into limits, or end-points, in all areas of silicon technologies. Some I've mentioned previously.

The thesis of this piece is the Next Technology Disruption is No Disruption, No Revolution:
instead of exponential growth of technologies, decreasing unit prices and increasing volume sales, we're now seeing zero or slow growth, steady or increased unit prices (especially if supply-chain is disrupted), and in all but a few market segments, sales are in decline and profits are stressed in many vendors. I believe these are linked.

2012/09/10

Future of Big Iron servers and Expensive Databases

This article came across a list, what follows was my response.
IBM and Oracle Present Rival Chips for 'big Iron' Servers
Wonderful to see the Dinosaurs still dukeing it out.

The eDRAM from IBM for the L3 cache is a big move. Like when they figured out how to use Copper in chips and reduced power use, hence heat production significantly.

I suspect we're seeing a replay of the late 1980's demise of mainframes... Not fast, not universal, not complete, but 90+% of the business goes away, killing weak supporting businesses.

Everyone but IBM's System Z and Unisys ClearPath went away - or into emulation.
[Clearpath = emulation on Xeon of 2200 & B-series]

In my view, two forces have converged to push these high-end niche processors into irrelevance:
  • Patterson's Brick Wall (2006):
    • Power Wall + Memory Wall + ILP Wall = Brick Wall
  • "infinite" IO/Sec and virtual-RAM with PCI-SSD. eg Fusion-IO
With cheap PCI-SSD by the Terabyte, the majority of Apps/enterprises don't need:
  • Big Iron Databases
  • Big Iron Storage Arrays and supporting SAN's
  • Big Iron multi-chip fast uniprocessing cores.
A lot of the complexity of Big Iron DB's (like Oracle) is aimed at achieving "speed" in the face of low-performing HDD's... [slow IO/sec, not streaming throughput]

If the whole of a relational DB (tables) fits in memory (or fast Virtual memory), then doesn't the DB become very simple, modulo ACID tests and writing "commits" to persistent, high-reliability storage?

Which means we might start seeing a bunch of in-memory DB's, like NoSQL, but for normal-sized DB's (1-5Gb), not large collections.

There's an economic rule on product substitution that led to the relatively quick decline in IBM mainframe sales:
  • when the capital expenditure on a substitute is less than the operational costs of the current system, barriers to adoption are removed.
    • capital costs are 'sunk' and can't be recovered.
    • To realise savings, you have to wait for the next upgrade or refresh cycle.
    • But the conversion costs have to be factored in, and incumbent vendors take care to price upgrades, even "forklift upgrades" (complete replacement) under the total cost of moving to a new solution. [Used to advantage by Tier 1 Storage Array vendors currently].
    • But Operational Costs, like maintenance charges, aren't 'sunk'.
      • They are due every year.
      • When a whole system is less than recurrent costs, businesses can quickly and easily justify the change.
      • They write-off the CapEx for the old equipment and wheel it out the door.
      • Usually "Big Iron" hardware has zero residual value, even when 2 years old.
      • When the equipment is on the cusp of being obsolescent, it is worse.
      • Or they have to figure out how to break the lease.
      • Unless they went into debt to fund the CapEx, they can move away quickly.
Hardware maintenance fees are typically 15-20% of capital costs.
Whilst Oracle licensing costs are beyond me (I don't track them) - but are becoming a major component of Enterprise Computing costs.

How many "little" DB applications need to succeed with two low-cost ($10k) servers, 3 SATA drives each in simple RAID and 1 Fusion-IO board, run as H/A with an in-memory DB?

If organisations can build a complete, high-performance, high-availability, simple-admin solution for $20-$30k per group of DB's, they can afford to deploy them immediately based on direct maintenance savings.


Follow-up comment:
Intel are looking over their shoulder at becoming dinosaurs. Maybe I won't live to see it, but ARM servers could very well do in the x86_64.
Ed
And so they should for most general purpose computing.

I remember seeing John Mashey of MIPS talk in 1988 where he plotted CPU speed for each of ECL, bipolar and CMOS technologies. ECL had been overtaken by then, bipolar was due to lose the lead within a few years.
The 486 in 1991 was a complete system-on-a-chip and changed the landscape.

It answers the question "Where did all the supercomputers go?"
A: Inside Intel. [and Power and SPARC. possibly Z series]

The Intel chips seek "maximum performance" - they pull all the tricks that super-computer designs used, and its is that technology that is approaching Pattersons' "Brick Wall" [heat, memory, ILP]

And as an aside, GPU's are filling the "vector processor" niche of CDC and Cray.

ARM has pursued a very different strategy, more based around 'efficiency': MIPS/Watt

So, while I agree with you, I think the situation is nuanced.

ARM processors are obvious choices for low-power and mobile/battery devices.
Because of design simplicity (small PSU, no CPU-fan) and smaller size, they'll become more interesting for low-end PC's, especially portable devices.

There is a company, Calxeda, now producing high-density ARM boards for servers.
They are hoping to leverage MIPS/Watt for highly-parallelisable loads, like web-servers.

But I can't see anyone taking on Intel soon in the supercomputer-on-a-chip market.
It's not just servers, especially for large DB's, but workstations and 'performance' laptops.

The problem with that evolution of the market for Intel is ARM taking sales from multiple market segments. Seeing that Winders-8 will run on ARM, we might see the end of WinTel for low-end & mid-tier laptops.

As a company, can Intel survive such a radical change in demand for its major product line?
Will its work on MLC flash fill the financial void?

I've no idea how that will go.
But like you said, ARM is going to shake up even the Intel server market.

The "secret sauce" that the ARM architecture has is that it's a licensed design.
Although chip design companies might not own or be able to access chip FABs within 2 or 3 design cycles of Intel, they can produce highly optimised and use-case targeted chips.

Which Intel can't do. They are focussed on the bleeding edge of CPU performance and FAB design.

Manufacturers like Apple/A5 and Calxeda can produced ARM-based designs that can outperform Intel-based systems by an order-of-magnitude on non-MIPs metrics.

As Apple has shown, there are very big markets where raw MIPs isn't the "figure of merit" in designs.

2011/11/30

Apple needs to invent 'The Brick': screenless high-performance CPU, Graphics and Storage

Two new things appeared in my world recently:
Wilcox wonders what will happen to "Power Users" if Apple move on Desktops, as they've moved on from the rack-mount X-serve line. Customers needing servers now have the choice of a Mac Mini Server or a "Mac Pro" (tower).

Can Apple afford to cut-adrift and ignore the needs of good folk who rely on their product for their business/livelihood, some of whom may have used Macs for 20+ years?? Would seem a Bad Idea to alienate such core and influential users.

Clearly Apple look to the future, and like the floppy drive they expunged long ago in favour of Optical drives (now also obsolete), Desktops as we know them are disappearing from mainstream appeal and usefulness.

I think there are two markets that Apple needs to consider:
  • One they haven't won yet: Corporate Desktops, and
  • One that's been part of their core business for decades: High-end Graphics/Media
Thunderbolt on laptops means big, even dual, monitors are simple for Corporate Desktops, addressing a large part of the demand/needs. While Apple retain the Mac Mini line, they have a viable PC Desktop replacement for those organisations that like the "modular PC" model, especially those that don't want laptops walking out the door.

The simplicity and elegance of Just One Plug of the iMac makes it unbeatable in certain niche applications, such as public use PC's in Libraries or battery workstations in call centres.

Can Apple produce a "power" laptop with the processing, graphics and storage size/performance that meets the needs of High-end Media folk?
A: No, never. Because the fastest, most-powerful CPU's, GPU's, most RAM and largest/fastest storage only ever come with high-power and big footprint: you need a big box with a big power supply: The definition of a Desktop or Workstation.

One solution would be to licence OS/X to "tier 1" PC vendors like Dell or HP  for use on certified systems. But that's not going to happen, Apple is a hardware/manufacturing company - they will never go there.

Hence "the Brick" that is mainly accessed via "Remote Desktop".
My suggestions are a modular design, not dissimilar to the NGEN's expandable 'slices':
  • CPU's and RAM in a housing with capacity to gang together for scale-up.
  • GPU's in a PCI-slot chassis, with Thunderbolt available for physical displays.
  • Local storage via e-SATA, SAS or Thunderbolt.
  • remote bulk storage over the network
  • External power-supply, or part of a base-unit (CPU, RAM, PCI-slot, network, Thunderbolt).
The point of "the Brick" is ComputePower-on-Demand and Universal-Workspace-View, not unlike SUN's 1993 "Starfire video" prototype.
It can live in a (locked) cupboard, or many can be hosted on a server cluster as one of many Virtual Machines. For even a modest operation, high-power servers running VMware makes operational and economic sense. VM's mean another licensing deal. Perhaps VMware, part of EMC, might have the clout to do a deal like this with Apple. Or not.

Jim Gray authored a paper in 2004, "TerraServer Bricks" as an alternative architecture. The concept is not new/original and more than the usual low-power appliances.



An aside on "Jump Desktop", it uses well established (and secure) remote desktop protocols (RDP, VNC). But for Unix/Linux users interested in security and control, this is important:
Jump also supports SSH tunneling for RDP and VNC connections which also adds a layer of encryption but this must be configured manually.


2011/11/06

The importance of Design Rules

This started with an aside in "Crypto", Stephen Levy (2000), about Rivest's first attempt at creating an RSA Crypto chip failing because whilst the design worked perfectly on the simulator, it didn't work when fabricated.
[p134] Alderman blames the failure on their overreliance on Carver Mead's publications...
Carver Mead and Lynn Conway at CalTech revolutionised VLSI design and production around 1980, publishing "Introduction to VLSI System Design" and providing access to fabrication lines for students and academics. This has been widely written about:
e.g. in "The Power of Modularity", a short piece on the birth of the microchip from Longview Institute, and a 2007 Computerworld piece on the importance of Mead and Conway's work.

David A. Patterson wrote of a further, related, effect in Scientific American, September 1995, p63, "Microprocessors in 2020"

Every 18 months microprocessors double in speed. Within 25 years, one computer will be as powerful as all those in Silicon Valley today

Most recently, microprocessors have become more powerful, thanks to a change in the design approach.
Following the lead of researchers at universities and laboratories across the U.S., commercial chip designers now take a quantitative approach to computer architecture.
Careful experiments precede hardware development, and engineers use sensible metrics to judge their success.
Computer companies acted in concert to adopt this design strategy during the 1980s, and as a result, the rate of improvement in microprocessor technology has risen from 35 percent a year only a decade ago to its current high of approximately 55 percent a year, or almost 4 percent each month.
Processors are now three times faster than had been predicted in the early 1980s;
it is as if our wish was granted, and we now have machines from the year 2000.
Copyright 1995 Scientific American, Inc.
The important points are:
  • These acts, capturing expert knowledge in formal Design Rules, were intentional and deliberate.
  • These rules weren't an arbitrary collection just thrown together, they were a three-part approach, 1) the dimensionless scalable design rules, 2) the partitioning of tasks and 3) system integration and testing activities.
  • The impact, through a compounding rate effect, has been immense e.g. through Moore's Law doubling time, bringing CPU improvements forward 20 years.
  • The Design Rules have become embedded in software design and simulation tools, allowing new silicon devices to be designed much faster, with more complexity and with orders fewer errors and faults.
  • It's a very successful model that's been replicated in other areas of I.T.
So I'm wondering why vendors don't push this model in other areas?
Does it not work, not scale or is not considered 'useful' or 'necessary'?

There are some tools that contain embedded expert knowledge, e.g. for server storage configuration. But they are tightly tied to particular vendors and product families.

Update 13-Nov-2011: What makes/defines a Design Rule (DR)?

Design Rules fall in the middle ground between  "Rules-of-Thumb" used in Art/Craft of Practice and  the authoritative, abstract models/equations of Science.

They define the middle ground  of Engineering:
 more formal than R-o-T's but more general and directly applicable than the theories models and equations of pure Science, suitable for creating and costing Engineering designs.

This "The Design Rule for I.T./Computing" approach is modelled after the VLSI technique used for many decades, but is not a slavish derivation of it.

Every well understood field of Engineering has one definitive/authoritative "XXX Engineering Handbook" publication that covers all the sub-fields/specialities, recites all the formal Knowledge, Equations, Models, Relationships and Techniques, provides Case Studies, Tutorials, necessary Tables/Charts and worked examples. Plus basic material of ancillary, related or supporting fields.

The object of these "Engineering Handbooks" is that any capable, competent, certified Engineer in a field can rely on its material to solve problems, projects or designs that come their way. They have a reference they can rely upon for their field.

Quantifying specific costs and materials/constraints comes from vendor/product specifications and contracts or price lists. These numbers are used for the detailed calculations and pricing using the techniques/models/equations given in The Engineering Handbook.

A collection  of "Design Rules for I.T. and Computing" may serve the same need.

What are the requirements of a DR?:
  • Explicitly list aspects covered and not covered by the DR:
     eg. Persistent Data Storage vs Permanent Archival Storage
  • Constraints and Limits of the DR:
    What's the largest, smallest or complex system applicable.
  • Complete: all Engineering factors named and quantified.
  • Inputs and Outputs: Power, Heat, Air/Water, ...
  • Scalable: How to scale the DR up and down.
  • Accounting costs: Whole of Life, CapEx and Opex models.
  • Environmental Requirements: 
  • Availability and Serviceability:
  • Contamination/Pollution: Production, Supply and Operation.
  • Waste generation and disposal.
  • Consumables, Maintenance, Operation and Administration
  • Training, Staffing, User education.
  • Deployment, Installation/Cutover, Removal/Replacement.
  • Compatibility with systems, components and people.
  • Optimisable in multiple dimensions.  Covers all the aspects traded off in Engineering decisions:
    • Cost: per unit, 'specific metric' (eg $$/Gb),
    • Speed/Performance:  how it's defined, measured, reported and compared.
    • 'Space' (Speed and 'Space' in the sense of Algorithmn trade-off)
    • Size, Weight, and other Physical characteristics
    • 'Quality' (of design and execution, not the simplistic "fault/error rate")
    • Product compliance to specification, repeatability of 'performance'. (manufacturing defects, variance, problems, ...)
    • Usability
    • Safety/Security
    • Reliability/Recovery
  • other factors will be needed to achieve a model/rule that is:
     {Correct, Consistent, Complete, Canonical (ie min size)}

2010/08/29

Datacentre Hardware organisation

Related posts:
Senior Google staffers wrote The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines, which I thought showed break-through thinking.

The importance of this piece is it wasn't theoretical, but a report of What Works in practice, particularly at 'scale'.

Anything that Google, one of the star performers of the Internet Revolution, does differently is worthy of close examination.  What do they know that the rest of us don't get?

While the book is an extra-ordinary blueprint, I couldn't but help asking a few questions:
  • Why do they stick with generic-design 1RU servers when they buy enough for custom designs?
  • How could 19-inch racks, designed for mechanical telephone exchanges a century ago, still be a good, let alone best, packaging choice when you build Wharehouse sized datacentres?
  • Telecommunications sites use DC power and batteries. Why take AC, convert to DC, back to AC, distribute AC to every server with inefficient, over-dimensioned power-supplies?
Part of the management problem with datacentres is minimising input costs whilst maximising 'performance' (throughput and latency).