why is serial faster than parallel?

[Lifer]

common sense says that parallel should be faster. more data flowing thru cables at a time.
now everything is going serial (USB, firewire, SATA).

 

[NokiaDude]

half the wires on parallel cables are for grounding. IRC, only about 20 wires are used, roughly.

 

[Schadenfroh]

not on the drives, they use a PATA to SATA bridge chip, bottleneck, but i guess access time does not exceed 133 ata anyways so i guess you are safe

 

[Zepper]

Assuming the same generation of line driver technology, serial isn't faster - as you suspected. Just less clumsy cabling.
.bh.

 

[ElFenix]

i think what he means is that the interconnects have a higher theoretical throughput than the parallel stuff they're replacing.

 

[labrat25]

as i remember it serial clocks to higher bandwidths than parallel

 

[jjyiz28]

with parallel, more bits are transfered per cycle, but those bits must be synchronized with each other, therefore it can never be as fast as serial can. serial dont care much for syncing when its only 1 bit at a time. therefore serial can pump up the cycle rate really high so it more than makes up for the 1 bit per cycle

 

[boran]

Originally posted by: jjyiz28
with parallel, more bits are transfered per cycle, but those bits must be synchronized with each other, therefore it can never be as fast as serial can. serial dont care much for syncing when its only 1 bit at a time. therefore serial can pump up the cycle rate really high so it more than makes up for the 1 bit per cycle

technology always advances like this:

Serial -> lotsa serial in parallel -> faster serial -> lotsa serial in parallel

because you can yank up the clock easier, and then someone thinks, hey what if we combine two of these serial connections then it'll go twice as fast. voila parallel.

 

[buleyb]

Originally posted by: Schadenfroh
not on the drives, they use a PATA to SATA bridge chip, bottleneck, but i guess access time does not exceed 133 ata anyways so i guess you are safe

Isn't the 74GB Raptor a native SATA controller? I thought this was required to get the command queueing.

anyone?

 

[Sunner]

Originally posted by: buleyb

Originally posted by: Schadenfroh
not on the drives, they use a PATA to SATA bridge chip, bottleneck, but i guess access time does not exceed 133 ata anyways so i guess you are safe

Isn't the 74GB Raptor a native SATA controller? I thought this was required to get the command queueing.

anyone?

Yep, as are Seagates 7200.7.

 

[thorin]

It's simple. Serial protocols/interfaces "can be" faster because there are no timing issues to account for. You don't have to ensure that data bits a,b,c all arrive together and before x,y,z if you're only sending one bit of data at a time and in a row. So setting up a multi gigahertz interface sending single bits is much simpler then setting up a 10s or 100s of megahertz interface sending multiple bits.

ie:
|||||
|||||
|||||


vs

|
|
|
|

Thorin

 

[Jeff7]

Someone mentioned timing issues - they definitely play a part with drives, because cables can be many different lengths, as opposed to motherboards and CPU dies, where the interconnects are made at very precise lengths, so keeping bits in synch there is easier. That's why there's also a push for parallel processing at very high speeds - the high precision timing available on the boards makes this possible. Many things that operate with varying cables are serial - TCP/IP, USB, and serial ports (yes, really).

 

[Zepper]

And if you are only talking hard drives, the data comes off the disk(s) serially - one head reading one track at a time. So serial can be more efficient in that application - no conversion stage.
. I've often wondered why they don't use multiple heads reading/ writing multiple tracks simultaneously for parallel data flows instead of one head/one track/a bit at a time. Didn't the Kenwood CD-ROM drives use the multiple head method for their 70x+ read speeds?
.bh.

 

[beatle]

Originally posted by: Sunner

Originally posted by: buleyb

Originally posted by: Schadenfroh
not on the drives, they use a PATA to SATA bridge chip, bottleneck, but i guess access time does not exceed 133 ata anyways so i guess you are safe

Isn't the 74GB Raptor a native SATA controller? I thought this was required to get the command queueing.

anyone?

Yep, as are Seagates 7200.7.

The 7200.7 doesn't have the PATA to SATA bridge. But the new Raptors still do, as seen here.

 

[thorin]

That links to a "Preview", I don't think it's fair to assume that the production model will be or not be native SATA until we actually see a real one.

Thorin

 

[Viper96720]

It still uses a serial to parallel converter. That's why you can use the molex power connector or sata power. While the Seagate can only use the sata connector
for power.

Don't need sata for command queing. Don't scsi drives and some ibm ata drives have that ability?

 

[Matthias99]

I've often wondered why they don't use multiple heads reading/ writing multiple tracks simultaneously for parallel data flows instead of one head/one track/a bit at a time. Didn't the Kenwood CD-ROM drives use the multiple head method for their 70x+ read speeds?

The Kenwood "TrueX" drives did use that (I had one), and while they were indeed very fast at reading disks, they still had some issues. I'm guessing that if it had some problems on optical drives, trying to squeeze a mechanism like that into a tiny 3.5" magnetic hard disk would be even harder and more likely to screw up. Besides, anything that makes the read/write heads larger or heavier will increase seek times, which would likely negate any raw speed increases.

Don't need sata for command queing. Don't scsi drives and some ibm ata drives have that ability?

This is correct. However, you either need a native SATA drive, and/or one with extra electronics on it to queue the commands before issuing them to the drive. In theory you could have a PATA drive with command queuing, but it would cost too much to be worthwhile in the consumer price segment. Unless you're running some large web/database server or the like, command queuing is unlikely to make a big difference.

 

[Viper96720]

Found out was the IBM drive with tagged command queing. Needed the ide controller to support it.