SMPFR

donc a prioris si tu force l'IRQ dans le BIOS ça devrait marcher.
mais je te comprends, j'evite de bidouiller profond quand je sais que je vais avoir besoin du PC !

deja que mon pc de jeux a une install qui passera pas la lan
alors si enplus je doit me tapper une reinstall du serveur

je pourrai jamais manger et boire tou ce que j'emene

tu manges pendant les LANs
j'ai tendance a manger liquide
dans le pire des cas, tu retourne le clavier, ya toujours un bout de pizza qui traine

ouaip
je bouffe comme un goret en plus
je suis le specialiste de la brioche au pepite d echocolat
qui ce glisse de partout dans le clavier :ange

HD Speed dispo sur telecharger.com


Contrôleur 3ware RAID 5 SATA avec 4 seagate 7200.8 250 Go

le site de l editeur : http://www.steelbytes.com

Seagate 40Go 5400trs du portable

c'est parti pour un autre bench
en avant

cool testerai demain une foi tout remonter

j'ai testé ca sur mon pc et mon portable avec les réglages par défaut :
- PC :
[*]Seagate 40go, 7200rpm 2mo de cache en pata : 40mo/s
[*]Maxtor 160go, 7200rpm 8mo de cache en pata : 55mo/s
[*]Maxtor 160go, 7200rpm 8mo de cache en usb2 : 20mo/s :'(
- Portable : disque dur Hitachi 7K60 (7200rpm, 8mo de cache, pata 2.5)
[*]proc à 400mhz : 13mo/s
[*]proc à 1533mhz : 32mo/s

J'aime pas trop l'idée que le débit disque dur soit lié à la fréquence du proco... à croire que le chipset bidouille la vitesse de connexion en fonction de la fréquence du proc...

je comprend pourquoi j'ai des débits pourri quand je suis en onDemand (la fréquence évolue selon la demande), et ca me fait chier... j'espère juste que le bios précédent enlevera ce bug (j'appelle pas ca une fonctionnalité, je me suis pas payé un dur à 7200rpm pour qu'il bosse aussi lentement que mon 4200...)
[*]

Le raid 5 du server avec 4 fuji 10k de 36Go -> 80Mo/s

po terrible


Ca marchait mieux en raid 0

c'est normal
mais 80mo/s pour du raid 5 c'est déjà bueno

J'aime pas trop l'idée que le débit disque dur soit lié à la fréquence du proco... à croire que le chipset bidouille la vitesse de connexion en fonction de la fréquence du proc...

normal. l'IDE est géré par le proc (t'as qu'a regardé l'occupation UC quand tu copies un gros fichier)
c pour ça que j'utilise le moins possible les controleurs IDE des cartes meres....
j'ai deja vu des disques plus rapides en extrene sur du Firewire que sur l'IDE intégré (OK, c'etait un chipset SIS735 )

faut pas déconner non plus hein...

me dites pas qu'un amd qui tourne à 400MHz peut pas se prendre du 30mo/s dans la tete...

à croire que le chipset aussi diminue sa fréquence

pensez à changer la taille des blocs de lecture ... les perfs s'en ressentent grandement.

Mon IDE (seagate barraccuda 7200.7 PATA 120 Go) arrive à sortir un 90 Mo/s

Je fais un screenshot ce soir

pensez à changer la taille des blocs de lecture ... les perfs s'en ressentent grandement.

tu chnages ça ou ? c dans le BIOS ?
je vois pas l'option (g IDE block mode -> Enabled / disabled)

nan au formatage ntfs

oui mais doit y avoir une contrepartie non ?
On perd en capacité ou autre ?
Sinon pourquoi les constructeurs ne mettent pas ces tailles par defaut ???

ah OK, c la taille des clusters.
plus les clusters sont gros plus ça depote plus tu perd de place (en gros c ça)
un fichier occupe au moins un cluster donc si ton fichier fait 2octets (CR/LF) et que ton cluster fait 64ko bah t'as perdu 65534 octets
sur les disques RAID, ce qui marche bien, c de mettre la taille du cluster = taille du stripe. comme ça, on evite de lire inutilement des morceaux de cluster ou de stripe

ben ça se trouve si t'est super bond en lecture, t'es super mauvais en écriture

faut un juste milieu

Oki thx pour les precisions

pensez à changer la taille des blocs de lecture ... les perfs s'en ressentent grandement.

tu chnages ça ou ? c dans le BIOS ?
je vois pas l'option (g IDE block mode -> Enabled / disabled)

dans HD Speed au lieu de laisser "Taille du bloc" à Auto tu testes avec des tailles prédéfinies dans la liste avant de lancer le test. Avec la 3ware, ça allait de 30 à 192 Mo/s suivant la taille du bloc servant en lecture

Edit : Et encore, C tests ont été faits avant de défragmenter le DD

ah OK, c la taille des clusters.
plus les clusters sont gros plus ça depote plus tu perd de place (en gros c ça)
un fichier occupe au moins un cluster donc si ton fichier fait 2octets (CR/LF) et que ton cluster fait 64ko bah t'as perdu 65534 octets
sur les disques RAID, ce qui marche bien, c de mettre la taille du cluster = taille du stripe. comme ça, on evite de lire inutilement des morceaux de cluster ou de stripe

Attention, G peur qu'il faille réinitialiser la matrice pour changer la taille su stripe (init = format obligatoire après :/ ... Je boote sur la matrice )