Xref: utzoo comp.sys.ibm.pc:15573 comp.sys.misc:1424
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!iuvax!bobmon
From: bobmon@iuvax.cs.indiana.edu (RAMontante)
Newsgroups: comp.sys.ibm.pc,comp.sys.misc
Subject: Re: RLL Technical Details (long)
Summary: Some nitty-gritty boring details about ST-238's
Message-ID: <8769@iuvax.cs.indiana.edu>
Date: 15 May 88 17:15:56 GMT
Reply-To: bobmon@iuvax.UUCP (RAMontante)
Organization: Computer Science Dept., Indiana University
Lines: 27

This is a vote of appreciation for articles like this.  Pete Hol(which is this?
sman or zberg?) posted a question about the appropriateness of such a thing;
I feel it is far more appropriate than most of what we see on the net.  More
detail, not less; we can always stop reading as soon as the snow has gotten
deep enough.

And sure enough -- I looked all through the product specification for my ST-238,
and there's nary a word about "window margins".  Considering that it specifies
neato stuff like:
	Recording Density	14,740 BPI
	Flux Density		 9,827 FCI
and required timings for buffering your seek pulses (100nsec min. between
DIRECTION IN and the first step pulse, don't change this in BASICA :-), that
window margin must be a sensitive number.

Incidentally, I've seen a TI Business Pro document; it does give that parameter
along with many others.  Probably because they know their machine is too
nonstandard for most third-party mfr's to want to get involved anyway.

Something else you're surely dying to know:  when Seagate says 65ms average
maximum seek time, that's for a 205-track (1/3 stroke) seek, average of an
inward seek and an outward seek, using buffered seek pulses.  The full stroke,
innermost to outermost, is 150ms max.  Track-to-track is 20ms max.  One seek
error per million seeks; one recoverable read error per 10 billion bits read,
one NONrecoverable read error per trillion bits...

So make sure you press your salesman closely on these specs!