On June 26, Brad Spencer wrote:
>    Oh, come now.  What's wrong with the PCI bus?  It's vastly faster, and in 
>    many ways saner, than SBus.  And they've latched onto cheap, insanely 

  You mean the scaled-up versions of PCI are faster than sbus.  If
memory serves, original PCI is about the same speed as sbus, except in
certain situation where sbus is faster...in particular, the setup for
a transfer happens concurrently with the end of the previous transfer,
so data transfers can happen on every clock instead of wasting a bunch
of arbitration cycles in between.

  While I'm definitely a big fan of PCI, I think that Sun's move
(while not entirely bad) wasn't without its price.  Sure, sbus cards
are more expensive than cheap commodity PC parts.  But when I go to
sleep and put my pager on my nightstand, I'd rather not have cheap
commodity PC parts in the computer room, if you know what I mean.

  Call me weird, but there's just something that bothers me about using
the same ethernet card in your eight-year-old kid's disposable game PC
as in a $100K+ system in a multimillion dollar data center.

>    functionaly video cards and cheap hard drives for workstations (not for 
>    servers, of course). 

  "Cheaper" doesn't always mean "better".  The bus is nice, I will
agree...but the quality of manufacturing and the reliability of the
vast majority of PCI cards leaves a LOT to be desired.

>    Personally, I think Sun is spot on.  There's something to be said for 
>    economies of scale. 

  While I do agree, I don't think it was without a significant
downside...

> I don't know if this is still there, but when Sun first came out with the
> PCI based sparcs, there was a "warning", of sorts, on their own web page.
> If I recall properly, it stated that the buss speed would be about the
> same, even though the PCI buss is faster.  Something to do with interrupt
> latency, or some such.

  As I mentioned above, though I don't have the details, this has
something to do with overlapping arbitration and setup cycles with
data transfer cycles.  This reportedly allows real non-bus-overhead
data to be transferred on each cycle, with one transfer beginning at
the very end of the previous transfer with no intervening crud.

          -Dave McGuire