ðòïåëôù 


  áòèé÷ 


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



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