RE: filmscanners: Best solution for HD and images

["Austin Franklin" <darkroom@ix.netcom.com>]

> > No one uses narrow SCSI for RAID, and it doesn't have to be SSA.  SCSI
uses
> > four bits for SCSI ID, which makes SIXTEEN devices.

> The U-160 card I know (Adaptec 29160) allows the connection of 7 devices
> each controller while permitting 16 addresses.

A device IS the same as a SCSI address in this case.  Narrow SCSI can have 8
devices (three bits), one being the controller.  Wide SCSI, which is what
any RAID system is going to use (or why bother) has four bits, or 16
devices/addresses.

> Single SCSI card can connect up to 7 or 15 devices per channel

If you are using narrow devices, 7 is the number, wide devices, 15 is the
number.  As I said, it's not worth doing RAID on a narrow drive, since there
really aren't any SCSI 160 drives that are narrow that I know of...

> > A correct implementation of RAID 5 will write all at the same time.
RAID 5
> > is NOT slowed down because it has to do multiple writes, it's because,
> > sometimes, depending on stripe size, it has to read, calculate parity,
then
> > write.  RAID 5 is slowed down for reads, since the parity is distributed
> > across drives.

> RAID Level 5
> ...the performance for reads tends to be considerably lower...

As I said, but note that there was no penalty for writes.  Writes are cached
anyway.

> > > the benchmarks AREN'T running out of disk cache...that hardly tests
the
> > disk
> > > speed.  You'll be lucky to get even near 80, if even 60.

> I am meaning ... each disk runs at 35 or 30MB/s + SCSI architecture allows
parallel operations

True.

> then I can add them to have an aggregated transfer rate . It might be I
will never achieve 100% > real addition , but I believe the aggregated
transfer rate is close to the summary
> of the single aggregated transfer rates of each disk.

They DO increase, but not by direct addition, as you implied.

> Ultra160 uses double transition clocking to send 2 bits of data per clock
cycle instead of one,

Two BYTES of data per clock.

> > > The standard PCI bus is 33 MHz (or 66MHz), NOT 133MHz.  Perhaps you
mean
> > > 132M BYTES/sec?  Even at that, you can't get near %80 of that, if
you're
> > > lucky.  132M bytes/sec is the burst rate.  There is substantial
overhead
> > on
> > > the PCI bus that lowers that substantially.
> > >
> >
> > YEP ! I can achieve the saturation of bus before achieving the
> > saturation of
> > the controller (Adaptec 29160 is a 64 bit adapter).

> Correct ... then I can achieve the saturation (80% of 132MB/s) of the bus
before
> saturating the max controller throughput .... right ?

Yes.

> > 64 bit PCI is 264M bytes/sec for 33MHz PCI,
> > and 528M bytes/sec for 66MHz PCI...so there is NO way you are saturating
the
> > PCI bus especially with a 64 bit controller.  You previously said you
were
> > on a 32 bit PCI bus.

> No, no ! As far as I know the Intel PC has a 32bit PCI but Adaptec has
implemented
> a 64bit adpater over a 32bit bus ...

Absolutely not.  32 bit PCI IS only 32 bits wide.  Only 64 bit PCI is 64
bits wide.

> they are doubling the cycle and thus keeping the compatibility with
old-standard
> PCI-Intel systems while improving the speed and throughput of the adapter
> (compared with 32bit adapters).

A 32 bit 33MHz PCI bus only gives 132M byte/sec burst transfer speed.  If
you have a 64 bit device on a 32 bit PCI bus, it is acting as a 32 bit
device.  The upper 32 bits are not used.  There is no such thing as "cycle
doubling" on PCI.