linux Adaptec AHA-2940U2/U2W low preformance ?

[redpen]

ik weet niet zeker of ik hier goed zit maar ik mis ff niet waar ik het neer moest zetten

ik heb hier nu een leuk dual p3 500 servertje met
4 x QUANTUM ATLAS_V__9_WLS ( Direct-Access )

aangesloten op een

Adaptec AHA-2940U2/U2W

bij opstarten zeg me bak ook dat hij 80 mb per sec kan

maar dan test ik met hdparm en dan krijg ik

[root@cp71606-a dev]# hdparm -Tt /dev/sda
/dev/sda:
Timing buffer-cache reads: 128 MB in 0.97 seconds =131.96 MB/sec
Timing buffered disk reads: 64 MB in 2.26 seconds = 28.32 MB/sec
[root@cp71606-a dev]# hdparm -Tt /dev/sdb

/dev/sdb:
Timing buffer-cache reads: 128 MB in 0.98 seconds =130.61 MB/sec
Timing buffered disk reads: 64 MB in 2.55 seconds = 25.10 MB/sec
[root@cp71606-a dev]# hdparm -Tt /dev/sdc

/dev/sdc:
Timing buffer-cache reads: 128 MB in 0.98 seconds =130.61 MB/sec
Timing buffered disk reads: 64 MB in 2.28 seconds = 28.07 MB/sec
[root@cp71606-a dev]# hdparm -Tt /dev/sdd

/dev/sdd:
Timing buffer-cache reads: 128 MB in 0.96 seconds =133.33 MB/sec
Timing buffered disk reads: 64 MB in 2.24 seconds = 28.57 MB/sec


verder sysspecs zijn nog

met lsmod

scsi_mod 110872 3 [ide-scsi aic7xxx sd_mod] (dat is de driver)


[root@cp71606-a dev]# dmesg|less
Linux version 2.4.20-19.9smp ([e-mail]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SM
P Tue Jul 15 17:04:18 EDT 2003
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 0000000000097800 (usable)
BIOS-e820: 0000000000097800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000002fffd000 (usable)
BIOS-e820: 000000002fffd000 - 000000002ffff000 (ACPI data)
BIOS-e820: 000000002ffff000 - 0000000030000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
767MB LOWMEM available.
found SMP MP-table at 000f6ec0
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
On node 0 totalpages: 196605
zone(0): 4096 pages.
zone(1): 192509 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #1 Pentium(tm) Pro APIC version 17
Processor #0 Pentium(tm) Pro APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Kernel command line: ro root=LABEL=/ hdd=ide-scsi
ide_setup: hdd=ide-scsi
Initializing CPU#0
Detected 501.144 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 999.42 BogoMIPS
Memory: 769116k/786420k available (1491k kernel code, 14708k reserved, 1100k data, 156k init, 0k highmem)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K

en

[root@cp71606-a dev]# free
total used free shared buffers cached
Mem: 771724 575696 196028 0 132768 181036
-/+ buffers/cache: 261892 509832
Swap: 1566296 0 1566296
[root@cp71606-a dev]#


zijn deze prestaties enigsinds acceptable of zou ik meer moeten verwachten ?
bij mijn ide schijven die ik hierop heb krijg ik bij
Timing buffered disk reads: 64 MB snelheden van 44 mb/sec


p.s andere stats ook nog te vinden op http://217.123.169.240/system/index.php

[ Voor 6% gewijzigd door redpen op 12-09-2003 14:37 ]

[BalusC]

bij opstarten zeg me bak ook dat hij 80 mb per sec kan

Dat is idd de maximumsnelheid van het U2W interface En dat is dus niet de maximumsnelheid van de schijven.

De snelheid van de schijven kun je bijvoorbeeld in de database van www.storagereview.com terugvinden en als het meezit zelfs ook op www.maxtor.com

Anyway, 25~30MB/s is een nette snelheid voor een single U2W schijf lijkt mij zo

[ Voor 42% gewijzigd door BalusC op 12-09-2003 14:44 ]

[u_nix_we_all]

Nou , dat was vast nergens te vinden op het web ?

http://www.maxtor.com/en/..._family/atlas_v/index.htm :

Built on the industry leading Atlas architecture, it has a blazing-fast 6.3 millisecond average seek time, 29 MB/sec maximum sustained data throughput, and

edit:

u2 en u2w is ook nogal een verschil hoor, de een is narrow de ander is wide.

[ Voor 14% gewijzigd door u_nix_we_all op 12-09-2003 14:45 ]

[redpen]

ja thnx u_nix_we_all ik heb het net gevonden

http://www.001abc.com/har...m_atlas_v_9.10gb_hdd.html

shit ach ja maar goed dat alle data op me ide schijven staan in raid 1
die kunnen 44 aan
bedankt nog voor het helpen

[Liam]

Antieke SCSI schijven kunnen natuurlijk qua STR niet IDE bijbenen.
Misschien wel qua I/O's, SCSI heeft tenslotte command queuing en zeker nog wel qua access time.
Als ik hier mijn gloednieuwe WD1200JB vergelijk qua accesstime (12,8ms) met mijn oudere 10k 9,1 gb seagate cheetah (8,7ms) en mijn gloednieuwe Fujitsu MAP schijven (7,8ms) dan komen oude scsi schijven nog wel mee.
Nou is de Atlas V een 7200rpm schijf, maar dan nog kan command queuing een behoorlijke invloed hebben op de prestaties. Waardeloos zijn ze dus alles behalve, zeker omdat je ze in een servertje hebt zitten.
Lees anders eens femme's benchmarks.

Ter vergelijking is ook de IBM DNES-39170, een bejaarde 7200rpm SCSI-schijf uit het laatste jaar van het vorige millennium, in de resultaten opgenomen. De DNES-39170 illustreert het effect van command queuing door aanzienlijk beter te presteren dan de moderne ATA-schijven bij queue-diepten tot en met 64 uitstaande I/O's. Het command queueing mechanisme van de IBM-schijf kan kennelijk niet overweg met grotere queues, waardoor de prestaties sterk afzakken bij 128 en 256 uitstaande I/O's. De resultaten van de 10.000rpm en 15.000rpm SCSI-harde schijven zijn niet opgenomen in de grafiek omdat het grote verschil met de prestaties van de desktop ATA-drives de leesbaarheid van de grafiek ernstig zou verslechteren.