Re: proposal to fix ordering problem in PCI 2.1

[David B Gustavson <dbg@SCIzzL.com>]

This is a really lovely example, well documented and suitable for use in
textbooks, that should be framed and hung on the wall by every system
designer, showing the fundamental and subtle difficulties that are often
generated by the marketing department's selling an architecture into
applications beyond its designed capabilities.

Unfortunately, we're all so used to occasional crashes that few people pay
much attention. (As Dole keeps saying, "Where's the outrage??")

Also unfortunately, problems like this apparently _increase_ market
penetration, because they generate multiple niches for expert consultants,
who naturally encourage naive users to use the technology from which they
make their living.

It's very like the software industry--if you sell a bug-free program, you
only sell one copy to each user (neglecting piracy effects here), after
which you have to invent a new great product to keep your company alive.
But if you sell slightly buggy programs, you can sell update after update
after update, which will keep your company going with little or no
invention for an indefinite period.


I do find it hard to believe people are really doing this consciously; on
the other hand, I've often watched apparently intelligent people work
really hard to glue ugly gargoyles onto clean simple designs. Maybe it _is_
a valid career or market strategy. Maybe that _is_ at least a subconscious
motivator.

One would hope that _engineers_ would follow a rational path, and avoid
problems like these by exploring the corner cases up front, but that seems
not to be the way the world works.

Anyway, my congratulations to Corella et al. for a nice solution, which was
presented with every effort to make it psychologically acceptable; and, my
condolences in advance of its probable rejection.

(I'm sensitive to the PCI problems because a lot of people want to
interconnect systems that have PCI, by bridging PCI to SCI, which is a
simple clean fast architecture that's relatively insensitive to distance.
Unfortunately, even though SCI bridges are simple and SCI protocols don't
have bridge deadlock or ordering hazards (bridges and switches and rings
were designed in from the beginning and the corner cases were explored
_before_ freezing the architecture), there's no way to avoid the PCI
problems when you connect to PCI systems--in general, one gets the lowest
common denominator of the performance characteristics when interconnecting
different systems. Sigh.)

David Gustavson
(IEC/ANSI/IEEE std SCI chair)


At 2:00 PM -0800 10/25/96, Francisco Corella wrote:
>Hello,
>
>We would like to sollicit comments on the proposal included below to
>modify the PCI protocol in order to fix a problem related to
>transaction ordering.
>
>The motivation for the proposal is purely technical.  Basically, we
>found what we believe to be a reasonable solution to the problem
>described in Section 3.11, Item 6, of the PCI 2.1 Specification, and
>we would like to propose it as a way of making the protocol more
>robust.  HP will submit the proposal to the SIG, but in the meantime
>we would appreciate getting feedback from this reflector.
>
>The proposal has a very long section entitled "Detailed Description of
>the Problem" that lists scenarios where things can go wrong due to the
>ordering problem.  The reason for this is that there is disagreement
>as to the severity of the problem.  The purpose of the scenarios is to
>show that the problem is likely to manifest itself.  However, the
>scenarios are rather theoretical.  We would appreciate hearing more
>concrete ones---or hearing arguments that support the contrary opinion
>that it won't manifest itself.
>
>By the way, we think the Delayed Transaction mechanism introduced in
>the 2.1 protocol, and the Producer-Consumer model that goes with it,
>are very elegant.  The intention of this proposal is not to attack or
>put down the protocol.  On the contrary, we want to make it more
>robust, so that the Producer-Consumer model is guaranteed to work in
>all cases.
>
>Francisco Corella
>Hewlett-Packard Company
>
>------------------------ here is the proposal ------------------------
....

--David B. Gustavson            phone 415/961-0305 fax 415/961-3530
IEEE CS/MMSC Microprocessor Standards Committee chairman
Exec. Director, SCIzzL: Assoc. SCI Local-Area MultiProcessor Users
1946 Fallen Leaf Lane, Los Altos, CA 94024-7206 dbg@SCIzzL.com
For more info on SCI etc., see the Web: <http://www.SCIzzL.com>

��
�