Reprise du message précédent :
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 !

Bon, j'ai lu l'article fourni dans le 1er post...et je ne suis pas convaincu! Tout ce que ca permet de conclure, c'est que dans les conditions qu'ils ont utilisées, et avec les applis qu'ils ont utilisées, ca ne change pas grand-chose d'augmenter le cache au-dessus de 512ko...
Ce que je reproche à cet article c'est que l'on ne sait finalement quasiment rien du protocole de test, et que les résultats sont p-e tout à fait différents avec d'autres applis ou d'autres disques, par exemple...
Pour moi il y a évidemment une part de marketing dans l'augmentation du cache sur les disques actuellement, mais il en résulte réellement une augmentation des perfs grâce à une baisse du pourcentage de "page manquante", i.e d'accès disques immédiat à effectuer...je pense que le temps d'accès moyen s'en ressent, ainsi que la réactivité globale du système...

Je suis tout à fait d'accord avec toi ! J'ai aussi lu l'article, et tous les tests qui apparaissent correspondent à des tests théoriques, et ne correspondent pas tellement à l'utilisaton pratique que nous faisons de nos pc (ils répètent sans cesse : "real-world", c'est ça oui !). En plus le protocole de test n'est pas indiqué clairement, on ne peut pas le reproduire nous-même. Or un bon benchmark doit toujours être reproductible !

OK pour les critiques (en particulier, quel est précisément le protocole de test ?).
Cela dit je réitère mon argument : donne-moi l'algo du gestionnaire de cache intégré au disque et implémente-le au niveau de l'OS.
 
Tu y perds :
- coût CPU : négligeable car DMA ...
- utilisation de la RAM (bah oui mais bon vu le prix ...)
- encombrement de la nappe/du bus pendant la mise en cache : neutre car ce que je mets en cache aujourd'hui je ne le lirai pas en encombrant la nappe/le bus demain.
EDIT: Sauf bien-sûr sur une machine avec beaucoup (> 2) de disques, car là le facteur limitant n'est plus la lecture physique des secteurs mais l'encombrement permanent des nappes/bus, alors que le cache disque  intégré n'est pas limité et n'encombre le bus qu'avec les données effectivement demandées.
- efficacité de l'algo : pas de raison de perdre quoi que ce soit. A la limite l'OS peut raisonner au niveau fichier et donc faire une meilleure prédiction des prochains secteurs à lire (si le disque est fragmenté, les secteurs à lire seront par exemple 37-89-101 et le cache disque chargera les secteurs 37-38-39 ...)
 
Tu y gagnes :
- taille du cache (8Mo -> 300Mo)
- vitesse du cache (133Mo/s -> 4Go/s)
- et le prix, éventuellement (mais bon 15 Euros on s'en moque un peu ...)
 
Donc à mon avis, en théorie, avoir plus que 128ko-512ko de cache ne sert à rien. Quelle que soit l'utilisation, à supposer effectivement que l'OS garde assez de cache disque en toutes circonstances.
 

 
vous oubliez juste un détail : l'OS ne demande pas toujours à lire de gros blocs... Ma remarque s'applique à plusieurs demandes OS de petite capacité. N'oublions pas non plus que l'OS fait ce que les appli lui demandent...
 
[citation]
> 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 ../.. en supposant que les secteurs 1 et 50001 sont proches géographiquement.
[/citation]
 
Non je dis que pendant que l'électronique du disque transfert les données de son cache vers la RAM, une lecture peut être lancée et exécutée en parallèle...
 
[citation]
> 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 ../.. 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 ?].
[/citation]
 
c'est possible mais tu n'en a aucune preuve réelle... seul le disque le sait (cas des réallocations de secteurs défectueux, en plus il faut prendre en compte la mécanique multi-plateaux, multi-têtes des disques pour vraiment savoir où se trouve le CHS(x))
 

T'es marrant toi ! Fais-le toi-même... Si ça a pas déjà été fait, c'est sans doute parce qu'il y a une raison. Faudrait demander à quelqu'un qui développe le cache d'un os, chez linux par exemple...

Pas tant que ça ! 10% quand même à 40-50 Mo/s, moi je trouve pas ça négligeable !

Y a pas que le cache lui-même qui compte, mais justement l'algo : je pense que lui doit en prendre de la place en mémoire, sans compter que prédire les données doit prendre aussi plus de temps cpu...

Et c'est là que ça devient intéressant : les systèmes utilisés en serveur sont majoritairement scsi, et le serial ata va être chainable de la même manière...

Ce n'est pas du tout le cas sur les os actuels (enfin windows quoi). Sans compter que ce genre de prédiction a un coût : en temps cpu, mais aussi en ram, car l'algo pour faire ça doit être un minimum compliqué. Or en info pour l'instant ce qui marche le mieux c'est ce qui est le plus simple ! Par exemple tu regardes linux à côté de windows nt, il y en a un qui est bien plus léger que l'autre et pourtant bien plus efficace...

Sur nos petits pc, sans doute, mais sur un gros serveur (auquel tu tiens tant), la ram est souvent utile à autre chose...

Sur un système idéal, je n'en doute pas, mais sur nos pc actuels avec le windows actuel, c'est tout autre chose...
EDIT:Ah ! enfin j'ai réussi à faire marcher les citations...

J'ajouterais une dernière chose, si elle n'a pas été dite: il ne faut pas négliger que le disque met en cache des données à l'avance, en prévision de requetes qui n'arriveront p-e jamais...
Dans le cas du cache en ram on se retrouve avec un volume de données faramineux qui transite par le bus pci et se retrouve stocké en ram dans le vide...!

bien vu !
en revanche moi les citations multiples j'y arrive pas encore...

 
en fait, je me suis trompé, c'est 33 Mhz pour le UDMA-133, 16 c'est pour le 66. (et 25 pour le 100)
 
calcul :  
33 Mhz * 2 (technologie DDR) * 16 bits (transferts //) / 8 (1 octet c'est 8 bits) on obtient 133 Mo/sec.
 
 
pour le serial ata c'est 1500Mhz (sisi)  
 
1500 * 80% (efficacité du transfert série, du au info de controle) / 8 (1 octet c'est 8 bits) on obtient 150 Mo/sec.
 
 
les infos viennent de onversity www.onversity.com
 
 
pour ceux qui disent que du risc+8Mo soit moins performant que du X86 rapide + plein de DDR :
 
lancer un jeu récent qui utilise le Transform&lightning.
 
désactiver ensuite le T&l et regarder le score. un processeur spécialisé fait toujours mieux qu'un processeur généraliste.
la voodoo5 est un bon exemple. sur un processeur léger (en dessous de 2Ghz) elle fait moins bien que le geforce2GTS, au dessus, elle commence a montrer sa puissance. et pourtant, sans T&L, les 2 cartes se valent, mais sur un processeur léger (type PIII 600) et avec un jeu T&L, la voodoo est larguée.
 
a mon avis, le processeur risc et ses 8 mo fait ùmieux que l'athlon XP et ses 512 Mo, en plus l'OS (que ce soit linux ou Windows) ne fait pas nécessairement de la meilleur facon.
 

En fait il faut aussi remettre le nom de celui qui a écrit, sinon ça marche pas. Faut faire exactement comme le forum fait tout seul la première fois, sauf que les chiffres qu'il rajoute sont pas nécessaires... (en fait je sais pas à quoi ils servent)

La réponse de nurgle me plaît beaucoup, c'est un point auquel je n'avais pas pensé ! En plus l'exemple Voodoo5/GF2 est particulièrement bien choisi !

[citation]chips-disqueman[/citation]
> Merci de tes remarques ...
 
T'es marrant toi ! Fais-le toi-même... Si ça a pas déjà été fait, c'est sans doute parce qu'il y a une raison. Faudrait demander à quelqu'un qui développe le cache d'un os, chez linux par exemple...
> C'est précisément pour ça que je le dis : tout le but de ce topic est de trouver cette raison ...
 
Pas tant que ça ! 10% quand même à 40-50 Mo/s, moi je trouve pas ça négligeable !
> 10% de charge CPU en transférant à 50Mo/S ? JE ne suis pas sûr mais ça me paraît énorme. J'aurais dit < 5%, à comparer non pas à 0% mais à ce que tu aurais si tu lisais depuis le cache. On ne compte pas le temps de traitement des données ici, mais le temps à décider (gestion du cache) quelles données charger ...
 
Y a pas que le cache lui-même qui compte, mais justement l'algo : je pense que lui doit en prendre de la place en mémoire, sans compter que prédire les données doit prendre aussi plus de temps cpu...
> Je ne suis pas du tout d'accord. Le code d'un gestionnaire de cache, c'est 10000 lignes à tout casser et donc < 64ko de RAM. Quant au temps de traitement encore une fois, c'est le temps de trouver les données à charger préventivement, pas le temps de traitement de ces données. Donc pas grand'chose.
 
 
Et c'est là que ça devient intéressant : les systèmes utilisés en serveur sont majoritairement scsi, et le serial ata va être chainable de la même manière...
> Ca c'est possible. Pas d'avis sur la question, vivement le PCI-X ...
 
Ce n'est pas du tout le cas sur les os actuels (enfin windows quoi).  
> Je croyais que smartdrive (Dos 5.1) faisais exactement _ça, mais je peux me tromper.
 
Sans compter que ce genre de prédiction a un coût : en temps cpu, mais aussi en ram, car l'algo pour faire ça doit être un minimum compliqué. Or en info pour l'instant ce qui marche le mieux c'est ce qui est le plus simple ! Par exemple tu regardes linux à côté de windows nt, il y en a un qui est bien plus léger que l'autre et pourtant bien plus efficace...
> D'accord avec le principe général, mais pas ici : cf la complexité du scheduler O(1) sous Linux par exemple ...
 
Sur nos petits pc, sans doute, mais sur un gros serveur (auquel tu tiens tant), la ram est souvent utile à autre chose...
> OK OK, mais je dis: plutôt que de dépenser 15 Euros pour 8Mo de cache disque, achète 128Mo de RAM ! Enfin mon topic cherche surtout à démontrer (si c'est vrai) que l'argument des 8Mo de cache est purement marketing.
 
Sur un système idéal, je n'en doute pas, mais sur nos pc actuels avec le windows actuel, c'est tout autre chose...
> Bah vu que 512Mo de DDR@133Mhz coûtent environ 50 Euros, autant  se lâcher sur la RAM. Quitte à faire en sorte que l'OS l'utilise aussi pour le cache disque.
 

Je suis d'accord sur le fait que ça fait consommer de la bande passante pour des données qui ne seront peut-être jamais utilisées.
Cela dit si l'OS n'est pas trop fou il ne fait ces requêtes-là que quand le disque n'est pas surchargé (?). En revanche pour l'encombrement mémoire, pas d'accord : ça encombre tout autant le cache intégré au disque. Si ça ne te vas pas, recompile ton kernel en fixant le cache disque en RAM à 8Mo, et voilà ...

Tout-à-fait d'accord dans le principe. Mais la comparaison me paraît absurde : l'objet du T&L c'est d'appliquer un filtre (très) simple à un gros voulme de données. Ici encore une fois le CPU n'est pas censé traiter les données. Il s'agit juste d'exécuter un programme sophistiqué qui choisit quelles données charger à l'avance, ce qui sera fait par le contrôleur IDE du south-bridge via un canal DMA sans passer par le CPU.
Donc il ne s'agit pas de répéter un petit programme sur un gros volume de données, il s'agit de faire un "raisonnement" sur quelques données statistiques : tiens la table d'allocation me dit qu'après le cluster/inoeud 27 viendra le 35, qui est stocké dans le secteur n° 517, si j'allais le chercher en avance ...

L'avantage de proceder par simulation est que tu as un controle total sur l'environnement. Un bench sur du vrai materiel peut etre influence par des milliers de facteurs (mauvais driver, temperature de la piece, rayons cosmiques...).  
 
Plus serieusement, un bench reel ne pourrait etre fait serieusement sans connaitre exactement la strucutre physique du disk (fragmentation? nombre/position des tetes? fichiers en debut de plateau?...).  
 
Encore pire, si tu compares 2 disk, un avec cache de 2Mo, un avec 8Mo, il faut etre certain que les algos de gestion des requetes sont identiques (chercher sur google les articles sur les disk scheduling policies genre FCFS, SCAN, CSCAN-LAi).
 
 

Ils citent 5 workload qu'ils ont utilises. Ca sert a simuler des requetes au disk. Je ne sais pas si ces workloads sont representatifs de ce que nous faisons avec notre disk, il faudrait les etudier en detail pour ca. Mais bon, je sais meme pas ce que nous faisons avec notre disk...
 
 

 
 
Il s'agit d'une publication scientifique, elle est limitee par le nombre de pages disponibles lors de la publication. Si tu veux des infos complementaires, envoie un mail gentil aux auteurs. Dans les references bibliographiques de la fin, la [4] indique qu'ils ont publie un rapport de recherche qui lui devrait etre beaucoup plus complet.
 
La question n'est pas de savoir si le cache disk est util, ca je crois que tout le monde est d'accord pour dire oui. La question est de savoir si en mettre beaucoup ameliore les perfs dans la vie de tous les jours. Un bench qui consiste a copier 20go d'un DD a un autre ou de faire des requetes au max des capacites ne me semble pas trop representatif.  
 
Si les 8Mo accelerent un peu une operation que je fais 1 fois par mois, je prefere ne pas investir dedans.  
 
Loozerz

 
Dans le cadre d'un serveur de fichier ca risque de pas être trop souvent...
Et il n'y a pas que le(s) disque(s) sur le bus PCI...!
 

L'encombrement du cache intégré au disque on s'en tape, il est là uniquement pour ca! Et ajouter de la ram pour pallier à une "faiblesse" de cache du disque je trouve ca douteux comme démarche...heink:

 
pourquoi tu as de la RAM sur ta carte graphique?
1/ (surtout maintenant) parceque c plus rapide que la RAM systéme,
2/ parceque ça évite de bouffer de la RAM systéme
3/parceque ça évite de plomber le bus PCI qui s'occupe aussi de l'IDE et qui plafonne à 133Mo/sec.  
4/ spécifique au disque) parceque comme ça a été dit plus haut ça évite de faire appel trop souvent au systéme disque qui est "lent" comparé au reste du systéme.
donc le disque a une ram dédiée (disponible, rapide) à laquelle il accéde par un bus dédié (pas le PCI), n'encompbrant le bus commun (PCI) que pour ce qui est nécessaire: recevoir les infos à écrire et envoyer celle qu'il avit à lire.

Dans le cadre d'un serveur de fichier ca risque de pas être trop souvent...
> Pas d'accord : le disque ne mouline pas en permanence à 50Mo/s.
 
Et il n'y a pas que le(s) disque(s) sur le bus PCI...!
> OK, au pire il y a :
- carte réseau : ça ça tire effectivement un peu (12,5Mo/s)
- carte son : négligeable
- carte vidéo : a priori elle est AGP ...
 
 
L'encombrement du cache intégré au disque on s'en tape, il est là uniquement pour ca!
> Bah oui mais si ça encombre 8Mo sur mes 1024Mo je m'en tape; si ça en encombre plus, c'est que c'est plus utile ...
 
Et ajouter de la ram pour pallier à une "faiblesse" de cache du disque je trouve ca douteux comme démarche...
> Bah non, c'est bien là le coeur de mon argument : au lieu de payer 15 Euros pour 8Mo de cache tout pourris, mieux vaut acheter 128Mo de DDR@133MHz qui tuent ...
 

Tu mets une carte son sur un serveur  
 

 
Mais alors si on pousse ton raisonnement à bout : autant acheter 200Go de RAM pour avoir TOUT le contenu de ton/tes DD en RAM, comme ça t'as plus de perte de temps pour les acces disque

la comparaison avec la carte graphique me semble plutôt juste pour étayer notre point de vue sur le côté utile du cache disque.

Ce qui est une excellente solution  
Le seul problème, c'est qu'1 Go de RAM coûte plus cher qu'1 Go de disque dur  
Ce n'est pas forcément le cas pour le cache des disques

Sauf qu'une carte vidéo consomme jusqu'à 1Go/s quand ton disque est limité à 50Mo/s ...

Bah oui sur mon serveur de fichier j'ai /bin, /sbin, /lib (les fichiers systèmes de base) et /var (les logs, etc.) sur un RAMDISK de 128Mo. En revanche, avoir mes 200Go de copies de sauvegarde de ma musique qui risque sa vie à la moindre coupure de courant ...
EDIT: et je n'ai évidemment aucune carte son, c'était pour figurer le pire cas ...

 
:lol: super:lol::lol:
oublies pas d'acheter un super onduleur quand même

 
je dirais même 25Go/s pour une carte vidéo

oui mais si tu as 133Mo/Sec sur le PCI et que tu en bouffes déjà 50Mo/sec (tu tires ça d'où dailleurs? lkes dernier DD font bien plus de 50Mo/sec...), il en reste d'autant moins pour tout le reste: réseau etc....

 
Et l'onduleur, ca sert à quoi ?  
 
Mais l'idée extème c'est au démarrage de tout copier en RAM  
 
Non, mais plus sérieusement, je sais pas pourquoi 6Mo sont visiblement un plus pour un disque système.

Source : http://www.hardware.fr/articles/414/page5.html

de  tte façon ce dont on parle c'est les perfs du disque dur
 
et ya pas que le débit
 
un disque a un temps d'accès horriblement long : un million de fois  plus long que celui de la RAM
 
je trouve donc plus intéressant de tomber directement sur une donnée préchargée dans le cache du disque dur que de faire une lecture physique

OK. Sauf que
- carte(s) réseau(x) : 2 x 100Mb/s = 25Mo/s
- carte son (??) : 1Mo/s
- carte modem (adsl quand même !) : < 6Mb/s < 1Mo/s
Bref, tout ça c'est marginal. Le vrai facteur limitant, c'est le nombre de disques durs : au-delà de 2 disques à fond (RAID0, chacun sur sa nappe), on sature le PCI. C'est le seul intérêt qui reste aux contrôleurs RAID hardware.

OK, tout le monde est d'accord la-dessus, la question est de savoir si tu mets le cache avant ou après la nappe IDE ...

Que le gain soit nul pour des copies de gros fichiers c'est normal : par principe l'intérêt du cache c'est d'éviter les latences; quand on lit des gros fichiers contigus (sur une partition défragmentée), essentiellement on lit à la vitesse maximale du disque (50Mo/s), sans latence ou presque.
 
Quant à savoir pourquoi parfois c'est mieux d'avoir 8Mo que 2Mo,
j'aimerais bien comprendre en effet ...
PS: celui qui me répond "parce que 8Mo > 2Mo, il sort". Celui qui me répond parce que le cache évite la rotational latency, pareil. Merci.

On parle de perfs ici  
Et puis tu as le même problème pour le cache du disque : tu as intérêt à l'écrire sur le disque avant de couper l'alimentation

+1

 
 
pourtant la réponse est bien "parce que 8Mo > 2Mo"

 
on tourne en rond là
 
et comme on l'a dit 43 fois sur ce topic l'OS ne connaît absolument rien de la structure physique du disque (peut-être que c'était plus simple du temps du DOS qui laissait tout le boulot au bios...)

 
L'article d'Hardware, c'est rapport au sondage : tu a dis a la page précédente que 70% des votant se trompaient. Mais non, en fait, ca dépends juste de l'utilisation du disque.  
 
Désolé de ne pas faire avancer le schmilblick

sans doute ; en plus on sait pertinement que même NT ne s'octroie pas le droit d'accéder directement au matériel (heureusement dirotn certains )
 
Enfin bref.

Bah non, je ne crois pas : la question est de savoir si tu mets ces 6 Mo dans le cache disque ou si tu mets 300Mo dans la RAM pour faire la même chose. Qu'est-ce qui sera le plus efficace ?

 
Il faut aussi faire le matériel en fonction de ce que l'OS sait faire Si ton OS ne gère pas directement le matériel, ton idée de cache en RAM ne tiens plus

Ah bon ? Pas compris. Les secteurs physiques sont numérotés pour que lorsque tu viens de finir de lire le secteur n° n, les têtes et l'actuateur sont prêts à lire le secteur n° n+1. (Ca ne marche pas avec les secteurs défectueux réalloués de façon transparente, mais c'est un faux problème car tu n'auras jamais plus de 1% de tels secteurs réalloués; et puis c'est pathologique. Si le cache 8Mo ne sert que quand on a beaucoup de secteurs défectueux alors je m'en moque, je préfère changer de disque pour mon serveur de fichier.)
Donc l'OS fait l'hypothèse que quand il en est à lire le secteur 1325, il peut pour un surcoût modique lire les secteurs 1326 à 1345, et il a raison. Donc je ne vois pas ce que le contrôleur peut faire de mieux (ou alors j'ai raté quelque chose ?).

C'est vrai ça ? Je croyais qu'il squizzait le bios (mais je peux me tromper) ... En tout cas Linux se moque complètement du bios à ma connaissance (faillible encore une fois).