Reprise du message précédent :

 
Pareil pour moi

les disques sont équipés d'un algorythme de recherche de données et, pour vulgariser, un système qui permet de deviner quelles sont les prochaines données dont le système aura besoin selon les données actuellement en transit dans le cache. En mettant plus de mémoire, la marge de fonctionnement est plus importante, le disque peu stocker plus de données "en avance". Dans le cas de tranfert de gros fichiers dont les octets sont un peu à droite à gauche du disque, cela va aller plus vite. Rien à voir avec de soit-disant fichier qui font 8Mo etc.
 
Ce n'est pas qu'une question de garantie

 
donc un hdd avec 2 mo de cache qui est défragmenté est aussi rapide qu'un 8 mo en vrac? et les 8 mo n'apportent rien de plus que les 2 mo dans le cas d'un disque défragmenté?
 
j'ai bien suivi ou po?

il y a un peu de ça ; bien évidemment, un disque défragmenté avec 8Mo sera tout de même plus rapide qu'un disque avec 2Mo dans le sens où plus de données seront tout de même stockées en cache et en cas d'erreur, la marge de manoeuvre est plus importante avec 8Mo qu'avec 2Mo.
 
Dans beaucoup de tests, même si on ne peut accorder qu'un crédit tout relatif à ceux-ci, les applications bureautiques sont boostées avec des disques 8Mo. La majorité des essais en viennent à la même conclusion

STOP !
Le fait de mettre en mémoire les secteurs qui seront probablement demandés à l'avenir, à la fois le cache intégré au disque ET le système le font.
La différence est que le contrôleur intégré a 8Mo de RAM et envoie ses données à 133Mo/s, tandis que l'OS a 300Mo de RAM à 4Go/s.
Donc on en revient au point de départ : pourquoi est-ce que le contrôleur intégré (avec sons processeur RISC et ses 8Mo de RAM à 133Mo/s) servirait-il à quoi que ce soit par rapport au système (avec son Athlon 2000+ et ses 300Mo de RAM à 4Go/s) pour ce qui concerne le cache disque ?
En toute logique, le cache ne devrait servir absolument à rien : tous les appels au disque sont cachés de façon très efficace par l'OS. Lorsque qu'il accède réellement au disque, c'est uniquement par gros paquets de secteurs contigus et qui n'ont pas été utilisés récemment (et ne sont donc pas dans le cache), puisque sinon l'OS les aurait encore parmi ses 300Mo de cache ...
Bref je ne comprends toujour pas à quoi sert le cache sur les disques durs ...

c'est justement parce que le bus est à 133Mo/s qu'un cache en amont est nécessaire. Il faut que ces 133mo/s soient exploités au mieux donc qu'il y ai le moins d'erreurs possibles. Et dans ce cas, au niveau du disque, ce n'est pas le système d'exploitation qui gère le cache. Pour ma part, c'est plutôt le cache système je vois comme superflu.

 
ben je pense que c'est pour la premiere fois ou tu y accede et qu'elles sont pas cachées dans la ram.
si ton dur est fragmenté, il va ramer le cake pour aller chercher tous les octets qui sont éparpillés de partout.
donc le cache s'en occupe et les envoie ensuite au cache ram... enfin moi je vois les choses comme ca

Pas compris : qu'est-ce qu'une erreur ? un défaut de cache disque ? Là je ne comprends pas, puisqu'il me semble que l'OS ne va faire que des accès par gros paquets de blocs contigus, puisqu'il a lui-même un cache pour s'économiser de faire tout un tas de petits appels au disque.

Moi je vois le fonctionnement comme ceci :
le proc demande des infos qui ne sont pas dispos en ram ==> dd.
 
Ces infos sont alors envoyées par de dd avec une vitesse de transfert de l'ordre de 40Mo/s (débit en lecture du disque)
Une fois fini, le dd charge dans son cache une partie de la suite de ce qu'il était en train d'envoyer. Si au coup d'après le proc avait besoin de ce qui est en cache : temps d'acces de qqs microsecondes et vitesses de 133Mo/s au lieu d'un temps d'acces de qqs millisecondes et une vitesse de transfert 4* moindre.  
 
Enfin, je peux me tromper, mais ca me parait logique

 
Pour moi un fonctionnement "logique" d'un cache, serait plutot de mémoriser les dernières données lues sur les plateaux afin d'être capable de les réexpédier plus vite en cas d'accès fréquents.
C'est donc en cas d'accès multiples qu'on y gagne en perf (temps d'accès).

arreter de pinailler pour 10? serieux      

 
C'est faux.

Je suis d'accord. Sauf que la prochaine fois l'OS ne redemandera certainement pas ces données dans le cache disque, vu que lui les a mises dans ses 300Mo de cache (RAM).
Donc AMHA à chaque coup l'OS redemande un paquet de nouvelles données, absentes du cache du disque, qui ne sert donc à rien.

 
il n'est pas question de pinailler pour 10? mais de savoir comment ca marche

Oui, et c'est pour ça que sous Sandra les performances brutes du disque sont meilleures avec 8Mo de cache.
Mais le principe pour l'OS d'avoir un cache disque, c'est précisément d'éviter de redemander fréquemment les mêmes petits blocs de données !

yaplukaecriraseagate ou maxtor

Pour que tout le monde comprenne bien ce que je veux dire :
chez moi avec 1Go de RAM (XP1800+/nForce2) sous Linux Mandrake 9.1, après avoir démarré et lancé mes applications (evolution, mozilla, OpenOffice, etc.), au bout de 15 minutes mes disques s'arrêtent; quand je crée une nouvelle fenêtre Mozilla/Ooo, le disque ne redémarre pas : l'OS a tout caché en RAM (jusqu'à 600Mo (!) de cache disque chez moi).
 
PS: Pour que ça marche il faut mettre l'option "noatime" au montage des partitions, et faire une "hdparm -S 241 /dev/hdXXX"

Bah non ils ont un beau produit marketing et des gens qui achètent (dont moi pour la garantie), donc ils ont raison. C'est comme Intel qui vantait l'accélération d'Internet avec leur nouveau Intel Pentium III optimisé pour la 3D ...

 
sté pareil avec le pédeu
 
nan serieux, il nous faudrait une reponse sure, parceque la ce ne sont qu'hypotheses et suppositions...

je fesai surtout reference au a la premiere page du topic, apres c sur, c bien de savoir comment ca marche  

directement, si. Et un peu de l'algorithme de recherche de données quand même
 
Le cache intervient après ; il entre en compte dans le débit du disque.

 
t'as 3 ans de garantie au lieu d'un an déja...
 
meme si il n'y avait que ca comme diference, moi je suis preneur...

il faudrais que je fasse un dessin là  

Bon, alors personne pour expliquer pourquoi 8Mo de RAM à 133Mo/s c'est plus efficace que 300Mo à 4Go/s ?
(ceci est un up)

ben si l'OS veut faire un cache qui anticipe la lecture : ce qui est lu en avance va saturer le bus IDE (requêtes + transferts); le débit réel est inférieur à 133Mo/s, et s'il ya deux disques on n'est pas loin de la limite..
 
et ça sera peut-être pas très efficace (disque dur qui doit traiter les requêtes et réagir par une lecture effective..)
 
 
peut-être aussi qu'il faut tout simplement un cache de chaque côté du bus IDE pour que ça tourne bien . ..

un petit dessin du net :
 

 
La raison pour laquelle le cache du disque dur est importante est due à la différence entre la vitesse du disque dur et l'interface du disque dur. La recherche de données sur le disque dur implique le positionnement aléatoire des têtes, et entraîne une pénalité  de quelques millisecondes pendant que le bras du disque dur est déplacé et le disque tourne autour de l'axe. Dans les PCs d'aujourd'hui, une milliseconde est c'est long
Sur un disque dur IDE, le transfert d'un bloc 4,096 octets de données à partir du cache interne du disque est 100 fois plus rapide que de trouver et lire l'information sur le disque.
C'est pourquoi les disques durs ont les caches internes. Si une recherche n'est pas exigée (par exemple pour la lecture d'une longue suite de secteurs consécutifs sur le disque) la différence dans la vitesse n'est pas très importante, mais le cache est toujours beaucoup plus rapide.
 
Dans le cas d'écriture sur le disque, un cache plus important sur le disque lui-même permet, à quelques millisecondes près de dire au système que toutes les données sont sur le disque alors qu'elle ne sont que dans le cache. Cela libère plus rapidement le système et la mémoire pour d'autres opérations.
 
Dans tous les cas, le cache disque système et le buffer du disque sont complémentaires et palient à eux-deux la relative lenteur du port IDE. De part et d'autre une grande quantité de cache permet de conserver un temps une plus grande quantité d'octets et libérer ainsi du temps et de l'espace pour autre chose. Gardons en tête les disques durs SCSI "professionnels" avec près de 16Mo de cache.

Merci pour cette réponse précise. Mais imaginons que dans le schéma ci-dessus je remplace le "cache" par la "RAM" : la seule chose qui change c'est la vitesse CPU => RAM (qui passe de 133Mo/s à 4Go/s) et la vitesse RAM => plateaux (qui passe de "beaucoup" à 133Mo/s). Donc qu'est-ce que _a change au niveau performances ?
PS: je suis par ailleurs d'accord qu'en pratique, plus de cache c'est mieux, mais je voudrais juste comprendre pourquoi.

Bahh j'imagine que "l'intéret du cache du disque dur" doit ressembler un peu a "l'intéret du cache L2 d'un CPU" en théorie ou mème en pratique??
 
j'vais essayer de trouver un article sur le net!

trouvé dans le génération PC de février 99 article Objectif Puissance écrit par Marc et Christian Marbaix!
 
"Le cache intégrée permet d'assurer un flux de données plus constant en agissant comme une mémoire tampon."
 
J'imagine que le grossissement du cache devient nécéssaire étant donné que les disques ont de meilleurs débits?? ATA133 contre ATA33, env. 40Mb\S contre env. 15Mb\s en 99...  

Ici sa as l'air plus complet!!
 
http://www.storagereview.com/guide [...] cache.html
 

Non, car il y a déjà le cache de l'OS.
La question est "l'intérêt du cache intégré au disque quand l'OS a déjà 300Mo de RAM à 4Go/s quand ta nappe est limitée à 133Mo/s".

 
En fait c pas une raison d'OS mais une raison de servir de buffer entre l'électronique du disque et sa mécanique!! Un peu comme le Cache de niveau 2 le fait entre le CPU ultra rapide et ma mémoire système untra lente... Seulement un intermédiaire! d'ailleurs je pense que l'Os se fout du cache du disque mais que ce cache ne sert qu'au Firmware du disque qui lui, peux savoir si la donnée que l'OS lui demandes est dans ce fameux cache ou si il lui faut pédaler sur le disque lui mème!!

Oui je suis d'accord. C'est précisément pour ça que je dis que le cache du disque ne sert à rien.

bien sûr que si
 
schéma rapide :
 

• disque dur :: données éparpillées
• chipset disque dur :: données récupérées et organisées non-compactées
• cache disque dur :: données récupérées organisées et compactées

On envoi ainsi le meilleur flux possible de données par le bus IDE. Celui-ci, optimisé, se retrouve ensuite dans le cache système en attente de traitement. Si les données étaient envoyées directement depuis le disque dans la ram, ce serait au processeur voire au chipset de la carte-mère de faire cette organisation et ce compactage. Cela aurait pour conséquence d'augmenter la charge processeur. C'était le cas par exemple au temps des technologies IDE PIO etc.

Si l'OS fait des requêtes vers des données éparpillées, le cache est utile. Mais si l'OS gère son propre tampon, il ne fait plus que des requêtes groupées, donc le cache ne sert plus à rien.
 
Sauf que, je suis d'accord, ça augmente la charge du CPU. Mais avec un CPU infiniment puissant, ca ne change rien, le facteur limitant reste la nappe à 133Mo/s, voire plutôt la vitesse de lecture sur les plateaux soit environ 50Mo/s.
Or je prétends qu'un Athlon 2000+, c'est "infiniment puissant" : les 50Mo/s passent par le chipset sans passer par le CPU (DMA), le CPU doit juste mouliner un peu pour déterminer quelles sont les données qu'il va demander au disque (par l'intermédiaire du contrôleur IDE). Et ça, ça ne coûte pratiquement rien.
Me trompes-je ?

super bien cette dicu    (et hop)

ça fait du bien de temps en temps

Mise-à-jour du premier post, pour synthétiser le topic.

 
+1
 
Quelqu'un sait comment modifier le cache du systeme sous windows? (le "cache disque" mis en ram)

Dites, j'ai pas tout lu ou pas tout compris, mais j'ai l'impression qu'il y a un mélange de "secteurs" et de "clusters" par ici ...
 
Ca m'étonnerait fort que l'OS mette en cache des secteurs du disque dur, par contre des clusters je veux bien.

Exact, autant pour moi.