Reprise du message précédent :
En même temps les Geek se branlent souvent non
 
Edit: et je doute que ton disque soit aussi silencieux que le mien en plus    

En même temps je m'en tape, j'ai passé la période des concours de bite avec les configs    
 
Bon, je dois en fait avoir une limite au niveau de ma config (hard ou soft) quand même :
 

 
Ça c'est avec un autre de mes disques (Hitachi Deskstar P7K500), plus performant globalement, ça se voit bien sur le buffered, mais le cached ne progresse pas

étrange en effet, y a un soucis qq part quand même là

 
Ah oui ça peut limiter le cached le CPU ?
 
J'ai un Core 2 Duo E6550 o/c de 2,33@3,1Ghz, et toi deK ?

Hein ? j'ai rien dit moi
 
Non en fait j'ai effacé parce qu'en fait (en tout cas sur ma machine) le cpu n'est vraiment pas ce qui limite.

 
J'ai quoté, trop tard   non sinon ok ça arrive a tout le monde de se tromper  

Oui je ne pense pas que ça soit le CPU, j'ai un C2D E4400@2,67Ghz, donc pas non plus un veau.
1066 de FSB, la ram idem, et pas vraiment de problèmes ailleurs niveau perfs.

 
Oui non là c'est sur que ta config va pas brider les transferts hdd, c'est plutot le hdd qui est loin des possibilités offertes par ta config a ce stade là (en tout cas d'un point de vue matériel)

Mais le problème n'est pas au niveau du HDD là c'est clair, vu que ça le fait avec un deuxième

Si je baisse la ram à 800, les perfs en cached baissent également vers 1200Mo/s, la limite est peut-être à ce niveau-là.
Mais je suis bien en dual-channel, mes timings sont corrects ...

Peut-etre un problème software parce que ça me parait vachement bridé là quand même par rapport a tout les posts des autres forumeurs, ou alors tu n'a que des disques particulièrement mauvais mais apparemment non c'est pas le cas...
 
Je donne ma langue au chat pour le coup
 
Edit: et tu as bien mis le pilote spécifique a ton controleur S-ATA et non un générique ?

Moi j'ai:

 
Et:

 
(J'ai aussi activer le JMicron mais ici on s'en fou)
 
Edit: et ceci n'est PAS activé:
 

 
Ni ceci:

 
(bien que ça n'ait pas du tout l'air de concerner le S-ATA mais bon)

Je tourne avec un kernel stock Debian  
 
Je suis en train de bencher ma config (avec Phoronix Test Suite), les résultats sont parfaitement normaux et les perfs sont excellentes au niveau de la bande passante RAM et de la puissance CPU. (tout à fait conforme à ce qu'on peut attendre de ma config quoi)
Ça localiserait donc plutôt le problème au niveau de la gestion des HDD.
 
Je vais essayer en compilant un kernel perso.

 
Excellente idée  

Je me demande dans quelle mesure les cached reads à 3, 4, 5+Go/s ne sont pas le résultat d'un bug ou du fait que l'algo de test avantage particulièrement certaines combinaisons de hardware.  
On a vu les résultats hdparm tripler d'un coup sans explication logique entre des configs similaires qui offrent des perfs pratiques du même ordre. Pour moi, c'est pas crédible.

C'est ce que je commence a me dire : avoir un résultat de débit disque en cached qui soit supérieur à la bande passante ram, c'est un peu chelou.

 
Alors si la bande passante ram influence le résultat (possible ?), ça explique pourquoi j'avais de nettement moins bon résultats avec ce même disque lorsque j'étais en DDR 400 ! (sur une 939NF6G-VSTA). Je suis désormais en DDR2 1066.
 
Edit: en plus je suis en Dual Channel et j'ai lu sur Wikipedia que l'interet de ce mode, c'est de doubler la bande passante justement...
 
J'ai une bande passante qui est de 8,5 Go/s par canal. (Dixit Wikipedia sur la DDR2 1066)
 
Donc on peut dire que mon disque dur a une bande passante très largement inférieur a la RAM quand même !

Entre les débits théoriques et les débits réels, il y a une marge

Sur P35, on est plutôt vers 6Go/s pour du dual-channel : http://www.hardware.fr/articles/67 [...] -ddr3.html
Ce qui ressemble étrangement à tes résultats de hdparm

Je trouve des chiffres comparables de BP mémoire pour ma config avec Phoronix Test Suite.

Maintenant, reste à savoir pourquoi hdparm me renvoie des résultats erronés de BP mémoire.

Le man de hdparm :

(ce qui confirme bien que l'on n'est pas du tout dans une mesure du HDD lui-même, mais uniquement du cache en RAM)

Tu es en 32 ou 64 bits ?

En fait c'est peut-être bien le cpu qui limite. Faudrait prendre un profile de la machine pendant le test, parce qu'avec top par exemple le test va trop vite et ne prend pas un interval complet dans top.
 
Ca dépend comment la lecture est codée dans hdparm, mais une lecture en mémoire ça peut prendre pas mal de cpu avec plein de system calls, et de gros copyout()s.

Je pense que l'algo cached reads de hdparm est tout simplement très dépendant de la quantité de cache CPU. Je serai curieux de voir ce que donne un penryn avec 3Mo par core.
Si c'est ce que je crois, ça rend le test aussi représentatif qu'un 3Dmark avec des drivers optimisés pour lui

Ben je sais pas mais chez moi j'ai un pic à 100% de cpu quand je lance hdparm -T. Pourtant j'ai un core2 duo E8500.

Ah, possible, piste intéressante  

Avec mon portable, j'obtiens des résultats qui ne contredisent pas cette théorie :

Pentium M Dothan donc 2Mo L2 (idem que mon E4400), et DDR2-533 en dualchannel (donc pile-poil 2x moins de débit théorique que mon dual-channel de DDR2-1066 sur le desktop), j'obtiens 800Mo/s à peu près, soit la moitié du score de mon desktop.

Je n'ai pas d'autre C2D à disposition pour tester sur ma config par contre  

Edit : j'ai aussi regardé du côté du speedstep, aucun changement si il est désactivé.

 
Pour ma part, ça ne dépasse pas 40% (j'enchaine 10 tests à la suite pour être sûr de voir le pic d'activité).

J'ai aussi un pic à 100% avec le proco qui passe en fréquence maxi à ce moment là.

Pour ma part, je passe en mode performance avant de lancer le test. Ca évite le changement de fréquence en plein milieu.
D'ailleurs, j'ai lancé le même test en powersave (CPU à 2.1Ghz au lieu de 3.2Ghz), j'ai des résultats identiques. Ce n'est donc pas la puissance CPU qui bride.

Mais ça justment c'est pas bon pour mesurer l'impact du cpu. La phase où les lectures sont faites ne représente qu'une petite partie du run complet.

Vu que mon graphique d'activité CPU est à 1/10ème de seconde, je pense que j'aurai au moins capturé un pic à 100% sur 10 run.
Hors chez moi, le CPU plafonne à ~40% pendant 2sec à chaque fin de run. En dehors de ça, il n'y a pas d'activité notable.

Je soupçonne l'influence du FSB aussi.

trouble_fete> pour ton OC, tu as du employer un assez gros FSB si je ne m'abuse ? (vu que ton cpu est à 1333 stock)
Tu pourrais essayer en mettant ton CPU à fréquence stock ?

Un ami obtient 3300Mo/s avec son E6550 (stock) sur P35-DS4.

Tu te prends trop la tête pour un bench synthétique. Quand bien même t'optimiserais ton score pour l'algo de test, ton système n'irait pas plus vite en usage réel.

Ah mais je ne me prend pas la tête, je veux juste comprendre ce qui influe sur le score    
Je sais très bien que je n'aurai pas plus chez moi, et j'ai bien compris que ça n'avait pas d'importance, tous les benchs sont normaux pour ma config et je suis très content de ses perfs  

Le 1er facteur qui est évident quand on regarde les scores/configs, c'est la taille du L2. Ensuite et probablement dans cet ordre d'importance:
 
- La fréquence RAM (bande passante mémoire incluant d'éventuels optimisations timings)
- Le FSB (bande passante CPU <-> RAM)
- La fréquence CPU (bande passante du cache CPU)
- La puissance brute du CPU (sans doute à mettre en corrélation avec la quantité de cache. Plus élevé est le débit final, plus la charge CPU est lourde)
- jouer sur le tRD devrait apporter un gain sensible
 
Avec évidemment l'incidence de bottlenecks si un des facteurs est très inférieur aux autres.

 
Oui j'ai beaucoup augmenté mon FSB il est je crois a 444Mhz, je n'ai joué QUE sur le FSB pour o/c a 3,1Ghz.
Et ma Gentoo est en 32 bits.
 
RAM a 1066Mhz en 5-5-5-15.
 
Jvais essayer avec le FSB d'origine.

J'en ai fait plusieurs a la suite @2,33Ghz, voici les résultats, sachant que comme je suis en synchro, ma RAM n'est plus qu'à 800Mhz:
 

Et maintenant 5 a ma suite avec mon FSB 444 en synchro donc RAM en DDR2 1066:
 

 
Mon Timing buffered disk reads est pas terrible cette fois, c'est un peu n'importe quoi ce test  

Je crois que c'est la conclusion qui s'impose

Grave...

Je viens de me rendre compte que mon CPU tournait à 2666 MHz au lieu de 3166 (multipicateur à 8 au lieux de 9.5 dans le BIOS). En passant le coef à 9.5 (18.8% plus vite donc), j'améliore les perfs d'environ 16% sur les chached reads :

Pour mémoire, à 2666 MHz j'obtenais :

Et j'ai toujours le CPU à 100% pendant le test. Donc chez moi c'est bien le CPU qui limite.

Mon ancien DD est mort    
 
Le ptit nouveau :
 

 
Ça torche, un Spinpoint F1 quand même  

Rescucitation de topic
 
Donc effectivement je ne peux en aucun cas battre un SpinPoint Formule 1, avec un bête samsung HD103UJ, ça m'a même l'air assez nul, même si comme déjà dit le test ne vaut que ce qu'il vaut...