** This is the quasi-official and semi-temporary T13 email list server. **
These are good questions...
> Dal,
>
> You seem to be indicating that these committees are political processes
> instead of committees presiding over technical issues on this bus.
>
> Shouldn't technical issues be decided by the facts? And when someone who
> knows presents a technical fact shouldn't it be evaluated as such instead of
> someone making a decision that is based on something else? And shouldn't
> this have been done from the start? And isn't that why T13 is still sorting
> out these issues? And why should someone have "to come to a meeting"? Have
> you an others not been willing to decide issues on the facts?
I'd like to agree with you that technical facts rule the day but standards
committees are political processes which are definitely influenced by the
facts. Facts are not always the arbiter because opinions on facts vary: what
one person believes is a minor item can be a major hurdle for another.
One example of the dilemma in dealing with facts is the time at which a
committee becomes aware of them. If discovery arrives after a committee has
acted and printed a standard it is impossible to undo the implementations
shipped to the field. It then becomes a political issue of whether the
problem is easier to live with, or the next standard has to change and
introduce a backwards compatibility problem.
You now have conflicting facts which have to be dealt with.
Two wrongs do not make a right, so the B&W of a fact can turn into shades of
gray all too quickly. The committees constantly walk a line, and when there
are differences in opinion they are usually decided in favor of those who
have the political muscle in the committee.
The SFF Committee has operated as a complement to the standards process, and
rules like the majority of one were incorporated to prevent political muscle
winning the day. Being technically accurate is the underlying objective, as
one engineer can confound a whole room full of politicians.
The primary reason this thread started is that I wanted to clarify the time
frames so that Hale would stop blaming SFF for ignoring him, and redirect
his ire to the correct place.
Hale campaigned hard in T13 during 1996 to correct problems in ATAPI and had
virtually no success despite bringing up many valid and accurate concerns to
the committee. I've got pages of coverage on Hale's quest, and during that
period was very familiar with the varying constituencies. I covered every
one of the meetings during the 1990's, and have extensive history to fall
back on with newsletters that ran 60-80 pages/month.
It was not the SFF Committee which Hale dealt at length with on the issues
of sharing the same cable with hard disks.
ATAPI SFF-8020 Rev 1.4 is what manufacturers built the first production
level ATAPI CDs to, and that came out early in 1994.
The first year of ATAPI shipments put ATAPI CDs on a separate connector
otherwise users suffered abysmal performance. When the CD did a seek the
disk drive was locked out, and CDs were incredibly slow devices.
During 1994, the X3T10 ATA working group had been dealing with proposals for
command queueing and command overlap. Most members were opposed, as disk
drives would have to implement a capability to help ATAPI vendors.
Overlap allowed ATA and ATAPI devices to share the same cable because the
disk drive could be operating while the CD was off seeking.
At the risk of boring you further, here is an extract from the ENDL Letter
coverage of the X3T13 ATA Meeting held on January 23-25 1996.
In spite of the fondest dreams of IDE/ATA purists, ATAPI hasn't
failed where it counts most...in the marketplace. By any measure,
ATAPI has been wildly successful. Estimates of 1995 CD-ROM
shipments are pushing around 40 million units, 95% of which were
ATAPI devices......
Though all of this is clearly a success story, the standards
committee folks are worried.
So far, ATA and ATAPI devices have been largely independent of each
other because the ATA protocol only permits one operation at a
time. Think of it as being similar to two vehicles driving alone on
the same highway at differ rent times, it doesn't matter if the
drivers' interpretations of the traffic rules vary.
Command Overlap is going to change that. Suddenly its rush hour and
vehicles are sharing the road. To stretch the analogy a bit
further, basics like the speed limit are understood by everyone but
some of the minor rules are not quite clear.
Does a yellow traffic light mean STOP or SPEED UP so you don't have
to stop?
No doubt you have wrestled with this interpretation and undoubtedly
wound up disagreeing with the officer who observed your decision.
The results of loose interpretations on the ATA bus won't be fender
benders; they will be configuration failures, bus hangs, and data
corruption. The job of the standards committee is to make sure the
rules are clear and universal so that won't happen.
At this point you might ask, 'So what?', that responsibility has
always been the basic charter of standards bodies. The `so what'
is that each of these three uses of the ATA interface already has
its own book of rules.
+--------------+----------------------------------------+
| IDE/ATA Disk | ATA-2 and ATA-3 |
| ATAPI CD-ROM | SFF-8020 Rev 1.2 and SFF-8020i Rev 2.5 |
| ATAPI Tape | QIC-157 |
+--------------+----------------------------------------+
There are products built according to each of the books, and those
products don't always do exactly the same thing when they see a
'yellow'. At present the players are just warming up and making
'harrumphing' noises but you can expect some serious discussion to
start later in February.
Matters actually became more convoluted later in the year. SFF-8070 was
formed to work on removable media because T13 only wanted to deal with hard
disks and that did not include the super floppy. SFF-8090 was started to
cover CD-RW because the companes wanted to include implementation content
which X3T10 was opposed to having in a standard.
SFF-8020 Rev 1.4 in 1994 had problems which did not break the surface
because the ATA vendors that could have identified them were hoping ATAPI
would disappear, and had not participated.
The combination of poor implementations and inaccurate content caused
compatibility problems which should have disappeared with later revisions
but SFF-8020 turned into an Information specification controlled by X3T10
and they were never corrected.
INF-8020 was frozen in January 1996 and should have been buried in 1997 by
a standard addressing the problems, but Microsoft and OEM RFPs cited it as
the requirements for CD operation. This complicated and compounded all the
problems which Hale and others have tried to correct, and gave it a longer
life that it deserved.
- I share the technical opinion of INF-8020.
- I disagree that SFF ignored attempts to correct 8020, because
efforts to correct the deficiencies did not start until AFTER
control had moved from SFF to the standards committees.
When I wrote in January 1996 that "The results of loose interpretations on
the ATA bus won't be fender benders; they will be configuration failures,
bus hangs, and data corruption. The job of the standards committee is to
make sure the rules are clear and universal so that won't happen", I had no
idea that the situation would drag on as long as it has.
Dal
--
If you have any questions or wish to unsubscribe send a
message to Hale Landis, [EMAIL PROTECTED] To post to
this list server send your message to [EMAIL PROTECTED]
For questions concerning Thistle Grove Industries or TGI's
list services please send email to [EMAIL PROTECTED]
