Filmscanners mailing list archive (filmscanners@halftone.co.uk)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: filmscanners: Best solution for HD and images
I'll take this off list .
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.
>
>
|