Skip to content

DanHugo.com

Sections
Personal tools
You are here: Home » Stories » Silicon Valley Era » Working Silicon Valley » Chapter 10 - Motive Power
advertisement
 

Chapter 10 - Motive Power

Small companies are better than big companies. Small companies might also be better than smaller companies.

My time at Philips was educational, to say the least.  I traveled to a few countries to meet with various people from various places, I worked within the infrastructure of a too-large company that itself was a bit out of place in silly valley, and I began to realize that maybe silicon valley wasn't for me.

I decided to leave Philips in February 2000 and consulted back to the same group for a few weeks to close out what I had been working on.  This was an interesting little short-course, since the Director of Engineering was slowly going insane (in my opinion, and I am not a mental health professional) and he made it less-than-fun to close out that part of my time there.  But I did it and got a little extra bread in my pocket for my troubles.

At the same time, Deniz Teoman was pushing forward with a tiny startup effort he called Motive Power, funded by former Umax characters and supported by him with hardware expertise and his friend, John Neal, on software.  For any early PowerMac fans, John is the author of SoftwareFPU, which implemented 68881 functions on the PowerPC 601 used in those first machines. Why Apple didn't do this themselves is beyond me, but they did allow him to do it as an outside project while he worked there, which was pretty cool anyway.

So Deniz and John had developed a PCI card that would accept PC100/133 SDRAM dimms (I want to say 16 of them, maybe 12, can't recall exactly at the moment) and would act as a battery-backed disk block cache in Windows2000.  John had implemented all of the bits to have the OS place this cache device into the file system pathways so it just worked.  The demo was pretty neat, and enabled a rather impressive amount of acceleration as most caches do... once they have something in them.

Kevin Imamura and I were drawn in to this project mostly because we knew and liked Deniz from Umax, and because it seemed like they had done something pretty interesting.  They had some something interesting, in fact, so we were pretty stoked to be able to work on it at that early stage.  Right around that time, they were approaching a particular company in silly valley to see if they would want to license the technology behind this cache setup.

Allow me to step out for a moment and describe the scenario without being overly specific. The company in question was a manufacturer of high-performance storage interface devices, mostly SCSI.  They made their money by selling storage systems that were very fast and/or highly-reliable via various RAID levels.  Coupled with 10,000 RPM drives in an array, their offerings were reasonably reliable, reasonably fast, and reasonably expensive.

The demo [the code name for all of this was Amanda] was two desktop PCs next to each other, one with Amanda installed and one without.  Both computers would be powered-up simultaneously, and then items in the Starup Items folder on each machine would get launched and opened and whatnot.  The non-Amanda machine would lag behind the Amanda machine my a substantial margin, and one could see in the CPU usage monitor that the non-Amanda machine was spending a lot of time going out to disk to swap.  You could hear the drive activity and see the drive light blinking away.  To the casual user, this is a faster, quieter PC sitting on my desktop, and that's peachy.

To someone who makes their shareholders happy by selling RAID cards and multi-drive setups, this would not appear to be a great thing intially.  My theory-- as I told Deniz one day while we were sitting in my dining room-- was that someone who just spent a whole bunch of money on expensive RAID controllers and drives would not be so excited to learn that all of that might not be absolutely necessary (I'll touch on that more in a moment), so it seemed to me that the company selling that stuff might not be so excited about pushing add-on cache devices that compete against their offerings.

The subtlty here was that the demo was aimed at a desktop configuration, while RAID and SCSI drives in general were not aimed at the typical desktop user (not even Mac users, eventually).  RAID and SCSI would be aimed at server-side configurations and maybe folks in workstation mode working with multimedia editting or other storage-intensive stuff (CAD, large-scale software development, etc).  My suggestion, then, was to offer a configuration of the Amanda system that would not make the drives quiet, but which would make the drives work up to their capactiy by always keeping the cache in a written-out, relevant state.

We came up with two modes of operation.  Re-active caching, where the cache would see block accesses and cache them, and Pro-active cachine, where we would attempt to cache blocks before they were needed.  The two simple ways to do this were to cache whole files (useful if large files were being mapped into memory anyway) rather than just blocks, and guess which additional files to cache before they were needed.

So Kevin and I set out to try these ideas out.  I ported over some of John's code to work on my linux machine, so I had an Amanda cache in my linux test box (which was pretty cool, actually) and some software hackage to watch the launching of executables and the opening of files.  I had a little daemon running that would get these notifications and then read files in to the cache (rather than blocks).  Right around the same time, the RAID company in question made it clear that Linux was not interesting to them...

Thus, Kevin and I teamed up on his Win2K efforts.  He came up with a service that would do something similar, capturing executable launches and file operations, and which would gather statistics on all of this.  Eventually, we had the thing running so that launching Word, for example, would open the last N documents, ordered by frequency of use or something along those lines.  Basically, our proactive caching scheme had reached the point of being "interesting."

Silicon Valley hardware businesses were having a tough time by now.  It was the summer of 2000, there were some funding issues with this little venture, and there was (from my perspective) some focus issues on the business side of things.  I felt that putting all of the few remaining eggs into the basket of thie RAID company was a bad idea.

As the end of 2000 and the end of my contractual relationship with this effort were drawing to a close, it was becoming clear that the RAID company was not going to be stepping up (in fact, the person who was driving the effort to work with Amanda within the company ended up retiring or leaving, and his successor was not nearly so keen on the idea), so in November I found something else to work on, which will be the subject of yet another chapter in this long and winding tale.

In the end, Deniz and John were awarded two patents (no mention of Dan or even Kevin...) and I'm pretty sure that the software got rolled up into a ball and placed on a shelf somewhere (which I also disagreed with... a company in Morgan Hill had just started manufacturing a similar hardware device and was pitching it as a plain old ram disk... the cachine stuff was more interesting, but needed work).

In the end, my relationship with Deniz was strained, and that is unfortunate.  For the record, Deniz is about as brilliant a hardware engineer as I've ever met anywhere anytime, and he suffers from the same engineer's optimism that I do.  Neither of us are ideally suited for the business side of technology, though both of us would like to think we are.  Hmmm.

Created by danhugo
Last modified 2005-02-17 01:42 AM
Blog
Recent additions:
No blog entries are published.
« February 2006 »
Su Mo Tu We Th Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28        
 
 

Powered by Plone

This site conforms to the following standards: