ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá












     áòèé÷ :: Filmscanners
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.
>
>





 




Copyright © Lexa Software, 1996-2009.