Re: SCSI adapter PCI bandwidth usage

"Cyrille Briegel" <wanhua69@xxxxxxxxxxxxxx>,
In a message on Mon, 1 May 2006 13:28:27 +0800, wrote :

"B> So you would suggest buying another SCSI controller only for the CDR?

Yes. This solved problems on my system with a SCSI CDR / SCSI system disk.

"B> The idea is good for totally separating the SCSI bus for both devices.
"B> The only problem is that it will need an extra available unshared IRQ (quiet
"B> impossible on my PCI crowded MB)

Why does it need to be an unshared IRQ? Modern O/S's should be able to
deal with a shared IRQ...

"B> On the controller manual, it advertises that Adaptec uses a feature called
"B> SpeedFlex technology that is suppose to isolate both segment (LVD/SE) on the
"B> SCSI bus. Does it really helps or is it only advertisment crap?

This is something different. You still have a single SCSI bus with a
single host adapter. This just means that the controller has the
electronics to allow the LVD disks to run at full speed, without being
dragged down to the shower SE speed on other devices attached to the
controller.

"B> I agree that the PCI bandwidth is fast enough for the CDR, but when the HDD
"B> is running along with other PCI devices? (especially with a multitrack sound
"B> card). The HDD can have burst speed a little over 100 MB/s. If every PCI
"B> devices is transfering data at the same time (unlikely) it can have PCI
"B> congestion I guess.

With a *single* U160 disk, you are not likely to completely max out the
PCI bus. Yes, the disk has a high burst rate, but this is going to be
*short* bursts. It is not going to sustain the 100 MB/s data rate all
by itself for long. If it was a *RAID* card with a pile of U160 or U320
disks, yes you *could* swamp the PCI bus, but not with a single disk.
Sooner or later you'd need to pause for a seek. Yes, it is unlikely
that all of the devices are tying up the PCI bus all at once or for very
long. Assuming that the various devices have some cache and some memory
for buffering, you should be OK. Your trouble is mostly because the
SCSI controller is in contention with *itself* -- you are have *SCSI* bus
contention more than PCI bus contention.

"B>
"B> Thanks for your advice and information.
"B>
"B> Cyrille
"B>
"B>
"B> "Robert Heller" <heller@xxxxxxxxxxxx> wrote in message
"B> news:b49cb$44558600$cb248f0$13419@xxxxxxxxxxxxxxxxxxxxxxxx
"B> > PeterD <peter2@xxxxxxxxxx>,
"B> > In a message on Sun, 30 Apr 2006 20:40:42 -0400, wrote :
"B> >
"B> > P> On Mon, 1 May 2006 03:00:15 +0800, "Cyrille Briegel"
"B> > P> <wanhua69@xxxxxxxxxxxxxx> wrote:
"B> > P>
"B> > P> >I have an Adaptec 19160 SCSI controller with a SCSI Ultra160 HDD (LVD)
"B> and a
"B> > P> >SCSI CD writer (SCSI-3)
"B> > P> >I'd like to know if the SCSI controller "reserve" the PCI bandwidth
"B> (set at
"B> > P> >160 for the controller and the HDD and 20 for the CD writer). Which
"B> would
"B> > P> >means that even if the HDD is not reading or writing anything, the
"B> > P> >controller still use the total PCI bandwidth (160) of the SCSI
"B> controller.
"B> > P> >I have a doubt about that because I had some drop outs while recording
"B> audio
"B> > P> >with a sound card with the SCSI controller and the HDD set at 160. I
"B> lowered
"B> > P> >the value to 80 for both of them and there was no more audio drop outs
"B> > P> >during recording. That make me think that the drop outs were directly
"B> > P> >related with PCI bus congestion. Since I already have several other
"B> PCI
"B> > P> >devices (firewire, USB, LAN, sound card) in my system, I really need
"B> to save
"B> > P> >as much PCI bandwidth as possible.
"B> > P> >Lowering the value to 80 (instead of 160) for my HDD and the
"B> controller
"B> > P> >doesn't affect the audio recording (it's still fast enough for that
"B> > P> >purpose). But for other applications, I still loose some HDD speed
"B> > P> >(according to HDD benchmarks, mainly for the burst speed)
"B> > P> >I also would like to know if disabling write caching (or not) of the
"B> HDD has
"B> > P> >any effects on the PCI bandwidth (use more or less?)
"B> > P> >
"B> > P> >Thanks for any advice and comments!
"B> > P> >
"B> > P>
"B> > P> You have liberally mixed SCSI bus speed with PCI bus speed. The two
"B> > P> are only slightly related. If your PCI bus can't keep up, it is
"B> > P> probably that the computer just doens't have the 'horsepower' to do
"B> > P> the job.
"B> > P>
"B> > P> Although there are some priorities on the PCI bus, this is not
"B> > P> generally configurable by the user.
"B> > P>
"B> > P> Regardless if both the drives and the CDR drive are on the scsi bus,
"B> > P> then PCI has nothgin to do with it...
"B> >
"B> > As a general rule, you don't really want to put your SCSI CDR on the
"B> > *same* SCSI bus as your SCSI hard drive. It can create timing problems
"B> > -- the CDR wants to get a continious feed of data at its recording speed
"B> > and any interuption can trash the CD being burned.
"B> >
"B> > Getting a 'cheap' (narrow) SCSI controller for the CDR will help. This
"B> > will allow I/O overlap between the CDR and the harddrive. The CDR
"B> > is a 'relativly' slow device, compared to either the U160 SCSI disks or
"B> > a typical current vintage PCI bus, so neigher of these is a bottleneck
"B> > *by itself*. Because you have the CDR on the same logical bus as the
"B> > hard drives (same controller channel) the CDR and the U160 drives are in
"B> > sometimes in contention for the SCSI bus / SCSI controller. Putting the
"B> > CDR on its own controller removes this possible contention. SCSI cards,
"B> > in general, have enough local processing to manage operations on their
"B> > own. The PCI bus itself is more than fast enough for the CDR.
"B> >
"B> > P>
"B> >
"B> > Robert Heller -- 978-544-6933
"B> > Deepwoods Software -- Linux Installation and Administration
"B> > http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
"B> > heller@xxxxxxxxxxxx -- Contract Programming: C/C++, Tcl/Tk
"B> >
"B> >
"B> >
"B> >
"B> >
"B> >
"B> >
"B>
"B>
"B>

Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
heller@xxxxxxxxxxxx -- Contract Programming: C/C++, Tcl/Tk







.

Relevant Pages

  • Re: SCSI adapter PCI bandwidth usage
    ... P>>controller still use the total PCI bandwidth of the SCSI controller. ... P> You have liberally mixed SCSI bus speed with PCI bus speed. ... P> Regardless if both the drives and the CDR drive are on the scsi bus, ...
    (comp.periphs.scsi)
  • Re: SCSI adapter PCI bandwidth usage
    ... So you would suggest buying another SCSI controller only for the CDR? ... The idea is good for totally separating the SCSI bus for both devices. ... I agree that the PCI bandwidth is fast enough for the CDR, ...
    (comp.periphs.scsi)
  • HSG60 SCSI write abort on unit, not disk
    ... I have a HSG60 controller with mirror sets on it. ... I have also included the description of the Instance and the SCSI ... SCSI Command Opcode: 42. ... Sense Data Qualifiers: 64. ...
    (Tru64-UNIX-Managers)
  • Re: Loss of SCSI boot after CMOS battery replacement
    ... result of my old motherboard BIOS after all. ... controller takes priority over the SCSI ... IDE first to SCSI first. ... SCSI drives and Win98. ...
    (comp.periphs.scsi)
  • Re: Anthonys drive issues.Re: ssh password delay
    ... Upgrade the system BIOS ... Upgrade the firmware in the SCSI controller ... > firmware in the drives. ...
    (freebsd-questions)
Loading