| Dave Hitz's Blog |
A big part of my job is listening to smart people who know about storage, digesting what they say and reflecting on it, and then turning that into my own opinion. Then when I share my thoughts, they get distributed randomly to whoever I happen to be talking to. So why am I doing a blog? I figured that if I'm going to be having ideas and sharing them, I might as well collect them in one place.
- Recent
- Popular
- Tags (0)
- Subscribers (4)
- Disk Is The New Tape—Flash Is The New DiskNovember 7
-
Almost every measure of computer performance increases exponentially. Here is one important exception: disk drives keep getting bigger, but they are not getting much faster. As a result, the number of seeks-per-second available for each gigabyte of data (seeks/second/GB) is plummeting.
Let me give a concrete example. Fifteen years ago, a typical one-gigabyte disk drive had a seek time of ten-milliseconds or so. Do that math, and that’s 100 seeks-per-second for that one gigabyte. Today, one-terabyte drives have maybe five-millisecond seek time. Do the math, and that’s 200 seeks-per-second for the whole terabyte, or just 0.2 seeks/second per gigabyte. Over the past fifteen years, your ability to access the data you own has gone down by a factor of 500.
That’s bad enough, but if you consider how many CPU instructions you can execute while you wait for the disk drive, things are even worse. Fifteen years ago, the Intel 486DX could do 54 MIPS (million instructions per second). Today Intel’s QX9770 can do 59,455 MIPS. For every millisecond you wait, today’s chips execute 1000 times more instructions.
Consider these facts together: From a human perspective, seeks/second/GB has gone down by a factor of a five-hundred, but from the CPU’s perspective, it is five-hundred-thousand times slower! Remember those ol
- Lawsuits and FootballNovember 7
-
I don’t intend to blog on every little step in the Sun/NetApp lawsuit, but a ruling this week really supports the point that I made in my last blog entry: pre-trial rulings aren’t usually a good way to judge the final outcome of a case.
Mike Dillon, Sun’s general counsel, posted a couple of blogs (here and here), which implied that Sun was winning because the patent office issued preliminary rejections on a handful of NetApp's sixteen different patents in the case. Sun requested that we delay until the patent office had a chance to do a final review.
In this week's ruling, the judge denied Sun’s request, noting that the patent office “almost always grants initial rejections” so “the Court gets only limited guidance” from these rejections. Waiting for the patent office makes no sense because software patents like this “take longer than other groups to result in a final action” and “it is unclear at best whether the PTO will keep pace with the increase in reexamination requests.”
My point is not to prove who is winning or losing. Quite the opposite: My poin
- Current Status of the Sun/NetApp Patent LawsuitOctober 26
-
I hadn’t planned to blog any more on the Sun/NetApp patent litigation, but Mike Dillon, Sun’s General Counsel, has recently made some very optimistic posts (here and here), and I need to respond. Dillon shared the results of some pre-trial wrangling—Markman hearings and preliminary Patent Office decisions—but sometimes when you focus on intricate details, you miss the big picture. (For background on the lawsuit, see here, here, and here.)
To me, the best indicator of strength is to look at which party wants to get on with the case (the one with a strong position), and which party consistently drags its feet and tries to delay (the one with the weak position).
Sun is requesting a “stay,” which is a request to put our claims on hold and delay the trial, because the Patent Office has issued a preliminary rejection of claims in 3 of our patents (out of 16). Such a ruling is not unusual for patents being tried for the first time, and there are two ways to resolve the issue. Waiting for the Patent Office, which is what Sun wants to do, is the slow way. The patent office currently has a
- Lessons from the Last CrashOctober 4
-
In the past two weeks, I've had lots of people ask me how I think the financial meltdown will affect things. I don't have a crystal ball, but I thought it might be interesting to look back to the tech crash in 2000/2001.
I remember one of our executive staff meetings in particular, where it became clear how bad things were getting. One of the topics of the meeting was how sales were going, and Rob Salmon, who ran world-wide sales at the time, described an ugly picture. We were still winning deals, at least according to the lower level decision makers, but when it came time to collect the purchase order, we would find out that the CFO, or even the CEO, had frozen the funds at the last minute. It wasn't that anyone else was taking the business: the business was simply disappearing, or at least being delayed.
The executive staff meeting continued, and an hour or so later we had a status update on a big business software project that we were working on. I can't remember exactly what it was—ERP or CRM or something like that. Anyway, about twenty minutes into the conversation, Dan, our CEO, interrupted and said, "I don't think it makes sense to do this right now. It's just too expensive, and given the economic situation, too risky." The IT people giving the presentation said, "But it’s been approved. We already committed to our vendor!" Dan's response was, "It's not too late to cancel." That was that.
From the other side o
- VCs Don’t Like Small InvestmentsAugust 23
-
When we were first starting NetApp, back in 1992, we thought that we could create a product and a company on an unusually small amount of money. We also thought our low cost would give us an advantage in trying to raise Venture Capital (VC) money. We were half right.
It took us just over a year from when we incorporated to ship product, and we had raised only $1.6 million dollars. To put that in context, some start-ups have raised over $100 million to enter the storage market and still not gone public. We shipped our first product with just eight full time employees and only three full time development engineers. The eight were a CEO, head of sales (the only sales person), head of marketing (the only marketing person), head of customer support (the only support person), an office manager, and three engineers including both James and me. We also had three part-time consultants—one on manufacturing and two more engineers.
We were right about building a product with surprisingly little cash, but we were wrong in thinking that VCs would find this attractive. VCs don’t particularly like small investments. In fact, we had to raise that first $1.6 million entirely through “angel investors”—rich individuals who invest their own money. The VCs wouldn’t invest until aft
