Reprise du message précédent :
Au fait concernant mmap:
http://www.gnu.org/software/libc/NEWS
"Read-only stdio streams now use mmap to speed up operation by eliminating copying and buffer underflows"

Déçu, même le jour-à-troll personne ne veut plus jouer avec moi ...
Bon bah je vais aller poser ma question sur les forum de wanadoo.fr et msn.fr ...

intéret : la garantie 3 ans

 
je suis assez d'accord avec toi dans l'ensemble.
mais le fait est là: dans certains benchs les 8 mo sont sensiblement plus rapides que les 2 mo...
n'ayant pas trouvé de lien sur l'implémentation des firmware de HD, je crois que l'on va devoir tourner en boucle....

Bon bah merci à tous ceux qui ont bien voulu jouer avec moi ...
Je garde ces deux questions sous le coude :
 
1) comment sont agencés les secteurs physiques sur un disque, et pourquoi ?
   Est-ce que l'hypothèse "quand le disque a fini de lire le secteur physique de numéro LBA n,
   tout est prêt (têtes/actuateur/DSP) pour lire le secteur physique de numéro LBA n+1, situé  
   possiblement très loin" est vraie ?
 
2) Quel est l'algorithme qui recharge le page-cache lorsqu'une lecture physique est devenue nécessaire (demandes de nouvelles données pas encore présentes dans le cache) ? Plus précisément comment se fait le "read-ahead" lorsque le rechargement se fait depuis un disque dur, combien de données sont rechargées, etc. ?
 
Je reposte ici s'il y a du nouveau ...

Citation de http://www.suse.de/~bastian/Export/linking.txt
(on parle de charger une biblioothèque en mémoire).
"This is further optimized by the fact that the Linux kernel only loads parts of
the library (on a page by page basis) when these parts are actually used."
Autrement dit il n'y aurait aucun read-ahead dans la gestion du buffer-cache.
Oops pour la question 2 ? Il va vraiment aller le lire, ce fichu code source ...

Bah c'était pourtant facile à trouver:

On va bien voir ce que ça change ...

 
Tiens nous au courant, ça m'intéresse

ça risque de développer des performances pourries de foutre une aussi grande lecture par anticipation....

Bon désolé je n'ai plus trop le temps (en fait il faudrait faire
1) script qui met soit 3/31 soit +infini/+infini, par exemple infini=131072,
   au tout début du démarrage.
2) enregistrer une session avec beaucoup d'applis ouvertes.
3) démarrer avec 3/31, tout fermer et chronométrer le temps pour tout rouvrir
4) idem avec +infinity/+infinity
Ca permettrait d'avoir un avis sur les capacités du cache de l'OS en utilisation desktop.
Pour l'utilisation serveur, une autre machine qui fait en boucle (100 fois) des accès à 4Mo  de fichiers par NFS constituerait un joli benchmark.
J'essaierai plus tard, là pas le temps.
 
Au passage (http://216.239.51.104/search?q=cac [...] r&ie=UTF-8)

et l'indispensable Léa:
http://lea-linux.org/admin/optimise.php3?little=ok
 

mesurer l'impact du read-ahead lors d'un relancement d'une appli n'est pas la bonne chose à faire.
 
si tu lances une appli, puis tu mesures le temps à la relancer, à priori quelque soit le read-ahead, l'os lira tout depuis le cache.
 
le read-ahead a une influance sur le chargement des données non-cachées auparavant, et si il est trop grand, en multi-tâche où plusieures appli font des accès disques en concurrence un read-ahead trop grand peut avoir des répercussions négatives sur la souplesse du système.
 
glacote > tu peux faire un purgage explicite du caches entre les étapes ?
 
(purger le cache avant chaque lancement de session chronométré ?)

 
1) Je suppose qu'un

va notamment vider le cache, mais pas sûr (?)
 
2) Quelqu'un veut essayer de faire des timings (plus de machine chez moi, pas le temps au boulot, et en plus comme ça je ne serai pas de parti pris) ?
 
3) Répercussions négatives si read-ahead trop grand : OK. Il faut chercher par tâtonnements une valeur plus raisonnable, genre 1024 (soit 4Mo avec des pages de 4ko).

alors ca sert ou pas?
 
ca serait bien de maj le premier post (qui date de 2 mois...)

 
je plussoie    
 
une conclusion objective rédigé par tous serait le bienvenue    
 

Dans le pratique ca sert, point.
Après glacote essaye de nous démontrer qu'on pourrait s'en passer mais:
1) ca reste de la théorie.
2) on n'a aucune preuve que ca marche.

Désolé plus le temps. Je ferai des tests fin septembre quand j'aurai acheté mes disques pour mon RAID-5 (4 ou 8 Disques, pas décidé). J'essairai de prendre des 2Mo et des 8Mo.
EDIT: skeye OK. Conclusion: donnez-m'en une, je la copierai-collerai.

http://forum.hardware.fr/message.p [...] formulaire
Bon apparamment:
1) le command queueing (= utiliser un gros cache (ex. 16Mo dans le benchmark) pour réorganiser les écritures) améliore considérablement les perfs. (+30% ?)
2) c'est déjà fait au niveau software dans le noyau Linux.
Bon, qui veut bien aller les lire, ces fichus fichiers sources ?

glacote, ça devrait te faire plaisir ça:
 
http://www.materiel.be/news.php?start=0#news2749

Ok, cf mon post juste au-dessus.
Cela dit, ça n'explique toujours pas pourquoi, ça veut juste dire au mieux
que l'argument "oui mais en pratique le cache est utile" est faux.
Moi, c'est sûr que j'aimerais bien avoir raison, mais je voudrais surtout savoir
pourquoi: command queueing en ide ?? ordonnancement des secteurs LBA/secteurs physiques ?
implémentation sous Linux/Windows du cache disque ?
Bref, dès que j'ai fini mon water-cooling pour disques, j'achète des disques, et là je m'y mets sérieusement (benchmarks, avec/sans cache, etc.).

D'ailleurs, quelqu'un connaît-il un disque de > 160Go qui existe en version avec 8Mo et 2Mo de cache ? Pas trouvé sur rue-montgallet.com ...

 
ben l'Hitachi Deskstar 7K250 arrive, en 160Go (et 120) PATA il existe en 2 & 8Mo de cache...
pareil pour le Maxtor DiamondMax Plus 9 les 80,120 & 160Go PATA existent en 2 et en 8Mo
 
PS : super post  

fatigué le gamin !!      
 
j'avais pris le > pour =
apparement tout ce qui est + de 160 en PATA a 8Mo et pareil avec le SATA...  

C'est un peu ce qui m'embête ... j'ai bien un 120Go 2Mo, mais pas l'envie d'acheter une 120Go 8Mo juste pour faire des tests.
Alternativement, est-ce que quelqu'un sait comment désactiver partiellement le cache
d'un disque (genre modifier son BIOS intégré pour lui faire croire que c'est
un 2Mo, même s'il embarque 8Mo). J'accepte que la modification soit
irréversible, tant que le disque reste utilisable.

Simple constatation :
 
Il y a 4 ans, les HD faisaient 10 Go et les bonnes séries étaient dotées de 2 Mo de cache. Les plateaux tournaient à 5400 trm, la densité des plateaux étaient 20 fois inférieure, et les débits moindres d'autant.
 
En informatique on s'apperçoit vite que passer de 2 Mo à 8 Mo est ridicule par rapport au reste des chiffres. Le plus ridicule dans l'histoire, c'est que 8 Mo sur un bus SATA ça correspond grossomodo au temps d'accès d'une tête, et qu'en lecture continue, la densité actuelle des HD permet de plafonner sans problème à quasi la vitesse du bus. Deplus, les fichiers font très rarement moins de 8 Mo (mise à par quelques images et MP3 qui ne nécessitent pas de vitesse de lecture/écriture élevée, qui a des fichiers aussi petits sur son disque ?) donc le cache sera insufissant pour éviter une lecture ou écriture physique sur le disque pour complèter les informations à transfèrer.
 
Sur les cartes RAID, on trouve maintenant du cache jusqu'à 2 Go (et plus sur les très gros matos) ce qui a un sens par rapport au volume d'information qui transitent par le bus.
 
En bref, pour voir un changement significatif de vitesse, il faudra avoir un grand minimum de 256 Mo de cache par disque.
 
Passer de 2 Mo à 8 Mo, c'est comme décider de fixer une amare de paquebot avec un clou plutôt qu'une punaise : dans l'absolu, d'un point de vue purement mathématique, oui, ça tiendra beaucoup mieu. Seulement, ce qu'on lui demande de supporter est infinimenent plus élevé, et au final ça change rien. A la première vaguelette, le paquebot et ses 10000 tonnes va virer votre clou. La c'est à coup de DivX de 800 Mo que vous allez un peu faire fumer votre malheureux cache de 8 Mo
 
Donc, 2 Mo ou 8 Mo changent rien

Meci pour ces remarques

Argument intéressant.
Cela dit:
1) "on sature le bus": pas d'accord, on en est à 50Mo/s en lecture max.
2) "presque tous les fichiers font plus de 8Mo": bof.
C'est en particulier faux le plus souvent pour les .mp3/.ogg, les .doc/.sxw, les .html,
les .jar/.java/.c/.cpp, les .so/.dll, etc.
De toute façon ce qui compte c'est combien d'accès aléatoires tu vas faire: sur gros fichier de xxx Mo lu séquentiellement le cache ne sert à rien, il est utile lorsqu'il te permet d'éviter des rotationnal latency. Donc dans le cas ou tu enchaîne un grand nombre de petits accès.
3) La question fondamentale est surtout de savoir si on ne pourrait pas remplacer le cache intégré par la RAM. Je pourrais te refaire le même argumentaire à l'encontre des cartes contrôleurs avec 2Go de cache intégré ...
 
 
 
 
 

Ce que je voulais dire, c'est surtout que le volume de données transfèrées est incoparablement plus important que le cache. Hors, sur un seul petit fichier de 3 Mo, que tu le charges en 0.01 s ou 0.1 seconde, ça change absoluement rien. Par contre, si tu as 200 Mo de fichiers à transferer, si ton cache fait 8 Mo, tu vas avoir aussi peu de chances (pour de 1/1000) pour que ton cache contienne un fichier dont tu vas en effet avoir besoin.
 
Parceque le cache, c'est bête comme choux : quand le HD lit un fichier, il continue à lire physiquement jusqu'à ce que le cache soit plein, ce qui fait que lorsqu'il passe au fichier suivant, il a une chance pour que le fichier soit déjà chargé en cache. Mais là, 8 Mo comparé à un disque de 250 Go qu'on trouve aujourd'hui, je te laisse faire le calcul... Ca change rigoureusement rien que tu aie 2, 8 ou 32 Mo. Faudrait bosser avec au moins 128 Mo pour avoir une chance quele cache serve de temps en temps.
 
PS: dans tout les cas, quelque soit la taille du cache, avoir un disque défragmenté impactera les perfs de façon bien plus significative que le cache physique, tout comme le cache logiciel (qui lui, sur mon PC atteinds par moment 1 Go) est bien plus significatif que le cache physique dont le fonctionnement est inadapté à l'utilisation des disques durs. Les gains notables se font sur les lecteurs dont les temps d'accès sont très lents, et pour un rapport cache/taille du disque de l'ordre du %, comme les CD.

OK, merci.
1) je ne suis pas sûr que le cache intégré soit purement "read-ahead".
  En tout cas le cache de l'OS sûrement pas, il le fait au moins
  au niveau des secteurs (= lit en avance les prochains secteurs du fichier
  en cours, qui ne sont pas forcément ceux qui suivent le dernier secteur
  lu: fragmentation ...)
2) comment fais-tu pour mesurer ton cache disque (sous Win32) ?
 
 
 

Bah tu regardes la mémoire occupée, et la taille de tous les programmes qui tournent, la différence est pour la majeure partie la taille du cache.
 
Et surtout, quand tu copies un CD entier sur le disque sans faire un seul accès disque sauf tout à la fin de la copie, tu en déduit que le cache est d'au moins 600 Mo

l'argument taille d'exploitation/taille cache n'est pas valable à partir du moment ou tu fonctionnes avec un read-ahead où le firmware essayes d'exploiter des patterns prévisibles....
 
sur un cpu, tu traites bien plus que ce que le cache peut contenir, et la présence du cache a une importance critique.
 
en fait le soft de maxtor reviens dans un sens à ce que l'on disait, le cache générique d'un OS ne peut pas connaitre les specs du matériel du HD pour en tirer parti.
 
après j'avoues que j'ai pas essayer le soft de maxtor pour voir comment il se comporte....

 
pas d'accord. les caches matériels et logiciels fonctionnent par ligne/bloc, et si tu fais un accès disque, le firmware ne va pas non plus invalider tous ses blocs/lignes de cache au moindre read-head.
 
justement le firmware doit segmenter dynamiquement sa RAM, en fonction de tampons d'écritures, bloc déjà chargés, et zone de read-head.

Ca sort d'où, ça ? C'est peut-être vrai, mais là je ne comprends pas.
Peut-être que le fait que MaxBoost ne marche qu'avec les Maxtor est
purement marketing, mais pas sûr.
En tout cas je voudrais bien comprendre ce qui soutient cet argument
(qui est effectivement le point central de la discussion).

Petit cross-linking:
http://forum.hardware.fr/forum2.ph [...] 0#t2749420

et encore c'est pas evident je suis tombé sur un maxtor 150go 8mo de cache garantie 1ans

 
+1

Comme je disais sur l'autre post la!!
 
en cache écriture, sa fais un bon gain...    
 
Celeron 2.1Ghz
Asus P4P800
dual Channel
1Gb de Ram
DiamondMax +8 40Gb
 
Buffered Read => 45Mb\Sec
Sequential Read => 55Mb\Sec
Random Read => 7Mb\Sec
Buffered Write => 431Mb\Sec            
Sequential Write => 47Mb\Sec
Random Write => 11Mb\Sec
Average Access Time => 6ms
 
Screenshot disponible sur demande  

en quelques lignes de théories improvisées, tu arrives à démontrer le contraire de ce qu'on constate en pratique!
d'ailleurs d'après toi le cache disque sert à quoi?
à regarder un film en divx 2 fois de suite en ne le lisant qu'une fois?
a titre indicatif, la taille moyenne d'un fichier dans mon répertoire windows (XP) est de 122Ko.
il faut savoir que quand windows rame, en général il fait plusieurs accès simultanés au même disque.
un test simple: dupliquer un fichier de 600Mo sur le même disque, avec un chrono. En général le débit est incroyablement + lent que les 50% qu'on pourrait espérer si le disque passait réellement la moitié de son temps à lire et autant à écrire.
rien que l'ouverture d'une page web, ça crée plein de petits fichiers, parfois parrallelement à une modification du fichier swap.
pourquoi?
simplement parce que le disque passe une grande partie de son temps à déplacer les têtes de lecture.
 
on peut aussi se demander pourquoi les 6 Mo supplémentaires sur un disque de 8Mo donne un gain appréciable alors qu'on a des centaines de Mo de cache dans la RAM principale qui est + rapide.
La raison est la même.
Le cache disque de windows est mal géré, pas la peine de chercher + loin. Quelque soit la gestion de son contenu, il ne regroupe visiblement pas les ordres de lecture et d'écriture avant de les envoyer au disque. Sinon une telle chute du débit serait impossible lors d'accès multiples au disque, sinon cette fonction serait inutile sur les disques SCSI, et sinon les 8Mo de cache intégrés ne serviraient à rien face à l'énorme cache de windows.
La solution?
Au lieu de proposer un cache intégré couteux, on peut très bien prendre un peu de RAM du PC (rapide et pas chère, pourquoi se priver?) pour grouper les commandes d'écriture et de lecture, qui contiennent généralement beaucoup de clusters successifs, le but étant d'en réunir suffisemment pour que la tête passe + de temps à traiter des clusters contigus qu'à se déplacer.
 
un exemple de réorganisation des ordres donnés au disque:
On lit 2 fichiers non fragmentés en même temps, le disque a un débit de 40Mo/s et un temps d'accès de 10ms, et les clusters sont de 8Ko.

• premier cas: pas de cache intégré.

on lit un cluster (8Ko, 0.2ms), on déplace la tête vers l'autre fichier (10ms), on lit un cluster (8Ko, 2ms), on retourne au premier fichier (10ms).
Total: 20.4ms, 16Ko. Débit effectif: 784Ko/s!!!

• avec 2 Mo de cache utilisés idéalement:

on lit 2Mo soit 256 clusters (50ms).
on déplace la tête vers le 2è fichier: 10ms.
on lit 2Mo: 50ms.
on retourne au 1er fichier: 10ms.
Total: 120ms, 4Mo. Débit effectif: 33Mo/s.

• avec 8 Mo de cache:

on lit 8Mo (200ms), on déplace la tête (10ms), on lit 8Mo (200ms), on déplace la tête (10ms).
Total: 16Mo, 420ms. Débit effectif: 38Mo/s.
 
Dans ce cas on voit qu'avec 2Mo on commence à exploiter pas trop mal le disque, mais on y gagne quand-même avec 8Mo.
 
Les disques IDE ne font malheureusement pas cette réorganisation, windows non plus (ou très mal), alors l'utilitaire de maxtor, s'il le fait, arrive à point pour combler ces lacunes.
 
En attendant, on est bien obligé de constater que le cache intégré sert quand-même à quelquechose, sans doute parce que même sans réorganiser les commandes qui y parviennent, il permet sans doute de lire par anticipation pour se rapprocher un peu du cas que j'ai décrit (chose malheureusement impossible pour l'écriture). L'usage n'étant que la lecture par anticipation explique sans doute pourquoi on ne trouve pas + de 8Mo, au-delà on perdrait surtout du temps à remplir le cache sans savoir si ça sert à quelquechose.

OK je suis globalement d'accord.
En un mot, plus le cache est près du CPU, mieux c'est.
Donc mieux vaut l'avoir en RAM (derrière le north-bridge) que sur le
disque (derrière North bridge + south bridge + une nappe à 133Mo/s).
Je voudrais juste savoir:
1) quel est l'algo de read-ahead et celui de réorganisation des écritures
   de win32 ? Celui du noyau Linux 2.4 ?
2) Comment convertir secteur physique <=> secteur logique LBA. Si c'est
   trivial, pourquoi le cache des OS n'est-il pas infiniment plus performant ?
   Si cette conversion est complexe/inconnue de l'OS, alors c'est sûr que
   le cache intégré est utile. Autre façon de se poser la question:
   MaxBoost est-il réservé aux Maxtor pour des raisons marketing, ou
   parce qu'il tuerait les performances avec d'autres disques ?

Saviez vous qu'il y a des disques durs 2.5" (portable) avec 16Mo de cache ?

peut-etre p[our eviter de faire bouger les tetes, et d'eviter de ce crois l'echauffemetn ? la perte inutile d'energie ?
a voir

Pour avoir testé deux disques identique mais l'un avec 2 et l'autre 8mo et bien la différence éxiste... enfin surtout dans les benchs......  
 
Sinon plus rapide comme disque d'exploitation et pour la différence de prix......

 
attention, ça sent les écritures cachées alors qu'elles ne devraient pas.
 
au niveau OS, tu peux demander à faire des écritures volontairement cachées ou volontairement non cachées, et normalement les benchs demandent des accès non cachés....
 
il y a longtemps à la sortie des premiers chipset UDMA, Intel avait fait un driver UDMA qui cachait même quand on lui demandait pas, un disque UDMA explosant un SCSI
 
forcément à l'époque Intel avait dit que c'était un bug, le reste du monde pensait que c'était une triche (c'est marrant comme les choses se répétent )