A bedtime story :)

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.

Comments (17)

  1. Anonymous says:

    Totally random? HAL will be jealous…

  2. Anonymous says:

    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…

  3. Anonymous says:

    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.

  4. michkap says:

    Mommy? Daddy is scaring me with his bedtime stories!

  5. Anonymous says:

    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?

  6. 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.

  7. Anonymous says:

    Can you tell what year was it? Just curious, if I was born by that time.

  8. Anonymous says:

    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.

  9. Anonymous says:

    What does "Longhorn reset" mean?

  10. Anonymous says:

    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.

  11. Anonymous says:

    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.


  12. Anonymous says:

    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…

  13. 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.

  14. Anonymous says:

    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.

  15. Anonymous says:

    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.

  16. Anonymous says:

    Hi Norman.

    Your right. However, in the early PC environment, the distinguishment between Tracks and Cylinders (at least in the general software field) was not very disciplined. In the benchmark quoted (software), note that it says “Track to Track Seek Time” – emphasis on the Seek. Head to Head Switching time (track to track as your suggesting) was rarely ever quoted, much less tested. I mean I can’t think of an easy way to derive a stable, let alone moderately accurate result, given the capabilities of the hardware. The benchmark has to explicitly request a sector, in which case (as you’ve mentioned), sector interleave will play an ugly role.

    As for average seek, I recall that it was popular to perform this over one third of the disk surface. Ie 640Cyls / 3 = ~213 Cyls (if memory serves, the ST4038 has 733 Cyls, 5 Hds). As a metric, that is over simplifying things. Eg When the heads need to seek over larger distances, the timings/voltages are not a sum of a single (Cylinder) seek, it’s less (optimised). Indeed you could hear the differences, as the distances increased.

    Sorry to hijack your thread, Larry…

  17. Anonymous says:

    Tuesday, October 03, 2006 12:01 AM by RichardRudek
    > However, in the early PC environment, the distinguishment
    > between Tracks and Cylinders (at least in the general
    > software field) was not very disciplined.

    Um, aside from “general software field” I understand what you’re saying. While the general software field was still dedicated to goals like making Y2K into a problem (due more to management than to programmers of course), the PC software field was dedicated to creating other future monsters. An inability to distinguish tracks from cylinders isn’t a monster and I didn’t even know it played a role on PC software development, but anyway, thank you for the reminder ^_^

    By the way I remember head crashes on IBM disk drives too, which were half the size of a washing machine and didn’t hold anywhere near 733 cylinders, but had more than 5 heads. In those days people tended to believe the manufacturers’ specs on cylinder-to-cylinder seek and track-to-track seek etc. (well at least children tended to believe them ^_^) Anyway the important thing was that keeping things in the same cylinder tended to keep things faster.

Skip to main content