tester un hd neuf

--{ Hugolino a plopé ceci: }--

Merci à tous pour m'avoir donné le nom du programme de test: badblocks

You're welcome in the bad blocks gang. Have a beer ?


--
"All the things I really like to do are
either immoral, illegal, or fattening."

Hugolino a écrit :

Le test dure environ 24 heures sur ce disque de 250 Go. Si j'avais pensé
à mettre les I/O du disque en 32 bits avec 'hdparm -c 1 /dev/hdb', ça
aurait peut-être été plus rapide, mais comme ça avait l'air de débiter à
75 Mo/s sans ça, je crois pas que ça aurait changé grand chose.

Le mode d'accès 32 bits n'est effectif qu'en mode de transfert PIO, pas
en (U)DMA.

Chez moi la seule valeur qui évolue notablement est "Hardware_ECC_Recovered"

Les valeurs à surveiller sont surtout le nombre de secteurs réalloués et
le nombre d'erreurs non corrigées.

Le Fri, 04 Jul 2008 18:33:20 +0200, Pascal Hambourg a écrit:

Hugolino a écrit :
> Le test dure environ 24 heures sur ce disque de 250 Go. Si j'avais pensé
> à mettre les I/O du disque en 32 bits avec 'hdparm -c 1 /dev/hdb', ça
> aurait peut-être été plus rapide, mais comme ça avait l'air de débiter à
> 75 Mo/s sans ça, je crois pas que ça aurait changé grand chose.

Le mode d'accès 32 bits n'est effectif qu'en mode de transfert PIO, pas
en (U)DMA.

J'avais parié que si je disais une co**erie tu serais là pour me
corriger :)
Un petit lien pour expliquer ce genre de subtilité ?

Est-ce que ça a un rapport avec ce que raconte la page de manuel de
hdparm à propos de l'otion '-c':
8<-----------8<---------8<----------8<----------8<----------8<----------8<
Note that "32-bit" refers to data transfers across a PCI or VLB bus to
the interface card only; all (E)IDE drives still have only a 16-bit
connection over the ribbon cable from the interface card.
8<-----------8<---------8<----------8<----------8<----------8<----------8<

hdparm -i /dev/hdb raconte:
8<-----------8<---------8<----------8<----------8<----------8<----------8<
/dev/hdb:
Model=SAMSUNG SP2514N, FwRev=VF100-50, SerialNo=S08BJ1CPC17969
Config={ Fixed }
RawCHS383/16/63, TrkSize4902, SectSizeU4, ECCbytes=4
BuffType=DualPortCache, BuffSize92kB, MaxMultSect, MultSect=off
CurCHS@47/16/255, CurSects511760, LBA=yes, LBAsects&8435455
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3
ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

* signifies the current active mode
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Verrais-tu quelque optimisation utile ?

> Chez moi la seule valeur qui évolue notablement est "Hardware_ECC_Recovered"

Les valeurs à surveiller sont surtout le nombre de secteurs réalloués et
le nombre d'erreurs non corrigées.

Oui.

--
Linux users never complain about Microsoft. They don't need to !
Hugo (né il y a 1 394 721 857 secondes)

Le Fri, 4 Jul 2008 08:21:45 -0700 (PDT), ptilou a écrit:

Une boucle avec /dev/zero, puis ci t'as encore des doutes t'en
inbrique une deuxieme avec Hdparm ....

dd if=/dev/random of=/dev/brain ?

--

Voici mon problème, j'ai deux PCs relies par des cartes ethernet,
configures avec le protocole PPP.

-+- Romain in Guide du linuxien pervers - "Ils sont fous ces romains !" -+-
Hugo (né il y a 1 394 724 466 secondes)

Hugolino a écrit :

Le Fri, 04 Jul 2008 18:33:20 +0200, Pascal Hambourg a écrit:

Le mode d'accès 32 bits n'est effectif qu'en mode de transfert PIO, pas
en (U)DMA.

Un petit lien pour expliquer ce genre de subtilité ?

Pas sous la main, non. Comme j'ai la flemme de chercher un lien potable,
je vais expliquer moi-même.

Est-ce que ça a un rapport avec ce que raconte la page de manuel de
hdparm à propos de l'otion '-c':
8<-----------8<---------8<----------8<----------8<----------8<----------8<
Note that "32-bit" refers to data transfers across a PCI or VLB bus to
the interface card only; all (E)IDE drives still have only a 16-bit
connection over the ribbon cable from the interface card.
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Plus ou moins. La largeur du bus de données ATA/IDE est de 16 bits. Les
transferts entre l'adaptateur hôte et le périphérique s'effectuent
toujours par mots entiers de 16 bits. Il faut 256 mots pour un secteur
de 512 octets par exemple. Il faut se rappeler que ATA signifie "AT
Attachment", et cette largeur de 16 bits est calquée sur celle du bus
système PC/AT (appelé communément bus ISA). L'adaptateur hôte ATA
originel était très simple.

En mode PIO (Programmed I/O), c'est le processeur hôte qui effectue le
transfert de chaque mot avec une instruction d'entrée-sortie à l'adresse
du port de données de l'adaptateur ATA. Or avec les adaptateurs ATA sur
bus VLB et PCI, la largeur du bus système passe à 32 bits alors que la
largeur du bus ATA reste à 16 bits. On a donc deux possibilités :
- soit on continue à utiliser des instructions d'entrées-sortie sur 16
bits, en n'utilisant que la moitié de la capacité du bus VLB ou PCI ;
- soit, avec les adaptateurs ATA qui le supportent, on utilise des
instructions d'entrée-sortie sur 32 bits permettant de transférer deux
mots de 16 bits à la fois sur le bus système, l'adaptateur ATA se
chargeant de la concaténation et de la séparation en mots de 16 bits sur
le bus ATA.

Le réglage "32-bit" décide donc si le processeur utilise des
instructions 16 bits ou 32 bits pour accéder au port de données du
contrôleur hôte ATA.

Vous allez me dire : quel intérêt puisque le bus PCI est beaucoup plus
rapide que le mode PIO le plus rapide (33 Mmots/s avec une horloge à 33
MHz contre 8 Mmots/s en PIO4) ? Par conception, le bus PCI est taillé
pour être le plus efficace dans les transferts dits "en rafale", où on
transfère plusieurs mots à des adresses consécutives en une seule
transaction. Par contre il l'est beaucoup moins pour des transferts
répétés avec la même adresse comme c'est le cas en mode PIO, car chaque
mot transféré demande une transaction séparée et chaque transaction
"coûte" un certain nombre de cycles d'horloge PCI indépendamment du
nombre de mots tranférés. Par conséquent il est plus efficace de faire
des transferts par mots de 32 bits plutôt que 16 bits, car cela divise
par deux le nombre de transactions. Le résultat est sans appel : des
tests que j'ai fait sur plusieurs machines ont montré que le débit
soutenu en PIO4 en mode 16 bits était largement inférieur aux 16 Mo/s
attendus alors que les disques eux-mêmes pouvaient soutenir des débits
largement supérieurs. Le mode 32 bits permettait d'améliorer
sensiblement le débit obtenu.

Maintenant, pourquoi ce réglage est-il sans effet en (U)DMA ?
En (U)DMA, ce n'est plus le processeur qui transfère les données entre
le contrôleur ATA et la mémoire mais le contrôleur ATA lui-même, qui
prend la maîtrise du bus (busmaster) à la place du processeur. Par
conséquent le choix entre instructions d'entrées-sorties sur 16 ou 32
bits exécutées par le processeur n'a plus lieu d'être. D'autre part
comme le contrôleur ATA transfère directement les mots en mémoire à des
adresses consécutives, il peut utiliser le bus PCI à son plein potentiel
en transférant un maximum de mots en rafale lors d'une même transaction
PCI. Les transferts en (UDMA) ne souffrent donc pas de la limitation du
bus PCI en PIO.

A noter que le bus VLB ne supportait pas les transferts en DMA à ma
connaissance.

hdparm -i /dev/hdb raconte:
8<-----------8<---------8<----------8<----------8<----------8<----------8<
/dev/hdb:
Model=SAMSUNG SP2514N, FwRev=VF100-50, SerialNo=S08BJ1CPC17969
Config={ Fixed }
RawCHS383/16/63, TrkSize4902, SectSizeU4, ECCbytes=4
BuffType=DualPortCache, BuffSize92kB, MaxMultSect, MultSect=off
CurCHS@47/16/255, CurSects511760, LBA=yes, LBAsects&8435455
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3
ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

* signifies the current active mode
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Verrais-tu quelque optimisation utile ?

En PIO, il aurait pu être utile d'activer l'option "multiple sector"
(hdparm -m). Elle sélectionne l'utilisation de commandes ATA PIO
permettant de transférer un seul secteur ou plusieurs secteurs à la
fois. Elle aussi est sans effet en (U)DMA car toutes les commandes ATA
DMA permettent des transferts de secteurs multiples.

A noter que * n'indique pas que le mode DMA ou UDMA est activé. Il
indique seulement le mode DMA ou UDMA qui serait utilisé lors d'un
transfert avec une commande DMA.