Hierarchical State Machines

Dropped by Miro Samek's talk "Hierarchical State Machines: a Fundamentally Important Way of Software Design" at PARC last week, and still thinking about it. While the title is a bit over-the-top, some of the ideas such as a "quantum language" fit quite nicely in an RTOS. Of course, it's architecture, architecture, architecture.

Mr. Samek himself sees the "framework" as applicable to many areas, such as real-time embedded systems, GUIs, or networking servers. He also is working on a realtime preemptive kernel which he says he will release soon. Why? As he put it himself "Obviously, what I'm doing is cottage-industry, but that's all I can do alone." Sounds like a good enough reason - just to try and see if it flies. That's what exploration is all about.

Remember when "design" meant "reliable"

Dennis Rockstroh of ActionLine in the Merc attempted to handle the frustration of a Sony Vaio user recently. Turns out the poor man continually had the power just blit out on him while working on his laptop. Back and forth to the factory it went, never seeming to get any better. Dennis helped the gentleman get a replacement laptop from the factory, but no one seemed to understand why such a problem was occurring and why it required a complete replacement to rectify. Sony didn't wish to discuss it, and the frustrated user couldn't figure it out other than noticing that wiggling the power connector sometimes worked.

How do I know this? Because I bought a Vaio PCG-FX-310 for my husband a few years back, and soon after acquiring it, the power connector began to fail. But since I've been putting together systems since the days of Symmetric Computer Systems, plus all that work on 386BSD and X86 systems from lunchboxes to desktops to laptops, we didn't just sit around griping about the problem - we tried to figure out exactly why this happens - both as a good little example of the importance of design in a consumer product, and as an illustration of the difference between American and Japanese audiences.

So we did the obvious - we took the laptop apart. And we found out why the factory sent back a different laptop - it turns out that this flaw cannot be repaired. It is basic to the design.

I have a Vaio Z-505 in a titanium case, and it has a very sturdy connector mechanism for the power. But in the later designs, to save costs, Sony left out the anchoring plastic on the edge of the previously all-metal case, so the connector has all of it's mechanical force transferred to the soldered-on printed circuit board connections, which are less than 1/10th of an inch of solid metal (not stranded wire). If you took a 10 gauge solid copper wire (which in effect it is) and bent it back and forth, you would only have to flex it 20 or 30 times before it broke.

In ordinary use, the laptop gets flexed more times than this in a day. So it is no wonder this is the weak spot in the design.

It is the same connector as the Z-505, by the way, as we can switch power connectors between them. The difference is that one is an example of well-engineered design (the Z-505), and the other (the PCG-FX-310) is an example of poorly engineered design. So Sony can do a good job, and they are fully aware of this problem. It couldn't possibly have been unexpected.

On the Z-505 the connector is on the side and a plastic insert holds it into position so it cannot flex as much. In addition, the connector is attached more securely to the printed circuit board, and the force is not directly on the metal to printed circuit board point, so it lasts much longer. I'm writing on one now. The Z-505 was a premium subcompact laptop. The FX-310 is an economy model, and apparently they took far less care.

How could this design have been improved to avoid this problem? Either they needed to make the connection to the printed circuit board more flexible, or they needed to restrict the connector by taking the force in the bezel that surrounds the connector. But this wasn't done.

So anyone who has one of these laptops is in trouble. It would take a complete redesign. It is a fundamental flaw.

"OK" you may ask, "I've got one of these laptops, and I can't seem to get it repaired but I need to use it - what do you do?" Well, I wouldn't recommend this and don't try this at home but you can either 1) rebuild it and fix the problem until the next time it flexes and breaks and then rebuild it again, or 2) use a heavy object like a disc drive to wedge the power connector in place - but it is still very tricky for the latter case. Sometimes we just have to take it apart, resolder, and put it back together. Since my husband uses it for his presentations, he just can't take the time to send it off to Sony's repair center (in Fremont, by the way) only to be told it's fixed when we know it can't be fixed - only cudgeled back together, as happened with ActionLine's upset customer.

I'm back to looking at the IBM Thinkpads again for business purposes, but the BIOS issues are annoying. Perhaps a technical column on the hazards of commodity products? Other than this issue, the Vaio is quite efficient - and I like Sony's fine graphics capability.

It's ridiculous that Sony should lose customer good faith because of a 2 cent part. But that's why you do quality control.

Now what would a Japanese customer expect from Sony? A Japanese executive my husband knows did manage to break a Z-505 (he dropped it) and it did require repair. So you can break a Z-505. But once the repair was completed, the computer worked perfectly. This demonstrates that design, not indeosyncratic "lemons", is the key here.

No Japanese customer would have tolerated this problem in the FX-310 - only Americans would. And Sony would never sell such to a Japanese audience - it would be unacceptable, as would the 3 times repair that Dennis's poor customer endured.

Where's the Simplicity in Web Services?

Martin LaMonica wrote an interesting piece in Cnet lamenting the lack of "simplicity" in web services today. According to the article "Tim Bray, co-inventor of XML and director of Web technologies at Sun Microsystems, said recently that Web services standards have become 'bloated, opaque and insanely complex.'". I think Bray is being far too kind.

One the the criticisms we had with the Unix operating system kernel (BSD or System V - it didn't matter which) while creating 386BSD was the continual problem of managing a "bloated kernel" into which everyone wanted to throw their special cool thing whether it belonged there or not. When we introduced modularity in 386BSD Release 1.0 however, the reduction in complexity was not easily visualized by traditional kernel programmers used to a monolithic design, and also relegating them to a piece of the pie instead of the entire pie seemed to a few more vocal critics as "demeaning". Web services is facing the same bias, only this time from companies anxious to have their particular widget inscribed in the annals of orthodoxy even if they are so odd that they actually belong as a special case module.

So where's the simplicity in web services? We'll get it when we get out of low-level design and understand the architecture better (see William F. Jolitz's article Web Services and DataCenter Environments in the April 2003 edition of Dr. Dobbs Journal article for more information). The key is architecture in design first. This is the only way you get reliability, scalability, and security from the get-go.

Unlike kernel design, web services don't even have an established user base yet, while people have made use of ad hoc Internet solutions using databases, scripts, and HTML / XML successfully. So perhaps, like OSI could not displace TCP/IP, web services will also "eat themselves into the grave" before they ever achieve acceptance.

The Problems of Personalization

For those who would enjoy it, Byte Online presents The Problems of Personalization in the Features columns. Online retailers are crowding onto the "personalization" bandwagon—with humorous and occasionally insulting results. Join me as I talk about Amazon, Wine.com, and others as they attempt to solve The Problems of Personalization.

A Wandering through the Vintage Computer Faire

The Vintage Computer Faire was held last weekend at the Computer History Museum in Mountain View last weekend. Sellam Ismail, VCF Coordinator and vintage computer collector, was kind enough to send me a couple of passes. Unlike the cozy NASA-Ames location of several years ago, the Vintage Computer Faire, typically home of games, small computers like the Amiga, and the like, has begun to nicely complement the "Big Brothers" collection of DEC, IBM, and other gargantuans in the museum's permanent collection. What better place to talk about the good old days but in a place surrounded by a VCF buff's beloved machines.

Last year we did a presentation at VCF 2003 entitled Before 386BSD: The Symmetric 375 & Berkeley Unix (see the mention in Talk About Legacy Machines). Symmetric Computer Systems, a venture-funded company founded in 1982 by William Jolitz, was a contender in the hot race to produce a personal BSD Unix system. The Symmetric 375 was the first system out the door with hardware floating point and virtual memory, beating Sun by years. It was the first system with open source supplied, integrated, and tested, from EMACS to SPICE for use in scientific and engineering work. And it was the first to ship systems with all software fully installed and tested, ready for use immediately. William and Lynne Jolitz discussed the design and development of the 375 computer and its influence on 386BSD - the first open source BSD system for the X86 released a decade later. That was a fun talk!

The year before that, when the VCF was still at NASA-Ames, we put together a poster entitled Symmetric Computer Systems - The Story of a Systems Startup. And that was a lot of fun, let me tell you. Ever try to get an all-wirewrap handcrafted system running? We did...

We displayed the operational all-wirewrap (20,000 connections, 25x22 inch bd) Proto I computer (in the case) from 1983. I also had the original notebooks for Proto, including the wiring key. Proto I had an Atassi 40 MB drive with the 1984 BSD OS running a 16032 chipset - I took off the cover so that everyone could see it. I demonstrated that it worked by playing rogue. Rebecca Jolitz got every parent-child quiz question correct, by the way, and mille bourne still works perfectly. Games were used to check system operation, so they were part of the original Proto system.

The photo display included a picture of William with the barely populated wirewrap board, along with the original bizplan cover, funded prospectus, lots of photos of the founders, team and investors, PAD master for the 375 board final rev. I kept the picture big, by the way, so you can see the details.

One of the amusing items is the funding came in, and then $45k immediately went out for a System V license (I attacked the invoices and check stubs). The tape came, and was thrown in the trash. Then a $750 check was sent to the Regents of the University of California, so we could use BSD. It didn't have anything really to do with System V, but you had to "pay to play" then, so you really had to have a funded company. We also paid $10k for a GENIX license for the port by the team William led at National Semi prior (Project Mesa) to bootstrap the system faster on the 16032. SCS got a significant percentage of available venture funding for the effort. Built the boards. Used the WD ST-506 controller card - basis of IDE follow-on. Totally portable.

Also had a final production unit - ran fine, showed a 4.3BSD SYMMETRIX system. Had a Miniscribe (remember them?) 85MB drive. 8MB board (1Mbit DRAMS). SCSI tape. Were first in virtual memory, portability, single board microprocessor-based system. Board internal very tightly designed - piggybacked connector enet card on back. That's how we got it small enough to be portable. The heaviest thing was the disk drive/controller bd unit.

The kids helped themselves to the next door Amiga display - looking at them now, Amiga still impresses me for their graphics (look at them) and game playing ability. They played these games the *entire* time. The Amiga guy ended up with lots of traffic (we were next door) because the kids were so enthusiastic people would just come over and watch. Just what gaming should be about.

You know, I've got PC's barely lasting a few years, and Windows software delivering bogus errors due to intentional bit rot so you upgrade. I've got an 20 year old wirewrap and a 17 year old production unit, and they still run great! And BSD Unix looks just the same - same commands, same code, same everything, as current systems (although the X-Windows stuff came a bit later). However, rogue was better then, before they changed "floating Eyes" to "Emus" (come on - who goes and kills emus in dungeons?).

Looking At the Year Ahead

My latest Byte article is now online. In The Year Ahead, I predict 2005 will bring us more spam, less security, and maybe some shake-ups in search—but each of these fields holds opportunity for technical innovation. I hope you enjoy it.

When Marketing Fails, Technology Sails

This column is absolutely right about "clutter" on the Internet inhibiting effectiveness. And Cory Treffiletti is right in stating no one cleans up the "old methods" when introducing new ones. I suppose we all have that problem.

But when marketing fails, technology sails. The success of firefox is 1) security (e.g. block tracking), and 2) no pop ups (no ad clutter). Whenever I deal with a "creative" marketing group that thinks the world is one big contextless contentless commercial, I always see a failure in the making.

As anyone serious in this biz knows, "it's the content, stupid".

I Spy with My Little X-Eye - But I'm Blind, I'm Blind....

Yes, I know. There are so many much more expensive technically incompetent products I could be writing about right now - in operating systems, networking products, switches, routers, you name it. So why would I nominate the PC CHIPs X-EYE PC Camera (USB 1.1) for "worst product of the year"? Perhaps because it was such a great big lie that it could ever work that even if I was given it for nothing it would still cost too much.

First, it claimed to be 100k pixel resolution (352 (h) x288 (v) max resolution, frame rate - 30 fps at CIF (352x288), color 16.8 million true color (24-bit), software - BMP/AVI/ TWAIN). All you need is a pentium (200 MHz), any Windows system / 32MB ram / 12MB disk. All for $15.99! Seems like a too good to be true deal, and it is.

Since I'm always trying to find a way for kids to get into video on the web, I actually check out these little buggers. But this one didn't deliver at all. In fact, it couldn't work because there was no way for it to send the information through the USB through a Microsoft miniport driver at the rate of speed needed to support 30 fps. We found the fastest it could go reliably was a grand four frames per second. It could do an amazing ten frames per second if you completely idled the PC (yes, that meant killing every single program).

So the X-Eye is a complete fraud. It did contain the electronics internally needed to work, but you couldn't get the video off it fast enough to capture on the PC. It was a failure of architecture, and architects know better. The economics dictated it be made dirt cheap, so to keep cheap the software had to execute flawlessly on any configuration on any PC (hardware and software). If you had a slightly slow USB connection, for example, you'd lose it, or if had other USB devices and software on them that used a bit more processor than was available, you'd lose it, and so on. Your odds of success are better in the state lottery. At least SoftRAM (another infamous fraud) didn't annoy you - it just silently didn't work.

The design assumed it could back-to-back send a scan line or more across the USB with no recovery required, the software would accept it at that rate, and the display adaptor would display it at that rate. So we are talking an expectation of perfect hardware, software, and systems architecture in play to work with a fifteen buck device. Anyone seen that in PC economics? At InterProphet, we developed methods to achieve zero packet loss. Anyone think it went into a fifteen buck device?

So caveat emptor, folks. So throw those X-Eyes away (and I don't care how many popup ads you see about them) and buy your daughter or son a Canon A60 instead.

Inside the Black Box or Outside the Flim Flam

Reading the article today There Are No Black Boxes in Online Marketing, I had to laugh when Tom Hespos laments "To me, it seems ridiculous that anyone in this industry would want to put blind faith in a piece of technology without understanding fully why it works". Absolutely! It would be wonderful if marketing and sales really wanted to know how things worked inside the "black box". This would make the bona fide technologist who labored over a real product very happy.

But the reason we have black boxes is simple - the customers don't want to know anything about how it works - they just want it to give them the results they want when they want them.

This desperate willful ignorance on the part of "don't tell me about the technology, just tell me how it works" online marketing crowd is fertile ground for the flim-flam product that spews out worthless "results" in pretty charts. Like what you may ask. Gee, like security that isn't, spam filters that don't, and software "accelerators" that slow the processor - I could go on for hours, and I haven't even hit any hardware yet.

Let's face it - an ordinary sincere technologist doesn't have a chance next to those magical solutions. If she says they don't work, she's told that her competitor has it and it does work. If she argues with her customer, she's blamed for "losing the sale".

So until black box results are tied to an online marketer's performance (and job security), expect more black box solutions and very few honest answers.

Cookies and Popups and Ads, Oh My!

Another marketing lament on how cookies and spyware and popups and intrusive ads are ruining it for the good marketers ends up in my inbox. Why, oh why, they cry can't someone come up with a way to make the Internet a wonderful place for selling, and keep the bad guys from ruining a good thing. Alas. :-)

It's a matter of architecture and trade-offs, courtesy of those techie types no one can understand. Simply put, online marketing people have to give up on magic solutions like cookies and popups and sneaky tracking - they're all easily disintermediated by the same tech folks who programmed them in the first place. Live by the sword, and die by the sword.

To paraphrase a famous campaign slogan, "It's the content, stupid"! Provide good content on the Internet, tailored for your audience, and they will watch it and the relevent ads - just like TV. Rely on tricks, and in "Internet time" someone will put out a way to block you. Amazing thing, the Internet.

Take it from an Internet expert who actually knows the insides of all this stuff - it really is this simple. And it places online marketing back under the control of the online marketing specialist where it belongs.

No, Photoshop is Not "real life", Dave

Dave Pogue today reviews the Bushnell binoculars, and just can't figure out why they're so blurry. So I told him "it's obvious". Here's why for the rest of you...:
1. They didn't bother to adjust the focal plane focus of the sensor to coincide with the same focal point of the binocular eyepiece (e.g. a mfr defect).
2. To confirm this, adjust the binoculars slightly out of focus and take shots - I bet you'll find that it gets better if it is not fixed focus.
3. If it doesn't change at all, that means they have a fixed focus, and that the focus is set wrong. This is not adjustable by the user easily, but if you disassemble the binoculars and adjust the focus manually, you'd correct this problem.

But wait - there's more. I have a long list of errata on digital cameras, most recently the Canon SD200-300 on-camera editing issues, for example, discovered by us at ExecProducer over the course of handling production issues. So I'm quite familiar with these and other annoying issues (light level problems, for example, and resolution issues) and how to find the best way of handling them. So another nit with Dave is a very basic one - using photoshop is not "real life", as anyone in serious astrophotography will tell you.

Precision is expected in using binoculars and digital photography. Even with photoshop the auto levels command often undersaturates. In other words, you can't rely on photoshop to correct the other issues. Too much information is lost. You've got to deal with the problem directly - the focus.

So you might ask, "Why do I know about this stuff and why should it matter"? As to this knowledge - it comes not only from digital production but also from experience in imaging circles in astronomy. For example, anyone could see on this particular photo that you didn't have a pixelation problem, so the rest is obvious - that is, if you take images through a telescope and don't mind taking apart your optics. :-)

It does help that my son Ben won 2nd place at the Synopsys Science and Technology Championship last year with The Perfect Eye: A Study in Collimation, a discussion of collimation techniques using his telescope - he took it apart to defocus and refocus. My daughter plans to begin her science fair career with a discussion of aperture and Dawes limit using a variety of different instruments - she's only 10 but she's demonstrated telescope techniques at Stanford Tech Trek. So it's also a long-standing family interest. Even a child can do it. You can too.

Tom Foremski Interviews Doug Engelbart

Doug Engelbart is a computer legend, but he is also still very much alive and has plenty to say. Tom Foremski of SiliconValleyWatcher had a poignant chat with him. The upshot - have the last 20 years been a failure?

Some snippets from Tom's excellent interview:
" 'How do you deal with society when its paradigm of what is right is so dominant?' Doug Engelbart, the 1960s computer visionary asked me the other evening. It's a question he has pondered many times over the past 20 years or so, ever since his research funding was taken away.

Mr Engelbart and his teams of researchers at the Stanford Research Institute (SRI) shaped the look and feel of the PC, as John Markoff chronicles in his latest book What the Dormouse Said: How the Sixties Counterculture Shaped the Personal Computer Industry.

Mr Markoff's book raises the profile of Mr Engelbart, well known as the inventor of the computer mouse, and less well known for his seminal work in creating many of the concepts later found in the personal computer. Mr Markoff returns credit to where it is due.

What the book does not chronicle is how the rise of the PC killed funding for Mr Engelbart's work.

By 1979, he had lost all funding from SRI because of unfavorable peer review.

'The other research groups said what I was doing could be done better with microcomputers or through machine-based artificial intelligence. That was the dominant culture at the time. What people don't realise is that there are many different cultures and not one is right.' Mr Engelbart told SVW.

As a result of his experiences, he questions whether the past 20 or so years of his life have been a failure.

That's how long Mr Engelbart has been trying to raise funding to continue his research into human machine interfaces and solving large, complex problems using networked software.

But the culture of our time has been unfavorable to his ideas of developing human-centric computer applications using one big powerful computer with many users. The paradigm of the PC revolution is that everyone gets to have a computer, no time-sharing needed."

Misplaced Software Priorities

For a perspective from William Jolitz, co-developer of 386BSD, on the need to separate "innovation" from "renovation" in design, read Misplaced Software Priorities today. While it may gore a few oxen - especially those who work in the architectural flatland of low-level software - given the rapid outsourcing of this very same area to low-cost programmers in India and China, it might be time to listen to an alternative view from a long-time Silicon Valley developer and entrepreneur who's done more for the acceptance of open source than all the pundits put together.

Of course, if someone wants to stay low-level, they can always learn Mandarin, right?

Microsoft's Ultimate Throughput - Change the Compiler, Not the Processor

I like people who go out on a limb to push for some much needed change in the computer biz. Not that I always like the idea itself - but moxie is so rare nowadays that I have to love the messenger despite the message. So here comes Herb Sutter, Microsoft Architect, pushing the need for real concurrency in software. Sequential is dead, and it's time for parallelism. Actually, it's long overdue in the software world.

In the hardware world, we've been rethinking Von Neumann architecture for many years - SiliconTCP from InterProphet, a company I co-founded, uses a non-Von Neumann dataflow architecture (state machines and functional units - not instruction code translated to Verilog because that never works) to bypass the old-styled protocol stack in software, because an instruction based general processor can never be as efficient for streaming protocols like TCP/IP as our method. Don't believe me? Check out Figures 2a-b for a graphic on how much you wait for store and forward instead of doing continuous flow processing - the loss for one packet isn't bad, but do a million and it adds up fast.

It's all about throughput now - and throughput means dataflow in hardware. But what about user-level software applications? How can we get them the performance they need when the processor is reaching speed-of-light limits? If on a typical processor from one end to the other end you get one clock cycle at the speed of light at 7-8 GHz, anyone stuck in sequential processing will be outraced by Moore's Law, multiple cores and specialized architectures like SiliconTCP.

Herb is a great presenter, and does know his stuff. He also looks the MS part - works out and has those grand gestures of the inspirational speaker down pat. But he has a tough role to play - convince software developers to take some responsibility for the performance of their apps. Because, as he puts it, "the free lunch is over". He also sees processors reaching the limit on performance for today's sequential applications, and that the world will be full of non-Von Neumann machines to get performance. The monolithic kernelized systems ranging from Linux to old-style BSD to Windows are at a serious disadvantage here - we do need blocking for exceptions, for example - and even a completely modularized kernel like 386BSD, while a lot more efficient in performance, still waits a bit on processors. But it's the apps in userland that really suffer here (even if we avoid ring crossing), and clustering the apps custom-built means older software vendors won't be competitive - unless they change their tools, their techniques, and even the way they do product and market requirements planning.

Does this impact the server side? Not really - products like SiliconTCP take the weight of parasitic communications overhead off server processors, and since most requests are independent (like a three-tiered client-server transaction) but similar in action, we can use carefully structured data and shared memory resource to always fill up the processing queue in a highly concurrent format. But a client machine is a different beastie - it doesn't usually share copies, and the shared data is "unstructured and promiscious".

Herb sees locking issues as the major bane to concurrency in applications, and I agree. Waiting on locks is a very delicate practice in the OS itself (see Volume 1: The Basic Kernel for a detailed discussion of locks and threads). And he also sees the need to delineate different levels of abstraction based on object oriented concurrency and parallelism. So what's his approach?

This is a big problem, and his answer is small - too small to work, because its too late to do the small idea in an Internet world. He thinks changing the compiler to put in a mechanism for instantiating a lock once, instead of every time is the key, coupled with a mechanism he calls "futures" to hold the guess of what might be the result. The latter isn't much different from Sun's prefetch/precalculate approach for Niagera, with all of its benefits and drawbacks (most importantly, it didn't help enough according to Sun's own stats).

But even these small changes met with stout resistance and objections. Herb is right in saying that once we go parallel in software our simple test cases don't hold - race conditions and lock contention are a real problem in the new world order. But his approach, for all of his strong words, is too little precisely because he doesn't wish to inconvenience the very developers who will live and die by throughput. So the OS will get bigger, vendors won't change their apps in userland to use multiple cores effectively, and the reasons for upgrading expensive software packages will become fewer and fewer.

So what this really is about is the ever widening gap between hardware and software. Since the only way hardware can go faster is multiple cores and non-Von Neumann architectures, they will go that direction. If software developers choose to stay in their sequential programmatic direction, they'll be capped. And maybe, just maybe, hardware designers will extend their offerings more and more into the realm of software. So instead of worrying about C++, maybe it's the beginning of a Verilog world. Wouldn't that be something?

Itanic Readies for Final Sinking - Multiflow and HP Tech Aren't Enough

Alas, "itanic", aka "Itanium" is resurrected again, this time debuted by Intel as a "chip with two brains". But the critics aren't impressed, and to save money for senior management Itanium soirees, Intel middle managers are to be tossed into the cold big blue.

Well, this is no surprise to those chip-watchers who talked down Itanium from the beginning. While Dell and IBM have fled to calmer X86 waters with the likes of AMD, HP has been steadfast, selling 80% of the chips Intel has shipped.

Of course, many wonder why HP is such a firm holdout when everyone else is baling? To understand how we got where we are, we actually have to ask the question "Where did the Itanium come from?" If you think it all sprang fully formed from Andy Grove's head, you're quite wrong. And you'd miss the story of long-ago acquisitions, agreements, and ambitions...

A long time ago, in the go-go 1980's when Symmetric Computer Systems was building the first virtual memory single processor BSD system, there was a company called Multiflow Computers. They asked the very unmusical question "How many functional units can you keep busy doing interesting things on a die?" So they ganged together processors into very large instruction word (VLIW), wrote some patents and papers, and built a very interesting computer.

This question has been asked before, and we can read all about the 1960's era CDC 6600 and "scoreboard" - an attempt to control parallelization overlap in functional units (see John Louie Byers "Computer Systems Architecture", page 166-170). While the CDC 6600 did this with arbitrary functional units, Multiflow Computers examined how many instruction flows (instruction streams) could be kept going at any given time.

This problem arises every decade or so. Sun's recent foray into improving processor throughput is another in a series of projects to parallelize computation in a sequential world. In the 1980's, compiler design was cool, so it's not surprise that Multiflow used compiler technology as the agent for overlapping these functional units in parallel. If the result is overdone (because of dependency), the flow process is backytracked. If the result is underdone, the process is continued until completion. In other words, just branch code to "undo" or "finish doing" the missing pieces. I guess some folks liked it because Intel acquired Multiflow, and it became the basis for much of their innovation in Itanium.

Unlike Multiflow's static compiler approach, Sun is attempting to run a realtime interpreter on a prospector thread. Multiflow's 1989 patents are soon to expire, so we might see Sun try their older approach if Sun manages to last five more years.

Of course, there's more to Itanium than Multiflow. That's where HP comes into the picture. Itanium is also based on the HP PA-RISC implementation (aka the HP 9000 line), which Intel acquired along with HP's patent stucture, designed in competition with Sun and IBM's RISC machines of the time. This partnership merged the HP RISC architecture with Multiflow's smart parallelism of functional units. Intel knew we would eventually need multiple cores, and this seemed the smartest path.

The problem as processor designers see it (then and now) is how do you keep multiple cores appropriately busy? The way we humans write code is in languages that have no concept of parallelism. Our whole way of teaching programming is based on flowcharts worked sequentially. No surprise here - our mindset is sequential! Compilers are good planners of code, but in order to produce parallelized processing from sequentially designed code the compiler must be smarter than humans. And even compilers make mistakes, just like we do, so we have to build in error detection and correction which is effective and has reasonable overhead (in latency and storage).

The Multiflow approach made for a kind of "loose" parallelism because if it guessed wrong it just "backed out" of the problem. This avoided hardwiring into the code how many processors you're using and what they are used for, permitting more dynamic allocation of resource. Multiflow structured the compiler to create code combinations for a varying number of CPUs - a reasonable answer to the problem.

Alas, there is always the human factor, and ambition can serve as a vise as well as a goad. Intel always despised how they empowered their rival AMD and scores of other small vendors and resented the "second source" demands of customers of the 1980's. So this time, they decided to take the entire bet themselves. They locked up the compiler and systems technology under NDA, making it impossible for anyone to make money off of it but Intel. Thus the "itanic" disaster - Intel shouldered all of the multibillion dollar costs of this ambitious project so as to hoard all the profits that never materialized. I don't suppose that any exec at Intel who had dared to voice a concern as to the possible risk got anything more than a pink slip and a bad recommendation. Just another Governer "Evacuate? In our moment of triumph? I think you overestimate their chances" Tarkin moment.

BTW, these and other patents of this time will be expiring soon - Intergraph in particular had a number of legal spats with Intel over infringement, with Intel settling after lots of lawyer games. Intergraph was never an innovator, and these patents actually came from their Fairchild acquisition because they used the Clipper in their workstations - we played with that chip at Symmetric as well and considered it, but backed off completely once Fairchild was sold. After all, would you like to buy chips from one of your competitors?

When Video Kills Your Drive - Quicktime Waxes Track 0

Alright! Yes, sometimes I do read slashdot when it's amusing, and the discussion of how you can create your own custom panic screen (or BSOD window) for OS/X via an API is amusing (my son Ben points this stuff out for me - he feels it's one of his sacred tasks). Joke panic screens have been around a long time, but the battle over "how much information to give people" has led to many not-so-amusing battles, especially when we were creating 386BSD releases and did the Apple approach as an option long before Apple switched to BSD and did the same thing we did. I like information and transparency, but not at the cost of frustrating and annoying lots of people...

But aside from this old debate, probably the funniest *real* programming error discussed (yes Apple, you did it again) was the Quicktime capture bug a video engineer discussed, where it merrily fills up the drive with video and then, when you've run out of space on the disk, overwrites allocated blocks. Yes, allocated blocks! And where did that leave our poor engineer? With no track 0. Even Apple couldn't put that one back together again - they had to give him a replacement drive, and that's a complete admission of defeat, because as everyone knows Apple is very cheap. (Disclaimer - I have worked in manufacturing, and we all are very cheap in this regard because hardware returns make a nasty entry on your income statement - show me a systems vendor that doesn't care about hardware returns, and I'll show you a vendor that won't please shareholders).

But the question begs - is there another way to recover from a track 0 loss on a disk drive? Well, we faced the same problem at Symmetric Computer Systems years ago, and we recovered that disk, albeit not the way you might think...

Back in the dark ages of workstations (circa 1985), before IDE and ATA, disk drives were blitheringly stupid. In our NS32000-based workstations, we used a Western Digital ST506 controller board using a WD1010 chipset. With this chipset and a very stupid drive, we could tell it to start at track 0, or track 1023 or any track in between. Obviously, we started at track 0, and didn't think much of this feature, until one day we had a very unusual situation occur.

One of our very good customers called us because one of their Symmetric 375 computers used for nuclear calculations (yes, they worked the Fortan compiler intensively, and we ended up developing one that they said was better than everybody else's to make them happy - we aimed to please) was always erasing track 0. None of the other systems, and in fact, no other Symmetric 375 computer we ever shipped experienced this problem. But these guys were right - it was losing track of track 0, and that was a big problem - for us and them.

Now maybe you see where I'm heading. We created a special bootstrap ROM that would respond to a track 0 failure by checking the next consecutive track and so on, replicated the contents of the disk, and then once it came
up it would fix itself by reformatting only that portion of the drive. Of course, this had other problems as well - you'd get occasional time skewing, but it got the customer going again.

Why was the drive on this particular computer reformatted all the time? We never were able to independently confirm this, but since this computer was used at one of the National Labs, we suspected it was getting some kind of voltage or magnetic or microwave spike and it just happened to be that the heads were stowed on the first track which contained track 0. No other customer ever experienced this problem, although we did have one customer who unintentionally reformatted their drive and then called us wanting us to recover the information - alas, a low-level reformat doesn't let us do much.

The moral of this story is simple: if you build things "smart" but don't remember the corner cases, you can paint yourself into a corner. That's what happened to the poor QT video engineer, and he paid the price. Good design, like good cooking and good accounting, is a matter of experience, a dash of subtlety, and a good sense of humor.

MetaRAM Busts RAMBUS Stranglehold?

Sand Hill Road envies RAMBUS. Oh, they don't envy them their lawsuits, precarious business model or turbulent management structure. But they do envy them their ruthless monopoly of the high-speed DRAM market. RAMBUS successfully competed against the behemoths with a clever architectural enhancement, kept belief in their approach against huge odds, fought back as hard and dirty as the big boys and made licensing deals stick. They are survivors.

When RAMBUS went IPO back in 1997, I was completing work on the first preliminary patent application for InterProphet's SiliconTCP technology, while William began his hunt for investment. RAMBUS's IPO was on the minds of many VCs, but it wasn't in a good way, surprisingly. RAMBUS's 7 prior years had been fraught with changes in business model and personnel. Instead of setting up a fab, RAMBUS chose to license their technology. Finally, RAMBUS chose to make their stand on the basis of their patents. Don't let me fool you -- investors may crab about the need for "intellectual property protection" but when it comes to playing with the big boys, they believe about as much in IPR as the tooth fairy.

RAMBUS has been remarkably successful in defending and enhancing their patents (and yes, I know about their "steering committee" games -- coming from the OS side I've seen Microsoft and others play the same games, even to the point of doing software patents on work pre-existing by decades). Essentially, they've played dirty like Intel, Hynix and all the other guys the VCs said you could never win against. But it has been a very long wild and crazy ride for the payoff -- too much for the "10x in 3 years" crowd.

But despite all of RAMBUS's remarkable turbulence, it has been amazingly successful. During one incredible record-setting day in 1998, I listened to a top-tier VC say that he'd never want a single share of RAMBUS's stock no matter *how* much money they made. He just hated them. Another top-tier VC rambled on about how "you could make a lot of money with a RAMBUS business model, but they weren't interested in that". What they really hated is how there wasn't a single massive success where they could bow and take their winnings (like VMWARE in 2006 for example, but they didn't invest in that one either because it was run by a husband-wife team that believed open source was valuable -- hmm, beginning to see a pattern). As Magdelena Yesil (at the time partner at USVP) liked to intone to me "Venture Capitalists are more capitalist than venture these days". Chip risk wasn't as exciting when you could respin any company as an Internet venture and go public with no revenue. And semiconductor companies *are* risky.

Semiconductor companies are also the historical lifeblood of Silicon Valley -- hey, that's why it's called "Silicon Valley" and not "Internet Valley"! So now we come to MetaRAM, an attempt to steal RAMBUS's monopoly on architecture. According to Ryan Block of Engadget "MetaRam uses a specialized "MetaSDRAM" chipset that effectively bonds and addresses four cheap 1Gb DRAM chips as one, tricking any machine's memory controller into using it as a 4x capacity DIMM."

Is the technology innovative? Not likely -- it sounds like a combination cache and bank decoder, which is not innovative in the least. In fact, you need 4x the number of components on the DIMM, which means 4x the number of current spikes and decoupling capacitors, even if you put the chips together in the same package. Because you have a fifth chip, you complicate things even more. There is no way you can approach the triple-zero (volume, power, cost) sacred to chip designers with such a design, because one single high-speed high-capacity chip will eventually win out given the proliferation of small expensive gadgets demanding the lowest of volume and power. In a world of gadgets like IPODs, cellphones, laptops, PDAs and the like, cost is very important but *not* the most important quantity. So RAMBUS doesn't have a lot to worry about here.

Hynix has been fighting a losing battle against RAMBUS ever since getting hit with a whopping $306M patent infringement judgment in 2006 (since reduced to $133M), and RAMBUS is still going for more. These are the same guys who pleaded guilty in 2005 to a DOJ memory price-fixing scheme from 1999-2002 and paid a $185M fine. There is no love lost in the memory biz.

So where does little MetaRAM come in. When technology fails, maybe a clever business model will do. MetaRAM's big claim to fame is cost reduction -- not for gadgets or laptops, but according to Fred Weber, CEO of MetaRAM, for "personal supercomputers" and "large databases". And who is the big licensee for this so-called technology. Why, it's Hynix of course, who announced they will make this lumbering memory module. They claim it will be lower power. I think I'd like an independent evaluation on this point, but it will probably be lower cost. Is it worth it? Given reliability considerations, that also remains to be seen. But the moral of this saga is simple -- human memories are longer than memory architectures in this business, and the real puppet-master behind the throne (Kleiner-Perkins) is sure to walk away with the money. I wish I could say the same for the customers.