Reprise du message précédent :
La toute première lecture, elle se fait depuis la surface du disque, quels que soient les caches disponibles

OK, merci pour la précision.
Ma question est la suivante (en gros) : dans quel scenario une donnée peut-elle se trouver dans le cache du disque sans être déjà dans le cache de l'OS ? A mon avis, très rarement. Et donc le cache disque ne sert à rien.

Chez certain(s) fabriquant(s), l'interet des 8mo c'est trois ans de garantie contre 1 an pour les 2 mo

Oui. C'est pour ça que mon prochain disque sera un 8Mo.
La question n'est pas "qu'allez vous acheter ?" mais "pourquoi les constructeurs nous mettent-ils 6Mo de cache en plus qui ne servent à rien ?"

dans les benchs les disques 8mo arrivent devant les disques 2mo. Bien sûr ce n'est pas 4x supérieur. La différence n'est pas énorme et a le mérite d'exister. Il est intéressant de la prendre en compte lors de l'achat d'un disque 8mo, même si l'on sait que c'est partiellement mercantile.
 
Les disques équivalents au niveau mécanique avec un cache supérieur sont plus performants, c'est testé.

Oui je suis d'accord : si je fais un test du disque dur, forcément celui avec 8Mo est meilleur, puisque mon test inclut de faire tout un tas de petits accès pas du tout optimisés, pourlequel le cache intégré est salvateur. C'est un fait undéniable et que je n'oserais dénier.
 
Mais la question n'est pas là : maintenant les accès disque ne sont pas fait en bas niveau, mais à travers l'OS, qui lui utilise son propre cache disque. Il ne fait vraiment les accès au disque dur que quand son cache est pris en défaut. Donc ses accès sont rares et portent sur des blocs de données contigus, pour lesquels le cache intégré ne sert à rien.
 
La question est toujours la même : dans quel cas des données seraient présentes dans le cache du disque dur mais seraient absentes du cache de l'OS ? L'OS est-il tellement stupide dans son algo qu'il n'arrive pas à faire aussi bien avec 512Mo de DDR et un Athlon 2000+ qu'un malheureux contrôleur RISC/8Mo ?

"maintenant les accès disque ne sont pas fait en bas niveau, mais à travers l'OS, qui lui utilise son propre cache disque. Il ne fait vraiment les accès au disque dur que quand son cache est pris en défaut. Donc ses accès sont rares et portent sur des blocs de données contigus, pour lesquels le cache intégré ne sert à rien."
 
l'OS n'accède jamais directement au disque dur. Seul le disque sait où sont les données. L'OS dit je veux ça, passe par le traducteur "chipset de CM" et puis par le magasinier "chipset DD" qui va le chercher sur le disque puis le met sur le ponton principal "cache de DD" où le camion "bus IDE" vient le chercher et le met en stock dans la RAM (UDMA je rappelle, donc direct en RAM ). L'OS vérifie dans la RAM si ça convient. Si c'est ça, on prend, si c'est pas ça poubelle et on relance le processus. pouf pouf. Sans contrôleur pas disque. Le cache sert aussi à attendre le bus IDE.
 
"L'OS est-il tellement stupide dans son algo qu'il n'arrive pas à faire aussi bien avec 512Mo de DDR et un Athlon 2000+ qu'un malheureux contrôleur RISC/8Mo ?"
 
Ben des fois un petit bien spécialisé ira plus vite qu'un gros polyvalent.

On ne remet pas en cause le fait (c'en est un) que les disques avec un cache de 8 mo sont plus performants que leurs équivalents dotés de 2 mo  
La question est de savoir pourquoi

 
- l'OS demande de lire X clusters
- ceci se traduit par une lecture disque de Y secteurs
- le driver bas niveau demande la lecture du secteur N°1
- le disque reçoit l'ordre et lit le secteur 1
- le disque envoit le secteur 1 à l'OS/driver
- le disque sans attendre lit de suite les secteurs consécutifs suivants, N°2 et 3 et les met en cache
- pendant ce temps le driver de l'OS demande le secteur N°2
- le disque recoit la demande et envoi le résultat de suite puisqu'en cache. Toujours en avance de phase, il lit les secteurs 4 et 5...
- le driver de l'OS reçoit le secteur 2 et demande le 3,
...
et ainsi de suite. On voit bien qu'à un moment donné, l'OS n'a pas encore fait sa demande que la donnée est déjà en cache... non ? Plus le cache est gros plus le disque peut anticiper...

Certes, mais dans ce cas là, rien n'empêche l'OS d'agir de la même manière et de demander un peu plus de données que ce qui est réellement nécessaire

c'est ce que fait l'OS, mais le mécanisme que j'ai décrit s'appliquera de toute manière à un moment ou à un autre car l'OS ne sait pas où sont situées les données... l'OS n'envoit pas ses demandes de lectures read-ahead en parallèles, alors que le disque peut le faire durant le temps où la donnée est transmise sur le bus IDE vers l'OS...

voilà c'est ce que je disais

Un article de chercheurs de l'universite de Cincinatti publie en 2002 parle des caches:
 
http://parapet.ee.princeton.edu/~s [...] 84-zhu.pdf
 
In this paper, via detailed file system and disk system simulation
with realistic configurations driven by both real-world file system
workloads and synthetic micro-benchmark workloads, we studied the
impact of the disk built-in cache on file system response time when
the file system buffer cache becomes larger. With a reasonably sized
file system buffer cache (16 MB or more), there is very little
performance benefit of using a built-in cache larger than 512 KB. Our
results indicate that the current trend of using large built-in caches
is unnecessary and a waste of money and power for most users. Disk
manufacturers could use much smaller built-in caches to reduce the
cost as well as power-consumption, without affecting performance.
 
 
En gros, ils disent que ca augmente pas tellement les perfs dans des utilisations normales mais que ca coute plus d'argent.  

je viens de relire la tete du topic et les arguments de Glacote et au fond ja me demande si c'est pas le même principe de memoire tampon que sur les graveurs ce qui permet au fond un peu plus de souplesse d'emploi (peut etre d'ecrire des paquets plus regulierement ou de palier au deplacement des tetes etc...)
 
 

 
 
ben oui je viens d'arriver là et ça parait plus evident (merci )

 
16Mhz?? sources...
 
(Pas une plainte mais je suis assez surpris!)

Ah voilà du nouveau, merci; mais je n'ai pas bien compris :
> l'OS n'envoit pas ses demandes de lectures read-ahead en parallèles
non je ne crois pas en effet, il envoie plutôt une grosse requête portant sur une série de secteurs dont les numéros sont consécutifs (cf supra quant au rapport entre numéro de cluster et position sur le disque).
Que gagnerait-il à en faire plusieurs en parallèle, sinon rompre la "sérialité" des secteurs et donc obliger les têtes à se déplacer ?
 
> le disque peut le faire durant le temps où la donnée est transmise sur le bus IDE vers l'OS Pas compris.
L'OS demande au disque (via le south bridge) de lire les secteurs n°1 à 1000.
 
Le disque ne peut pas tous les avoir en cache (>> 8Mo), donc va devoir aller chercher la plupart depuis le disque. Supposons pour simplifier qu'il doive tous aller les chercher sur le disque.
 
Le contrôleur intégré traduit les numéros de secteur 1 à 1000 en leurs coordonnées physiques CHS [là je ne suis plus très sûr de l'impact des astuces genre LBA pour passer outre la limite de 528Mo].
 
Tu dis (si j'ai bien compris) que pendant qu'il va chercher CHS(1), ..., CHS(1000) le déplacement des têtes et le temps de traitement de chaque secteur sont tels qu'il pourrait aller chercher autre chose en parallèle, par exemple
CHS(1), CHS(50001), CHS(2), CHS(50002), ..., CHS(1000)
en supposant que les secteurs 1 et 50001 sont proches géographiquement.
 
Je prétends que la numérotation des secteurs est faite de telle sorte que le secteur CHS le plus proche du CHS(1) soit le secteur CHS(2), donc aller chercher quoi que ce soit d'autre obligerait à bouger les têtes ou retarderait le traitement de CHS(2) [gros ? ici : s'il y a plusieurs plateaux/faces, peut-être peut-on lire directement tous les secteurs de toutes les têtes en même temps; je ne crois pas à cause du traitement DSP qui empêche de traiter plusieurs têtes en parallèle, mais si tel est le cas, pourquoi ne pas mettre un DSP plus puissant plutôt que 8Mo de cache ?].
Par ailleurs, le débit physique est de l'ordre de 50Mo/s et la nappe étant limitée à 133Mo/s, le disque dur n'est pas ralenti par l'envoi des données sur la nappe. donc je ne comprends pas l'expression "durant le temps où la donnée est transmise sur le bus IDE vers l'OS" (je comprends OS = DDR-SDRAM via un canal DMA).
 
Ai-je mal compris ? Précisions svp ...
 
 

 
Merci pour ce benchmark pratique, qui en plus argumente pile dans le sens "le cache ne sert pratiquement à rien". Quantitativement parlant :
512ko de cache intégré + 128Mo de cache système >= autant de Mo que tu veux de cache intégré.
(source: début du paragraphe 2.2).

Je me suis effectivement toujours demandé à quoi servait le cache du graveur quand on a 650Mo de RAM (en gros, 128ko de cache devraient largement suffire, non ?)

un graveur est aussi fait pour écrire ... et malgrès les logiciels essayant d'éviter les ruptures de tranfert de données, le cache write back du graveur est tjrs considéré comme un bon temporisateur
 

Ben parce qu'avant y avait pas de burn proof, donc fallait surtout pas que les données arrêtent d'arriver. Un cache plus grand permet d'avoir un temps de rupture plus long. Par exemple avec mon graveur 8x avec cache 2 Mo, j'ai 1,14 seconde possible de rupture de données, et je peux te dire que sous Windows c'est pas beaucoup... (sous Linux c'est plus souple). Ben avec un 8 Mo ça m'en ferait 4,55s, c'est autre chose. Avec le Burn Proof c'est différent (il n'y a plus de risques pour le cdr), cependant la mise en pause du graveur et sa remise en route prennent du temps...

Tout-à-fait d'accord; cela dit les causes de rupture possibles sont :
1) le media source (disque dur, réseau, etc.) est temporairement saturé/indisponible.
2) le CPU est trop chargé pour traiter les données du fait d'autres programmes.
 
Tamponner les données en RAM permet de s'affranchir de (1): comme avec un disque dur, pourquoi utiliser une puce interne alors qu'on peut lire en avance les données et les garder en mémoire
(genre mkisofs ... > /tmp/tmpfs/image.iso où /tmp/tmpfs est de type tmpfs, c'est-à-dire RAM) ?
 
Quant au (2), avec un OS sérieux, il suffit d'accroître la priorité du logiciel de gravure (nice -10 cdrecord ...). De toute façon avec par exemple un Athlon 2000+ je doute que tu aies des problèmes de saturation CPU (j'ai déjà joué à Quake3 pendant une gravure sur mon 1800+).

 
Heu, le cache intégré au graveur, c'est utile pour éviter l'arrêt de la gravure quand les données ne parviennent plus au graveur ...
Que t'aies 32 Mo ou 2 Go de ram, si ton bus IDE est saturé et ne fait plus parvenir les données assez vite au graveur, sans cache c'est le plantage assuré.

Exact, autant pour moi.

Ben quand j'avais mon K6 ?©, j'avais essayé, sous Win2k Buffer underrun et sous Linux impec...

Attention merci d'éviter que ce topic ne dégénère en troll Win32/Linux
(ce post étant lui-même bien évidemment posté sous Linux) ...

 
Prenons le cas de mon graveur 16x Plextor IDE (en UDMA2):
 
---
 
Testé sur mon K6-III+ @600 Mhz sur Asus P5A (chipset Aladdin V):
Sous Windows (98/ME/2K), l'occupation CPU en gravant est très importante, la gravure plante dès que la vitesse dépasse 8x (et à 8x, le CPU est occupé à 90%)
Sous Linux, je peux monter à 12x, à 16x le CPU est trop saturé -> burn proof sollicité en permanence
 
---
 
Avec un Duron 600, sur Abit KT7 (Via KT133), le même graveur: je peux graver sous n'importe quel OS, en 16x, le CPU est occupé au max à 5% .
 
---
 
Ce n'est pas un troll Windows/Linux, juste une constatation: il semblerait qu'il y ait eu de gros progrès au niveau des controlleurs IDE sur les cartes mères récentes. Les différences observées entre Linux et Windows sont à mon avis liées au driver du controlleur IDE (sous Windows, le driver Ali IDE est un peu naze).
 
A noter que n'importe quel PC "récent" peux sans problème graver en 52x en IDE

Euh à mon avis t'avais pas le DMA sur ton K6... Avec le mien sur MVP3, ça prenait quoi ? 5 % maximum de graver en 8x...
Là je poste sous Slackware 8.1 installé dans VMWare 4 sur Windows 2000 (oui je sais c con, mais c pour le fun...)

 
Ali Power !  
Si si je t'assure que le graveur était en UDMA 2...
De toutes façons j'ai le même pb avec les disques durs (dès que le disque atteint +/- 15 mo/s, le CPU est à 100%)
 
Aladdin V

Bon, vu l'article cité dans le premier post, j'ai l'impression que 70% des votants ont tort ...
(ceci est un up).

 
Mais ca dépendrait aussi de l'utilisation du disque : si c'est le disque système ca doit quand meme faire plus gagner que si c'est une disque de données

Disons que en théorie ça sert à rien, mais étant donné les capacités actuels des os et contrôleurs de disques, et en utilisant des test pratiques (applicatifs) et non juste des tests de débits et temps d'accès, un cache de 8 Mo a quand même un intérêt certain... Il suffit de regarder le dernier test HFR pour s'en convaincre, et plus particulièrement le test 120 Go, ou le WD1200JB dépasse les disques plus récents (en test applicatif) alors que sa mécanique est plus faible...

rien que le fait que les données soient systématiquement fragmentées, le cache a son intérêt en lecture comme en écriture.

Bon, pour ceux qui pensent que le cache disque sert à rien et serait avantageusement remplacé par la ram, un peu de réflexion pourrait être utile : demandez-vous si ca vous arrive pas d'utiliser la ram pour mettre autre chose que des fichiers lus sur le disque...
Il n'est pas rare qu'en utilisation courante (jeux, au hasard) la ram soit utilisée au maximum, et le système a même parfois besoin de swapper sur le disque...
Si on vire le cache disque, je vous raconte pas la chute de perfs à laquelle vous allez avoir droit!!
Quoi qu'il arrive, le cache disque est indispensable, et la plupart d'entre nous pèterait un cable si on nous obligeait à bosser avec un pc dont le DD n'a pas de cache...

Je ne suis absolument pas d'accord. Vraiment pas.
J'ai un Athlon 1800+/nForce2 IGP/1Go DDR@133MHz; lorsque je joue à Quake3, j'ai encore plus de 200Mo de cache disque. Je doute que ton OS, même celui de Microsoft, soit assez fou pour réduire le cache disque à zéro pour gagner 1% de RAM en plus pour ton jeu. Même à l'époque du DOS 5.1 avec smartdrive il ne le faisait pas.
 
Quant à swapper c'est autre chose : tu peux très bien avoir un énorme swap (pour les programmes qui sont à l'arrière-plan) et simultanément avoir un gros cache disque (pour l'application au premier plan qui n'arrête pas de faire des accès au disque). En tout cas sous Linux.
 
PS: je rappelle que le contexte envisagé est celui d'un serveur de fichiers. En particulier le CPU ni le bus PCI ne sont pas censés être saturés, ni a fortiori la RAM.

Bon, ok, le système garde une partie de la ram pour le cache disque => il faut bien le remplir ce cache, non?
D'où lecture sur le disque => très lent, influe sur les perfs globales du système.
Avec du cache durectement intégré au disque, le disque peut mettre des données en cache à l'avance sans impacter les perfs globales...
 
Maintenant dans le contexte observé, tout serveur de fichiers n'a pas les mêmes besoins...
L'impact du cache ne sera pas le même sur un serveur gérant plusieurs milliers de connections simultanées et la petite machine qui sert de serveur ftp@home...
Dans le cadre d'un serveur ayant une utilisation intensive, je pense que le gain est non négligeable...  

Pas compris. Qu'est-ce qui est très lent ? Lire les données physiquement (pareil pour le cache intégré et pour l'OS) ou traiter (CPU) les données à lire ? Traiter les données, c'est grosso modo faire une requête DMA, donc ça ne coûte presque rien. Donc chaque fois que ton disque prend la décision de lire en avance des données pour les mettre dans son cache, qu'est-ce qui empêcherait l'OS de se faire la même remarque et de les demander au disque pour les mettre dans son propre cache en RAM ? A supposer que la nappe/le bus n'est pas saturé, c'est kif-kif. Ou plutôt c'est beaucoup mieux vu que la RAM va beaucoup plus vite/est beaucoup plus grosse que le cache intégré.
EDIT: comme je l'ai dis plus haut: donne-moi l'algo de cache du contrôleur intégré à ton disque, implémente-le au niveau de l'OS en utilisant la RAM et enlève (presque) tout le cache du disque (laisse 512ko). Tu auras au moins les mêmes performances (cf l'article cité dans le premier post).

 
Peut-etre que tout simplement l'OS n'est pas programmé pour   Mais alosr la question est pourquoi ne pas programmer l'OS en conséquence ?
Je dirais que parce qu'à l'usage, ca boufferait trop de RAM.

Pas vraiment, quitte à le limiter lui-même à 8Mo soit autant que le cache intégré.
Quant à savoir si l'OS est programmé pour ou pas, je prétends qu'il l'est (en tout cas le noyau 2.4 de Linux) et qu'il a bien raison : pourquoi payer 15Eur pour 6Mo (de cache intégré) alors qu'on peut avoir 128Mo (de RAM) pour le même prix !?

Là vous parlez de contexte en serveru de fichiers, mais je pense que le contexte initial étéit nos chers petits pc nan ?
Alors dans ce cas il faut pencher du côté de win, pas de linux (désolé, même si je l'aime bien).
Et si, win est assez fou pour réduire le cache à zéro ou presque ! J'ai fait un test : j'ai lancé plusieurs burnMMX jusqu'à saturer la ram, et là pouf! au bout d'un moment le cache système devient très petit... Très simple à faire !