Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

A bedtime story :)

A bedtime story :)

  • Comments 17

Once upon a time (all the best stories start with "Once upon a time"), there was a computer manufacturer, let's call it by a totally random collection of letters, let's say "JCN".

JCN had a brand new computer that it was producing (called the QD-BU).  One of the really cool things about this computer was that the hard disks on it were HUGE.  Twice the capacity of any PC available at the time.  This machine came with a 20 MEGABYTE hard disk!

Oh, and did I tell you it was FAST?  It was so fast, you could move the heads around on the hard disk in only 10 milliseconds!

JCN was quite proud of their new computer, and they made sure that it was rigorously tested.  They made sure that every component in the computer was of the highest quality, even the hard disks.  It was especially important that the hard disks work well, because with all that disk space, people would store more and more data on the hard disk.

After months and months of testing, JCN decided that their computer was ready to fledge its wings and take flight.  They launched it with MUCH fanfare, and it was very well received.

 

Unfortunately, they realized soon after the launch that there was a problem.  Users started reporting that hard drives in the QD-BU were starting to act "badly".  They would corrupt data seemingly at random.  JCN was NOT happy at hearing this, after all, they had spent a lot of time and money ensuring that the QD-BU would be better than any other computer available.

The problem was that the manufacturer of the hard drives couldn't produce them in quantity.  Their quality suffered when producing drives in quantity.

JCN worked to fix the problem with the manufacturer, and eventually everyone was happy.

 

Of course, JCN tried very hard to learn from the lessons of the QD-BU.  And their key takeaway?  Not that they needed to be careful about which vendor they chose to make their drives.

Instead the lesson they learned was "Fast hard drives break".  So for their next generation of computers (the QT/3), the hard drives were much slower.  They took 85 milliseconds to move the heads, but they were MUCH more reliable than the old QD-BU drives.

 

Of course this is only a bedtime story.  It has no relationship to the real world whatsoever.

  • Totally random? HAL will be jealous...
  • Great story.  In this ficticious world, did the QT/3 did a lot more changes than their QD-BU model?  I'm sure you have a story along the lines of the success or demise of the QT/3 computer...
  • I still remember the QD Magazine cover with an ax through their computer case. After recalling all those drives the supplier used them to create an artificial reef off the coast of Mouse Mouth, Florida, where the JCN's QD division was located.
  • Mommy? Daddy is scaring me with his bedtime stories!
  • Ha ha, nice one Larry. This little parable wouldn't happen to have anything to do with the mythical product of NT WJTUB, would it?
  • Jonathan Rascher, possibly.  The OS division is pretty averse to using managed code after the Longhorn reset.  But I personally don't think that's really all that unreasonable.

    Personally I think we learned the right lessons after Longhorn Alpha.  Time will tell however.
  • Can you tell what year was it? Just curious, if I was born by that time.
  • JCN solved this set of problems by selling their hard drive division to a competitor and selling their QD division to a different competitor.

    At a time when JCN still owned their hard drive division, coincidentally when they had been sued for overstating the quality of drives that held somewhere around 80GB but not for drives holding a mere 4GB, a 3-year-old 4GB JCN drive developed a bad block, which by itself is nothing unusual, but some details matter:  I had backed up my SYSTEM.DAT file.  The backup copy was written with every indication of success.  For some silly reason I tried to make a further backup from the first backup, but the first backup was unreadable because of a bad block.  I made a second and third backup from the original file with no problem.  At that time JCN had a web page where they pretended to take support issues from end users, but they knew I couldn't really be an end user because e-mail addresses that end in .jp weren't real e-mail addresses.  I didn't have an alternative at the time.  Somehow I found a way to submit a metacomplaint but still never heard back from them.  I was really glad that JCN was no longer a monopoly.
  • What does "Longhorn reset" mean?
  • If the lesson was "choose your vendors carefully" that would imply that management made a mistake in choosing vendors so obviously that can't be right.  Plus things like better quality control sound expensive.

    "Fast hard drives break" on the other hand sounds like an engineering problem so that's ok.
  • Mouse Mouth? How appropriate given that my house is a 2 minute walk from what used to be JCN's building.

    I never heard of _THAT_ permutation of the reef story. I used to work at a certain German telecom company that had a mainframe the CT-3111 that purportedly also became part of a reef.

    Amusing.
  • As far bedtime stories go, these babies weighed as much as a knight's horse and we paid the near mythical price of $800 (that's Canadian $$), circa very late 1970ish  ... one can only imagine what a 10 ms would have set us back ... but we were a happy bunch because we didn't know what to do with all that storage...
  • James: In 2004(?) we realized that Vista wouldn't stabilize on the course it was taking, so the decision was made to reset the product and scale back the feature set.
  • I've still got a Working 30MB (ST-4038), which I just connected to 6/8/10/12MHz AT clone, using a clone (Full-Length) controller (WDC-1007 ?).
    Had to initialise the drive (interleave=3), etc, and when tested (at 6MHz) it gave this (CORETEST v2.90):

    Data Transfer rate:           166.7 KB/sec
    Avg Seek Time:                  36.7 ms
    Track-to-Track Seek Time:    9.8 ms

    Ah, I see now. You must be talking about Track to Track Seeks when you say "move the heads around" :)

    PS: An interleave of 2 gives ~247.6 KB/s, but when CPU is set for 12MHz, the performance drops a bit: 239.6 KB/s, 37.6 ms, 9.9 ms. Consistent over 3 or 4 runs, each.
  • Track to track doesn't move the heads around, cylinder to cylinder does. Track to track only requires electronics to switch and stabilize, turning off one head and turning on another. Average seek time includes moving from a cylinder to another cylinder that is an "average" distance away, plus on rare occasions part of the track to track time (if it didn't finish before the heads finished moving), plus waiting for a sector that is an "average" rotational distance away to come around. "Average" now on notebook drives is quoted around 12ms. Desktop and server drives are quoted faster. There are several reasons that these numbers are completely meaningless to end users, and with modern drives these numbers are even meaningless from the viewpoint of the driver. Firmware built into the drive knows what the real cylinder and head and sector numbers are but the OS doesn't know. Firmware relieves the OS of most error correcting logic and scheduling logic, but also makes it hard for improvements in the OS to improve error correcting and scheduling.
Page 1 of 2 (17 items) 12