Poor SCSI drive performance on SMP machine, 2.2.16

I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM IBM 10 GB SCSI drive
(AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. The SCSI drive
performs the worst. In tests of writing 100 MB and sync'ing, one of my IDE drives takes 31 seconds. The SCSI drive (while doing nothing else) took 2 minutes, 10 seconds. This is extremely noticable in file transfers that completely
monopolize the SCSI drive, and are much slower than when involving the IDE drives.
After a large data operation on the SCSI drive, the system will hang for several minutes.
Anyone know what could be causing this? Thanks.

Attached are some data to help.

Thanks,
Para-dox ([email protected])

CPU0 CPU1

  0:   43661720   59171710    IO-APIC-edge  timer
  1:     233992     282694    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
  8:          1          0    IO-APIC-edge  rtc
 13:          1          0          XT-PIC  fpu
 14:         20         10    IO-APIC-edge  ide0
 15:   46455293   50354306    IO-APIC-edge  ide1
 16:   14508949   14462778   IO-APIC-level  eth0
 17:    3939554    4293901   IO-APIC-level  eth1
 18:     750747     761816   IO-APIC-level  aic7xxx
NMI:          0
ERR:          0
PCI devices found:
  Bus  0, device   0, function  0:
    Host bridge: Intel 440BX - 82443BX Host (rev 2).
      Medium devsel.  Master Capable.  Latency=64.  
      Prefetchable 32 bit memory at 0xe8000000 [0xe8000008].
  Bus  0, device   1, function  0:
    PCI bridge: Intel 440BX - 82443BX AGP (rev 2).
      Medium devsel.  Master Capable.  Latency=64.  Min Gnt=136.
  Bus  0, device   7, function  0:
    ISA bridge: Intel 82371AB PIIX4 ISA (rev 2).
      Medium devsel.  Fast back-to-back capable.  Master Capable.  No bursts.  
  Bus  0, device   7, function  1:
    IDE interface: Intel 82371AB PIIX4 IDE (rev 1).
      Medium devsel.  Fast back-to-back capable.  Master Capable.  Latency=64.  
      I/O at 0xf000 [0xf001].
  Bus  0, device   7, function  2:
    USB Controller: Intel 82371AB PIIX4 USB (rev 1).
      Medium devsel.  Fast back-to-back capable.  IRQ 10.  Master Capable.  Latency=64.  
      I/O at 0xe000 [0xe001].
  Bus  0, device   7, function  3:
    Bridge: Intel 82371AB PIIX4 ACPI (rev 2).
      Medium devsel.  Fast back-to-back capable.  
  Bus  0, device   8, function  0:
    Ethernet controller: Intel 82557 (rev 5).
      Medium devsel.  Fast back-to-back capable.  IRQ 16.  Master Capable.  Latency=64.  Min Gnt=8.Max Lat=56.
      Prefetchable 32 bit memory at 0xef101000 [0xef101008].
      I/O at 0xe400 [0xe401].
      Non-prefetchable 32 bit memory at 0xef000000 [0xef000000].

Bus 0, device 9, function 0:
Ethernet controller: Winbond NE2000-PCI (rev 0).
Medium devsel. Fast back-to-back capable. IRQ 17.
I/O at 0xe800 [0xe801].
Bus 0, device 12, function 0:
SCSI storage controller: Adaptec AIC-7890/1 (rev 0).
Medium devsel. Fast back-to-back capable. BIST capable. IRQ 18. Master Capable. Latency=64. Min Gnt=39.Max Lat=25. I/O at 0xec00 [0xec01].
Non-prefetchable 64 bit memory at 0xef100000 [0xef100004].
Bus 1, device 0, function 0:
VGA compatible controller: S3 Inc. ViRGE/GX2 (rev 6).
Medium devsel. IRQ 16. Master Capable. Latency=64. Min Gnt=4.Max Lat=255.
Non-prefetchable 32 bit memory at 0xe0000000 [0xe0000000].

WOOHOO, first report where I win one against the ever losing battle against SCSI....paradox3, you made my evening...

Also please add to the sign on I95 exit 2...

""Welcome to Maine", 'now you can go home, now'"

Caution Moose will attempt to mate with cars carrying canoes in the winter.

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi.

Do you get messages like the ones below in /var/log/messages?

sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs sym53c875-0-<0,0>: tagged command queue depth set to 7

In fact, do you get any messages in your log files that look like they might be related?

--
Bruce Harada
[email protected]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

You didn't provide enough information for anybody to have a single idea about the cause of the problem you report, in my opinion.

Just any not too old 10,000 RPM disk is able to sustain more that 25 MB/s sequential data transfer, but cannot do better than 5 milli-seconds latency with random IO patterns. So, result for 100 MB transfer can be less than 4 seconds in the best case but greater than (25000*5)/1000=125 seconds for random 4K IO pattern, for example.

What you want to do, in my opinion, could be:

- Check in the syslog the actual transfer speed that has been negotiated for your SCSI disk.
- Also check if error messages related to disk IOs have been reported by the kernel.
- Run some benchmark to check, at least, sequential IO performance (iozone for example will fit)

Gérard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I don't get any messages relating to the drives in any syslog output.

----- Original Message -----
From: "Bruce Harada" <[email protected]>
To: "paradox3" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Sunday, January 28, 2001 3:40 AM
Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hm. As a point of comparison, I use a similar system to yours (full SCSI, though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the same disk, in around 13 seconds. Where are you copying to the SCSI drive from - the same drive, an IDE disk, CDROM? If IDE, what are its particulars? (Check with hdparm -iI /dev/hd?)

--
Bruce Harada
[email protected]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I did this:

date
dd if=/dev/zero of=TESTFILE bs=1024 count=102400
date
sync
date

and I gave the time differences from the first to the last timestamp.

Regards, Para-dox ([email protected])

----- Original Message -----
From: "Bruce Harada" <[email protected]>
To: "paradox3" <[email protected]>
Cc: <[email protected]>
Sent: Sunday, January 28, 2001 2:31 PM
Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Sorry, forget this last email. Here is hdparm output.

hmm. i ran this on my old ppro200 with adaptec 2940uw and ibm DDRS-39130W drive.

sophia(jk)$ cat foo
date
dd if=/dev/zero of=TESTFILE bs=1024 count=102400
date
sync
sync
sync
date

i get

sophia(jk)$ time bash foo
Sun Jan 28 18:41:52 EST 2001
102400+0 records in
102400+0 records out
Sun Jan 28 18:42:11 EST 2001
Sun Jan 28 18:42:13 EST 2001

real    0m20.803s
user    0m0.400s
sys     0m8.780s

and this during a full kernel compile.

i get similar decent results using my other computer with a symbios 8751sp and fujitsu and seagate drives.

something must be messed up in a configuration somewhere. are you sure you are running the drive in synchronous ultra wide mode? is you termination good?

J o h a n  K u l l s t a m
[[email protected]]
Don't Fear the Penguin!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/