[Gllug] re: SCSI vs SATA

[Andy Farnsworth]

-----Original Message-----
From: Richard Jones
Sent: Wednesday, June 09, 2004 11:00 AM
To: Greater London Linux Users Group
Subject: Re: [Gllug] re: SCSI vs SATA

<snip>

In very very hand-waving terms, if you have lots of wires, you need to
make sure the signals arrive simultaneously at the other end of the
cable.  If they might not arrive at the same time, then you need long
setup and hold times at the receiving end, and that slows you down.

Of course the real benefit is cost: to run parallel cables at any speed
you actually need a separate return path for each wire => huge
inflexible expensive cables.  Serial can get away with 2 (?) wires at a
much much lower cost.

Rich.

-----End Original Message-----

Rich,
  In it's simplest form, serial needs only one wire.  However, this is
never used in practice as the way a signal is read is that the voltage
is compared to "ground".  Ground is theoretically zero volts, however in
reality it often has a voltage associated with it.  This is why serial
uses two wires, one for signal, one for ground so that both ends of the
communication has the same "common ground" to compare the signal line to
determine if it is a one or a zero.  With two wires, only one end can
send while the other listens and then vice versa, this is called half
duplex.  For full duplex or bidirectional communications at the same
time, you require a minimum of three wires.  One for send, one for
receive, and one for the common ground.  In reality, four wires are used
instead, transmit, transmit ground, receive, and receive ground though
often the two grounds wires are connected together at some point, though
not usually in the cable.

  SATA uses four wires but if you compare that to Parallel ATA which
uses 40 or 80 wires you still see a  cost savings.  Also, with only one
wire used for transmit (ok, plus the ground) there is no syncronization
issues.  In theory, if you have 10 transmit lines and 10 receive lines
(with associated grounds -> hmm... 40 wires sounds familiar :-) then you
would have 10 times the throughput possible, however, in reality the
time it takes to syncronize the signals from these lines causes the
whole system to slow down so much that just pushing data as fast as you
can down a single line is faster, hence Serial is faster than Parallel.

  This whole issue of serial faster than parallel comes down to the fact
that we now have the ability to signal at such a high frequency (i.e.
billions of times per second) that having to wait for even 1/1,000,000
of a second means that you are better off running serial than parallel
by at lest two if not three orders of magnitude.  Take ethernet for
example, 100 Mbit means that you are signalling at least 100,000,000
times per second and that you have if you have to wait that 1/1,000,000
of a second you have just lost 100 bits, so to keep up you have to have
more parallel lines to cover that 100 bits which increases the wait time
from 1/1,000,000 of a second to 1/900,000 of a second which means you
need more lines to cover that loss, which increases the time to wait ...
Ad infinitum.  The faster we signal, the less margin for error/delay we
have and the more any error or delay affects us.

Math lesson for the day:

Speed of light in a vacuum (not a hoover, a vacuum)
	300,000,000,000 milimeters / second

Speed of today's fastest processors (for this lesson, pretent that
faster = More cycles per second)
	3,400,000,000 cycles / second

(300,000,000,000 mm/s)/ (3,400,000,000 c/s) =
88.235294117647058823529411764706 milimeters / cycle

Therefore, if the distance the signal has to travel is more than 88.235
mm, the process will take longer than one cycle of the processor. That
is a little over 3.5 inches and shrinks each and every time the clock
speed increases.


Andy

P.S. I have never seen any of my posts appear on this list, are they
getting through?



-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug