Re: filmscanners: Best solution for HD and images

["Ezio c/o TIN" <ezio.lucenti1@tin.it>]

Austin, we don't understand each other .

Sure it's my fault .

 

> > > > Thus in the case of SCSI where you cannot (by definition) overcome the
> > > > number of 6 devices x chain/controller,
> > >
> > > WHAT SCSI are you talking about?  Try 16. not 6.
> > >
> >
> > How many addresses have you per controller ?
> > from 0 to 6 = 7 but 1 is the controller itself.
> > SCSI is not IBM SSA . SCSI = 6 devices x controller/chain ; SSA
> > 16 devices x
> > controller/loop
>
> 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.

 

From ADAPTEC WEB site

 

Performance

 

Supports up to 160 MByte/sec transfer rates with Ultra160 SCSI
Connects high-performance devices such as hard disk drives, CD-Recorders, and other high-speed peripherals to your PC

 

Connectivity

 

Connectivity for internal and external SCSI devices
Single SCSI card can connect up to 7 or 15 devices per channel
Backward compatible with earlier versions of SCSI

 

The Newest SCSI Features

 

Features added with Ultra160 SCSI

 

160 MByte/sec performance
Cyclic Redundancy Checking (CRC) checks all transferred data, adding significantly to data integrity
Domain Validation intelligently verifies system configuration and automatically sets reliable transfer speeds

 

The Types of SCSI

 

SCSI Type Speed SCSI makes it easy to connect hot hard drives and cool peripherals
Ultra160 SCSI (16-bit Wide) 160 MB/sec State-of-the-art hard drives
Ultra2 SCSI (16-bit Wide) 80 MB/sec Hard drives
Ultra Wide SCSI (16-bit Wide) 40 MB/sec Hard drives and tape drives
Ultra SCSI (8-bit Narrow) 20 MB/sec CD-R, CD-RW, tape, removable storage (Jaz), and DVD drives
SCSI-2, Fast SCSI (8-bit Narrow) 10 MB/sec Scanners, Zip drives, and CD-ROM

 

Server Technology Comparison

 

> 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 4

RAID Level 4 stripes data at a block level across several drives, with parity stored on one drive. The parity information allows recovery from the failure of any single drive. The performance of a level 4 array is very good for reads (the same as level 0). Writes, however, require that parity data be updated each time. This slows small random writes, in particular, though large writes or sequential writes are fairly fast. Because only one drive in the array stores redundant data, the cost per megabyte of a level 4 array can be fairly low.

RAID Level 5

This level is commonly referred to as striping with distributed parity. RAID Level 5 is similar to level 4, but distributes parity among the drives. No single disk is devoted to parity. This can speed small writes in multiprocessing systems. Because parity data must be distributed on each drive during reads, the performance for reads tends to be considerably lower than a level 4 array. The cost per megabyte is the same as for level 4.

 

Then it costs in performances anyhow ....

I personally estimate this in almost 20% (average) ... but we can discuss about this amount , what I am thinking is : RAID 5 slowers the operations if compared with a no-RAID mode (stright mode).

 

For me this is true by definition and by real mesurements.

 

> > > 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 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.

 

Ultra160 uses double transition clocking to send 2 bits of data per clock cycle instead of one, doubling Ultra2's data transfer rate of 80MB/s to 160 MB/s. As drive caches approach the 2 MB range, Ultra160 will grow to meet demands much as its predecessors Wide Ultra and Ultra2 SCSI evolved over the last three years

 

> > > 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 ?

 

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 ... 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).

 

Sincerely.

 

Ezio    

 

www.lucenti.com  e-photography site

 

 

----- Original Message -----

From: "Austin Franklin" <darkroom@ix.netcom.com>

To: <filmscanners@halftone.co.uk>

Sent: Monday, November 12, 2001 4:50 PM

Subject: RE: filmscanners: Best solution for HD and images

> > > > Thus in the case of SCSI where you cannot (by 
definition) overcome the
> > > > number of 6 devices x 
chain/controller,
> > >
> > > WHAT SCSI are you talking 
about?  Try 16. not 6.
> > >
> >
> > How many 
addresses have you per controller ?
> > from 0 to 6 = 7 but 1 is the 
controller itself.
> > SCSI is not IBM SSA . SCSI = 6 devices x 
controller/chain ; SSA
> > 16 devices x
> > 
controller/loop
> 
> 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.
> 
> > > That's not true.  There 
is no "double write", both the data/parity is
> > > written at the 
same time.  Parity can easily be calculated on the fly.
> > 
>
> >
> > YEP !  and who does write it on the disk in 
a different area/zone/disk ?
> 
> 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.
> 
> > > Run some benchmarks on your system and see 
for your self.
> > Also, make sure
> > > 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.
> >
> > My data are the output of a benchmark and not the 
theoretical max speed.
> 
> What benchmark are you using?  I do 
not believe you are getting 134M
> bytes/sec, it is physically 
impossible.
> 
> > Yes you can add because SCSI can parallelize 
the requests while
> > IDE cannot.
> 
> IDE CAN 
parallelize, and as I said, you can't just add transfer rates, it
> 
doesn't work that way.
> 
> > > 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).
> 
> Now you're talking silly.  You said you had four disks.  The 
MAX media
> transfer rate from those disks is around 35M bytes/sec.  
Even if they were
> able (which they are NOT) to sustain that over the 
SCSI/PCI bus at full
> speed, that's 140M bytes/sec.  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.
> 
>