Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!hplabs!pyramid!athertn!ericb
From: ericb@athertn.Atherton.COM (Eric Black)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Possibilities for speeding/expanding standard floppies
Summary: Redundancy ain't free
Message-ID: <222@mango.athertn.Atherton.COM>
Date: 14 Sep 88 02:13:54 GMT
References: <5565@pasteur.Berkeley.EDU> <67830@sun.uucp> <2618@sugar.uu.net>
Reply-To: ericb@mango.UUCP (Eric Black)
Organization: Atherton Technology, Sunnyvale, CA
Lines: 102

In article <2618@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes:
>In article <67830@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes:
>> increases performance if you really think about it, and B) What sort
>> of "recovery" is there from a screwed sector?
>
>At least other sectors on the track should be readable.
>
But as I understand it, the trackdisk.device crams 880K onto the floppy
by not having inter-record gaps separating the (logical) sectors.
In other words, there *are* no physical sectors.  What's more, to reduce
latency in writing to the disk, the same logical sector of data isn't
always laid down in the same spot relative to the index mark (i.e., relative
to the rotation of the disk).

In case of a data error on the track, the trackdisk device could give
you the entire track's worth of data with the warning that some or all
of it is bogus.  An appropriately smart scavenger program can go through
all those bits and try to identify the start of logical sectors, but it's
not easy.  Often the best (sometimes the only) way to do this is to
eyeball it and let the user's brain try to recognize data and go backwards
to find what looks like a data block header.  Not so hot for arbitrary
binary data.

Here's a useless but maybe helpful analogy (-:
   I have a byte-addressed memory, 8 bits per byte.  The hardware is
   such that the bits in the byte are only accessed together as a
   single chunk.  Now it happens that these 8 bits are actually stored
   in a circular shift register of, say, 17 bits.  This shift register is
   constantly circulating, the bits are just spinning around and around and
   around ...  The hardware stores 8 data bits into this byte by injecting
   the data bits at any arbitrary point, without having to wait for any
   special point to pass before it begins, along with a special bit pattern
   in the other bits which tells it where the 8 "real" data bits begin.
   The only way to tell which of the 17 bits are the real 8
   data bits is by grabbing all 17 and looking for that special pattern
   it put into the 9 non-data bits (call it a "marker").  Now, if alpha
   particles (or magnets?) blow away a few of the bits in there, the
   hardware can't find its marker, and can't tell where the 8 data bits
   are.

   Now, that overhead of 9 bits for every 8 "real" bits is kind of steep.
   We can change that by changing the size of the chunk that the hardware
   handles at one time.  For a given chunk size, there is a needed number
   of overhead bits.  If we chunk in multiples of 8 "real" bits, and
   we know where the first set of 8 starts because of the marker, then
   we save that marker overhead for each of the remaining sets of 8 bits
   in the chunk -- each starts right after the one preceding it.


What we have here is another example of a trade-off and an engineering
decision which weighed many factors in choosing this point along that
curve.  We have more data on the disk than in formatting schemes which
physically separate sectors.  Many sector-encoding methods include the
track/sector address in a header for each sector which is not visible to
anybody but the controller.  This takes space away from user data but
gives the ability to recover undamaged sectors from a damaged track.
I assume that the decision made at Amiga for the trackdisk was that
the media was reliable enough that the additional space on each disk
was worth the risk.  They could have put extra ECC bits to correct errors,
but that would take even more space.

You might flame that an inappropriate choice of trade-off balance was
made, but I haven't heard people saying that, only flaming.

Now, if 1.3 allows easy use of different devices (drivers) on different
floppy units (as I think Andy/Dave/Somebody said a few days ago), then
some enterprising programmer can come up with an alternative for the
trackdisk.device which does physically separate the sectors, does put
track/sector info on each, maybe even puts extra ECC bits out there
for recovery.  Performance will be different -- and that's performance
as measured in average throughput, burst throughput, sustained throughput,
latency, recoverability, vulnerability, storage capacity, and so on.
Lots of things to trade off.

My personal opinion is that for a home machine, for a game machine, or
even a casual use business machine, a reasonable design decision was made.
Growing availability of hard disks, with a whole new bag of tradeoffs and
design decisions, and overall higher reliability, will make much of this
moot for non-casual Amiga users (by that I mean business users and
serious home users, even serious game-only users).

I have had floppies bite the dust on me, probably a total of 25-30 in
the past 3 years of Amiga use, but I Cover My Ass and don't lose much
if it happens.  And I hate floppy flipping, so I appreciate the extra
space on each disk that the current encoding method gives me.  Even with
four floppy drives on my A1000, and two with a hard disk on my A2000.

It all boils down to redundancy.  Inter-record gaps between sectors
are redundant if you know where the sectors begin.  Track/sector id's
are redundant if you know where you are on the disk.  Data block header
id's are redundant if you know what file you are in.  Or what directory
you are in.  Checksums and CRCs and ECC bits are redundant if you know
what your bits REALLY are.

It all costs you.  You gotta decide how much you are willing to pay.  And
that decision is based on a whole lotta factors.

-- 
Eric Black	"Garbage in, Gospel out"
Atherton Technology, 1333 Bordeaux Dr., Sunnyvale, CA, 94089
   UUCP:	{sun,decwrl,hpda,pyramid}!athertn!ericb
   Domainist:	ericb@Atherton.COM