Posts

Showing posts with the label high-performance

Why Fibre Channel SAN's will be dead in 5 years.

I won't be buying shares in any Fibre Channel-based tech stocks as I think the technology will be dead within 5 years for two reasons: Enterprise Storage Arrays will stop being used for high-intensity random I/O, instead being used for "seek and stream", and PCI Flash or SCM Storage will become the low-latency "Tier 0" Storage of choice because of speed (latency), cost and simplicity. Update 1-Feb-2012: Another article by Fusion-io, Getting the most out of flash storage   provides extra links: Flash storage moves closer to CPUs : STEC is moving into PCI Flash cards. EMC: Flash could spell doom for Fibre Channel but don't talk about PCI Flash challenges. Flash storage in post-PC devices advances , general background on Flash memory. Elsewhere I've written Jim Gray's observation, "Disk is the new Tape" should be "Disk is the new CD". That is, Enterprise Storage is best suited for "Seek and Stream", not random I/O. Enterp...

How they got to 1 Billion IO per second.

Is Fusion-io's demonstration of "1 Billion IO operations per second" the same sort of game-changer that the 1987/8 RAID paper by Patterson, Katz and Gibson was? Within 5 years all "Single Large Expensive Disks" (SLED's) were out of production, will we see Flash disks in Storage Arrays and low-latency SAN's out-of-production by 2017? A more interesting "real world" demo by Fusion-io in early 2012 was loading MS-SQL in 16 virtual machines running Windows 2008 under VMware . They achieved a 2.8-fold improvement in throughput with a possible (unstated) 5-10 fold access-time improvement. Updated 16:00, 31-Jan-2012 . A little more interpretation of the demo descriptions and detailed PCI bus analysis. Fusion used a total of 64 cards in 8 servers running against a "custom load generator", or 16 million IO/sec per card. There are two immediate problems: How did they get the IO results off the servers? Presumably ethernet and TCP IP. [ No, in...

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

Two new things appeared in my world recently: A friend showed me Google 'Jump Desktop' , connecting his iPad to his Desktop. [Apple have their own 'Remote Desktop' product which I haven't researched. Not sure if it works over the wider Internet as well.] Joe Wilcox's piece (Jan-2011) on Apple dumping desktops sometime (soon) as they become less relevant. 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), Des...

Everything Old is New Again: Cray's CPU design

I found myself writing, during a commentary on the evolution of SSD's in servers , that  large-slow-memory like Seymour Cray used (not cache), would affect the design of Operating Systems. The new scheduling paradigm: Allocate a thread to a core, let it run until it finishes and waits for (network) input, or it needs to read/write to the network. This leads into how Seymour Cray dealt with Multi-Processing, he used multi-level CPU's: There were Application processors, many bits, many complex features like Floating Point and other fancy stuff, but had no kernel mode features or access to protected regions of hardware or memory, and Peripheral Processors (PP's), really a single very simple, very high-speed processor, multiplexed to look like 10 small, slower processors that performed all kernel functions and controlled the operation of the Application Processors (AP's) Not only did this organisation result in very fast systems (Cray's designs were the fastest in t...

Climbing out of the Ooze, or is that GNUze?

I've written on Microsoft heading for financial trouble and mounting internet security problems - but they have an underlying cause. Both ignore the hard-won Unix principle: Less is More . [the joke behind the pager, 'less'] This isn't just some arbitrary style choice, it's rooted deep in Computer Science and Software Engineering: smaller, cleaner interfaces - many fewer bugs if bugs/LOC is static (errors = LOC squared ) smaller code - potentially better understandability the Einstein principle: As simple as possible, but no simpler . Controlling system entropy - smaller code, less entropy to grow. Learning curve for new maintainers is lower - "cognitive span" of individuals not exceeded Learning curve for programmers lower and risk of errors of misunderstanding lower. More is Worse in Software Engineering - in every technical dimension. Microsoft has gone on to demonstrate that it is possible to have excessive 'customer features'. But this isn...

Teams - Where's the proof?

Addition 24-May-2007 Johanna Rotham author and consultant answered an e-mail from me. Johanna is involved in the Jerry Weinberg and Friends AYE - Amplifying Your Effectiveness - conference. Johanna's book "Behind Closed Doors" is on this blog and highly recommended for I.T. Technical Managers. Another interest of Johanna's: Hiring the Best People . Johanna's thoughtful response: Part of the problem is I can't do two of the same project where one is set up as an integrated team and the other is a bunch of people who don't have integrated deliverables. I can tell you that the projects where the people are set up with committed handoffs to each other (Lewis' idea that one person can't work without the rest of them), have better project throughput (more projects per time period) than the groups of people who do not have committed handoffs to each other. But that's empirical evidence, not academic research. Here's a real request I sent to a ...