From: Folkert Rienstra on
"J. Clarke" <jclarke.usenet(a)snet.net.invalid> wrote in message news:d3q82c01159(a)news1.newsguy.com
> Peter wrote:
> > > Carlos Moreno wrote:
> > > > Rod Speed wrote:
> > > >
> > > > > > so I was hoping that you could throw some arguments to support your
> > > > > > "fraid not" argument.
> > > > >
> > > > > The most obvious problem with his claim is that
> > > > > SCSI parallel does better than SATA speed wise.
> > > >
> > > > This is certainly a good argument. But then again, perhaps
> > > > an equally relevant question would be: "all else being
> > > > equal, is serial simpler and/or potentially faster than parallel?"
> > >
> > > Why is that relevant to the issue of the reasons for adoption of the
> > > SATA standard?
> > >
> > > We are not talking about abstractions here but about a specific
> > > implementation.
> > >
> > > > I guess there would be a considerable level of difficulty
> > > > in finding a sensible definition for "all else equal"...
> > > > Obviously, all else IS NOT equal as soon as we say that
> > > > we compare SATA with Parallel ATA...
> > > >
> > > > My comment goes along these lines: while reading some
> > > > semi-technical literature on SATA, they claim that the
> > > > parallel technique, both for IDE and for SCSI, are about
> > > > to hit a "performance ceiling"...
> > >
> > > This may or may not be the case. If it is, it is going to be a problem for
> > > SCSI, which supports 15 devices on a bus and for which faster devices are
> > > available, long before it becomes a problem for ATA, which, even before
> > > SATA, only supported 2 devices on a bus.
> >
> > SCSI has already extended to Fiber Channel, now going SAS.
>
> SO WHAT? What do you percieve that that has to do with SATA?

Does the term 'Serial' ring a bell?

>
> > > > They talk about various issues that sounded moderately convincing to me
> > >
> > > This is called, politely, "bafflegab" or less politely "burying 'em in
> > > bullshit". Until they produce numbers all they are doing is waving their
> > > arms and jumping up and down and hoping that someone will believe them.
> > >
> > > > -- who otherwise had always followed the "common sense"
> > > > notion that parallel *by definition* has to be potentially
> > > > faster than serial -- all else being equal, that is.
> > > > I mean, take 8 SATA cables and send them all to the
> > > > same hard drive -- it has to be 8 times faster, isn't
> > > > it? The embedded sync as part of the data can be used
> > > > to counter the alleged difficulty with parallel interfaces
> > > > that all the bits do not necessarily arrive at the very
> > > > exact moment. For that matter, send 8 or 16 fiber-optic
> > > > wires of the exact same length and there you go, EM-free
> > > > you-name-the-speed parallel connection.
> > >
> > > In point of fact this is exactly how so-called "PCI Express" is implemented.
> > > It is serial only in the sense that the multiple data paths do not share
> > > a single timing pulse.
> >
> > Oh short lived PCI-X.
>
> I'm sorry, but that statement makes no sense at all.

Actually it does. PCI-X never really caught on.
PCIe on the other hand appears to catch on almost immediately, replacing
AGP also.

> PCI-X is parallel in the purely conventional sense and has been around
> for a long time

But hardly ever used except for the very latest high-end SCSI and SATA.

> and appears likely to remain around for a long time, as even Intel, which is
> pushing PCI Express, nonetheless uses PCI-X internally in their chipset and
> also on their purpose-made server board. However, PCI EXPRESS, which is
> NOT REPEAT NOT PCI-X, uses up to 16 "lanes" to get its performance, so is
> it serial or is it parallel?
>
> > > > I was just hoping to hear some convincing arguments in
> > > > favor of the parallel interface (well, or arguments
> > > > in disagreement with the notion that serial can be
> > > > potentially faster than parallel in this context).
> > >
> > > To some extent it depends on how you define "parallel". Is PCI Express x16,
> > > with 16 data lines, each independently clocked, serial or parallel? A
> > > poing is reached where timing does become an issue with parallel
> > > architectures. The crosstalk etc arguments are clearly bogus as
> > > demonstrated by PCI Express, which with multiple data lanes is going to
> > > be no more free of crosstalk than any conventional parallel
> > > implementation.
> >
> > So on reassembly of multiple (serialy propagated) data lines there is no signal
> > skew between them? How come?
>
> Each line is independently clocked.

So obviously there's skew.

> If you want the details ask Intel.
>
> > Crosstalk was greatly reduced by a special signal coding technigue to
> > reduce noise generation.
>
> Oh? What is this "special coding technique" and where is it documented?

SERDES and 8B/10B data encoding.

>
> > But the biggest change is in the concept. Less hard wired signals, more
> > virtual wires which deliver information not by direct electrical state but by
> > content of data passed through them. Message Signaled Interrupt is an
> > example.
> >
> > All of those techiques called for a new standard(s). But serial communication
> > is the real engine in all of them (PCI Express, SAS, SATA).
>
> Fine, believe what you want to.

> Since you don't seem to know the difference between PCI-X and PCI Express

Oh?
Where exactly did he 'seemingly' display that? It's you who obviously doesn't
understand PCIe.
All you appear doing is desperate arm waving and jumping up and down hoping
that someone will believe you over him.

> and seem to think that high end extensions of SCSI have some relevance
> to the ability of a parallel architecture to deliver SATA performance,

Whatever that gibberjabber is supposed to mean.
If anything, that is what you appear to think.

> which the parallel SCSI architecture clearly does,

> it's clear to me that any further attempt at discussion with you is pointless.

Have to agree there but obviously for other reasons.
From: Joe Doe on
In article <1113031800.092249.202410(a)g14g2000cwa.googlegroups.com>,
"a.h." <ahsharif(a)gmail.com> wrote:

> What technical differences are between SATA and ATA?


On Anandtech's review of dual core processors he pointed out that NCQ
which SATA supports has a strong impact on multitasking tests:

See:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2389&p=8

for Seagate's take on NCQ:

http://www.seagate.com/products/interface/sata/benchmark.html


I certainly would like to surf wile compressing video in the background
among other tasks. If NCQ and SATA offer an advantage in this scenario
I would consider it a big enough incentive for me to want to migrate to
SATA drives with NCQ support.

Roland