Reprise du message précédent :

 
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 )

wave > un mot, achète-toi de la RAM.
 
perso, quand je charge une page sur le net, j'ai à peine un accès disque (qui doit correspondre à la mise à jour du cookie). Les éléments qui se mettent en cache normalement restent dans mon cache de windows, et n'en bougent qu'à la fermeture de IE.
 
franchement, windows, je le démarre une fois, et je le rédémarrer le jour où il y a eu une coupure de courant. et pour celui qui l'allume en arrivant le soir et qui l'éteinds avant de se coucher, ça change pas grand chose non plus. après, tes 20 millions de fichiers de 1 Ko qui sont dans ton répertoire de windows, tu les lis quand ? faut arrêter la fumette. quand tu utilises un programme, c'est pas les fichiers de 2 Ko qui sont les plus solicités, mais généralement le swap qui réduit les performances, et ce sont de gros volumes qui sont écrits/lus sur le disque à chaque fois. a ce moment, un gros cache disque est un gain précieux, mais ridicule à côté du gain d'un peu plus de RAM. ça me fait marrer de voir certaines machines rammer tout ce qu'elles peuvent quand on ouvre word... alors que chez moi, d'une semaine sur l'autre, word s'ouvre sans faire un seul appel au disque, tout simplement parceque windows à préféré conserver une image en mémoire, même si word était fermé.
 
ensuite, comme tu l'as très bien démontré, passer de 2 à 8 Mo ne change pas considérablement la vitesse du disque (super, 10%). Par contre, atteindre une taille bien plus importante, comme ça se fait sur une carte RAID, ça va permettre d'augmenter la probabilité de ne pas avoir à déplacer la tête du disque, ce qui apporte cette fois un gain immense, puisque non seulement tu économise un temps d'accès sur le disque, mais en plus, pendant que tu traîtes les données qui sont dans le cache disque, tu peux envoyer la tête chercher un autre fichier.
 
sinon, ton exemple est êtrement mauvais.
 
imagine une base de données. là tu as une réelle application de ce qu'est le cache, et en quoi ça apporte quelquechose...
 
un fichier de 20 Go
jamais tu vas pouvoir le charger dans la mémoire qui ne fait que 512 Mo
 
tu recherches des lignes qui sont épparpillées dans le fichier.
 
avec un cache de 2 ou 8 Mo (soit un rapport de taille de 1/100000), tu as donc moins d'un dixième de chance pour cent que tu puisse lire deux infos dans le fichier en même temps.
 
avec un cache de 256 Mo, rapport 1/10...

 
oups honte à moi, les buffered write doivent correspondre aux écritures cachées, et les sequential write aux non cachées
(enfin ça n'annule pas la remarque sur la possbilité de tricher en cachant même quand on le veux po)

 
la question n'est pas de favoriser les appli qui lisent des Go, c'est d'optimiser les petits accès entrelacés que tu peux observer dans un contexte multi-tâche (et non dans un contexte audio/vidéo, ou d'une base de données ou tu balayes des tables séquentiellement)

excuse-moi, mais une bdd c'est certainement ce qui est le plus multi-thread et multi-accès qu'il est possible d'imaginer...
 
mise à part pour un serveur de base de données, j'ai jamais encore vu de serveur nécessiter un système nécessitant une forte montée en charge des disques...
 
quand t'as 10000 utilisateurs qui font en moyenne 1000 accès concurrents aux disques, avec des transactions, là ton hd est solicité... c'est pas quand tu joues à quake...

tu es en train de me dire que 8Mo ça sert pas à grand-chose, que je ferais mieux d'en acheter 1Go. Tu trouves pas ça comique?

1)pour win32: de la merde. pour linux je sais pas mais a moins ça a des chances d'évoluer dans le bon sens.
2)normalement 2 secteurs successifs se suivent physiquement, la preuve on entend pas la tête de lecture lors d'un formatage. Ce qui est largement suffisant pour faire une réorganisation des lectures ou écritures.
Sinon mets-toi à la place de mator: tu as la possibilité d'améliorer tes produits. Vas-tu le faire gratuitement pour les produits des concurrents? celui qui fait ça il mérite l'ANPE à vie.
d'ailleurs les vieux disques maxtor n'ont pas été concus dans le but d'être utillisés avec un tel soft alors...
si ça marche bien les concurrents sortiront leur soft, et on aura enfin des drivers digne de ce nom pour les disques durs sous windows, depuis des années qu'on torture les têtes de lecture juste pour faire du bruit.

 
 
Vachement constructif comme argument

je sais pas s'il y a un moyen de connaitre l'algo, alors en attendant je juge au résultat.
 
explique-moi comment 8Mo de cache sur un disque (lesquels sont bridés par le débit de l'interface IDE) sont souvent + efficaces que les centaines de Mo de cache disque qu'alloue windows.

On ne sait quasiment rien sur la manière dont est utilisé le du cache disque, mais tu réussis quand même à en déduire que windows gère mal son cache disque  
 
Pour celà, il serait nettement plus utile de comparer l'écart de performances apporté par l'augmentation du cache entre windows et Linux.
(mais ca n'a rien à faire sur ce topic)

euh... installe MSDOS et n'active pas smartdrive, après on en reparlera... Le cache logiciel de Windows accélère mille fois plus les accès disques que le cache embarqué. Franchement, arrête de dire des conneries.
pour avoir justement du SCSI, et donc des drivers qui me permettent d'utiliser pleinement le U3W de ma carte, je peux t'assurer que quand smartdrive est inactif, mes disques se traînent plus que mon lecteur de CD quand smartdrive est actif. Et c'est incomparablement plus rapide sous Windows que sous MSDOS, et ça vient pas seulement de l'architecture 32 bits ou de l'utilisation de plus de fonctions du CPU, mais bel et bien d'amérliorations importantes de l'algo.
 
sinon, désolé, mais peut-être que cela vient des versions de Windows que j'utilise (Windows 2000 Server, et maintenant Windows 2003 Server) mais pour avoir eu de gros problèmes de disque dur (un HD m'a lâché) je peux t'assurer qu'une fois Windows démarré, à condition d'avoir un minimum de RAM, y'a plus un seul accès au disque. je m'explique :
j'ai un disque pour windows, un autre pour la swap et d'autres pour mes programmes/données. mise à part quand je vais sur internet, où à cause des cookies il écrit régulièrement sur le disque, je ne fait jamais un seul accès disque sur mon disque système. preuve en ait, c'est que mon disque système qui est mort a pour symptôme que lorsqu'il se met en veille, il est impossible de le redémarrer sans rebooter la machine. hé bien tant que je n'accédait pas au net, je n'avais aucun problème pour utiliser mon PC. Tant que le cache de windows n'est pas saturé, et que windows lui-même n'a pas besoin de swaper comme un porc, les fichiers restent présents en mémoire, et c'est rare que windows modifie ses propres fichiers, donc pas d'écriture non plus.
 
ensuite, qu'est-ce que tu entends par utilisation "quotidienne" de windows ? parceque là moi je sèche. je vois pas quand j'ai besoin d'attendre mes disques, y compris mes deux HD IDE qui n'ont pas de cache à ma connaissance. le démarrage de windows ? ha ouais... c'est vrai que là j'attends. sauf que dans le pire des cas tu le fait une fois par jour (ou alors pense à réinstaller ton système...) et après ? quoi d'autre ?
 
un MP3 se lit à une vitesse comprise entre 96 Ko/s et 160 Ko/s pour la majorité. Un lecteur de D7 est capable de soutenir la cadance.
 
un divx se lit à raison de 600 000 Ko / 3600 s = 166 Ko/s. A nouveau, un lecteur de D7 suit.
 
sorti de ça ? changement de niveau d'un jeu ? chargement des textures ? si c'est lent c'est que tu swapes mon vieux, parceque ça fait des années que j'attends pas plus de 5 secondes pour charger un niveau dans un jeu... je vois pas ce que tu veux gagner là dessus. et si tu swap pendant que tu joues, j'imagine même pas comment tu dois ramer en permanance, et c'est loin de venir du disque, mais du système derrière qui patine pour libérer des ressources. sorti de ça, tu fais quoi avec ton PC ? de l'imagerie ? on n'est plus à l'époque des goupils... une image de 20 Mo se charge instantanément depuis n'importe quel disque, même sans cache.
 
alors quoi d'autre ?
 
là où le cache pourrait d'être bénéfique, c'est pendant une défragmentation, qui en effet est l'application qui en tirera le plus parti. m'enfin je doute que tu passes tes soirées à défragmenter ton disque... en puis essaie de faire des lectures/écritures sur le disque pendant la defragmentation qu'on rigole... ouais, cache de 0, 2 ou 8 Mo, ce sera la même donne, dès que tu fais des accès multiples ta grande théorie ne tiens plus, à cause de la taille du cache qui ne permet pas d'avoir suffisament d'occurences où il te fera gagner un accès disque.
 
donc oui, je répète, passer de 2 Mo à 8 Mo est inutile. 2 Mo est amplement suffisant pour les traîtements mono-accès, et 8 Mo n'apportent rien au traîtements multi-accès. a partir de là, seul un cache très volumineux peut t'apporter quelquechose, ce qui n'est pas envisageable si c'est embarqué dans le disque.
 
c'est pas la peine de débattre sur le sujet, fait le calcul toi-même.
 
 
et pour info, j'aime pas ta remarque quant à l'inutilité d'avoir autant de mémoire si c'est pour bosser avec quelques Ko. tu ne sais pas du tout ce que je fais de mon ordinateur, alors tout comme pour le coup de l'algo du cache de windows, quand on sait pas, on la ferme au lieu de dire des trolls à deux balles.
 
ah, et en dernier... si je fais de l'encodage intensif de divx, ça changera rien à ce que j'avais écrit précédement : windows utilise autant de caches qu'il y a de disques, et par conséquent, vu que je ne bosse jamais sur mes disques systèmes, je ne touche pas à leur cache, il ne seront jamais pollué par des fichiers de travail. c'est un peu une règle d'or quand on fait ce que je fais dans mon travail... même découper le disque en partitions pour séparer le systèmes, les applications et les données de travail te fait gagner énormément en performances.

 
calme...
son raisonnement n'est pas parfait, le tien non plus !
et jusska present il y a eu de nombreux bons post, vachemetn interressants !
mas sdepuis kk posts ca se degrade.. et je ne tire aucuns renseignements dignes de ce nom...
si vous voulez vous disputer sur un sujet ,libre a vous, mais essayez plutot de faire kkchose de constructif, et ce pour le bien de tous
c pas mechant, le prensd pas pour toi, mais c juste ke trop c trop..
 
desole d'avoir pris ton message com exemple
 
++ all  

Bravo, ta théorie contredit tous les tests de disques durs de tous les sites de hardware, sauf peut-être ceux qui lancent juste un bench de débit pur.

 
oui, mais les serveurs de base donnée peuvent eux-même incorporer un système de cache au niveau application (car les performances disques sont prises en considération dès la conception)
 
alors qu'un panel d'appli normales, qui ne font qu'ouvrir lire/écrire et fermer un fichier ou peu de fichiers à la fois, MAIS tout ce ceci en concurrence chargent plus le sous système disque de l'OS (dumoins se reposent plus sur...) ....

 
c'est pas faux, mais il ne faut pas oublier que le cache OS élimne les transferts sur l'IDE (ou que le bus HD que ce soit de l'IDE ou du SCSI).
 
sans cache OS donc cache hit au niveau HD:
 
read appli => OS => accès HD (transfert IDE/SCSI) => recherche cache firmware HD => retour HD (transfert IDE/SCSI) => OS => appli
 
avec cache OS en cas de cache hit au niveau OS:
 
read appli => OS => recherche cache OS => appli
 
à l'époque du DOS, vu la lenteur de transfert sur l'IDE, le fait de l'éliminer permet un gain notable... (après les disques IDE de l'époque avaient que de chi en taille et des DSP de firmware pauvres ne performance interne => donc algos pauvres)
 
et pour les OS multitâches c'était pire, puisque pendant qu'un process fait un accès disque, en IDE en mode PIO, le transfert disque est bloquant. (alors qu'avec un transfert non bloquant au niveau noyau, pendant que le noyau charque le bloc l'ordonnanceur donne le timeslice à un autre process)
 
--------------
 
résonnons sur un autre sujet (en fait le miens celui que j'essayes de défendre depuis le début):
 
1) pour moi le cache HD sert énormément pour les read-aheads (et non le stockage massif des secteurs déjà lu)
 
2) le firmware en ayant connaissance du hardware local au HD, en étudiant les types de requetes de lecture, et en applicant des stratégies de read-head dynamique en fonction des éléments précédents, permet d'augmenter les performances globales dudit disque (via des read-ahead finements placés en terme de temps: utilisation des temps morts entre des accès, et en terme de zone: read-ahead qui fait la continuité du derniers accès, ou tout read-ahead à partir d'un secteur qui a été déterminé par algo+stats des accès précédents)
 
ensuite indépendamment de ça:
 
si l'on considère que le disque fait du read-ahead basique ou évolué, à même "fenêtre de temps mort" où le firmware décidera d'un read-ahead, un disque qui physiquement lit 2 fois plus vite qu'un autre, aura dans la même fenêtre de temps lu 2 fois plus de trucs.
 
donc à mécanique plus performante, même configuration de "temps morts" (au niveau accès OS), même stragtégie de read-ahead, plus de cache sera rempli.
 
d'où: il est fortement probable qu'au fur et à mesure de l'augmentation des performances mécaniques, un cache HD doive plus au moins croitre parallèlement...
 
-----------
 
tout ceci, en précisant que le cache HD ne remplace pas le cache OS, mais qu'ils sont complémentaires bordel de mairde
 
---------
 
désolé si j'ai dit des conneries

ensuite un point interressant est celui levé par wave (qui était aussi un point initial soulevé par glacote en parlant du noyau linux), savoir si le fait d'avoir des répercussions entre 2 mo et 8 mo de cache est lié au fait que les algos de cache de Windows sont pourris (vu que quasiment tous les tests sont sous Windows), et donc que les fabricants de HD font des HD 8 mo de cache pour les Windosiens vu la manne commerciale qu'ils représentent....
 
donc il faudrait trouver des benchs en utilisation desktop (pas de base de donnée, pas d'audio/vidéo) sous Linux entre un HD de même mécanique en version 2 Mo et 8 Mo pour savoir si ce que j'ai dit plus haut est relativement recevable, ou qu'effectivement hormis buffering de transfert, le cache HD peut être philosophiquement et algorithmiquement remplacé par le cache OS.

Perso je pense pas que les algo sous windows soit plus pourri que les autre. Honnetement quand je suis sous nux je swapp bcp plus que sous 2K

Peut être que c'est du plutot à une gestion différente du swap  
Il me semble que les Unix ont une approche complètement différente à celle de Windows pour la gestion du swap

 
+1 je pense ke c pas trop comparable..

Je pense que pour les OS "clients" (Windows 9x/Me/XP) en effet c'est très différent, mais pour les OS Servers, si on laisse les paramètres par défaut, on doit grandement s'approcher de la gestion de la swap de Linux/Unix.
 
Notamment, ouvrez un Windows 2000 ou un Windows 2003 qui a pas mal de RAM.
 
Ouvrez une application, puis une autre, puis une autre, et encore une et... jusqu'à ce que vous ne puissiez plus rien ouvrir.
 
Vous allez vous appercevoir que généralement, au moins 40% de la RAM est toujours libre, alors que le SWAP s'est bien remplie.
 
Au premier abords, on se dit que Windows gère mal la mémoire. Puis on réfléchit : dans une appli de 200 Mo, y'a peut-être 10 Mo qui sont réellement utilisés à un instant t. Windows met en swap tout le reste, afin de libérer la mémoire pour les données de travail, qui peuvent arriver en volume extrêment important d'un seul coup (ouverture d'un fichier volumineux par exemple). Hors, un fichier de travail, va clairement ralentir la machine si on ne peut pas accéder à sa globalité d'un coup. Donc Windows conserve de la place pour ça.
Linux swap comme un con tout le temps exactement pour la même raison. Quand on ouvre un soft comme un player de DVD, y'a 25 codecs qui sont chargés au démarrage, une chiée de menus, alors qu'on se sert d'un seul codec et d'aucun menu pendant la lecture. Donc au bout de quelques instants il va foutre en swap tout ce qui est inutilisé dans l'appli, afin de conserver de la place en mémoire au cas où on veuille ouvrir une deuxième vidéo.

 
oui, mais tu sais "jusqu'a vous ne puissiez plus rien ouvrir" ça peut aller très loin si tu n'as pas mis de butée dans le swap.
 
après pour la gestion du swap c'est souvant le même chose, quand l'OS a besoin de pages mémoires pour un process, il envoyes les pages mémoires les moins utilisées dans le swap.
 
et on est complètement hors-sujet, c'est pas de swap dont on parle.

nan, j'ai dis "jusqu'à ce que vous n'ayez plus rien à ouvrir"
 
et sinon, c'est justement la différence entre les OS "client" et "server" : les OS client attendent d'avoir besoin de swaper pour le faire, tandis que les serveur le font au fur et à mesure.
 
avec mes 2 Go de RAM, au démarrage de Windows, j'ai 154 Mo de RAL d'occupés, et 200 Mo de swap occupée. avec XP, t'as 300 Mo de RAM occupée, et quand t'arrive à 512 Mo de programmes chargés en mémoire, ça commence à rammer à mort parceque le système ne vois rien venir et ne libère pas de mémoire de façon préventive. du coup, tu passes ton temps à lire sur le disque à la même vitesse que tu écris, puisqu'il doit écrire autant sur le disque de swap qu'il ne lit de données à mettre en mémoire. avec un os server, il fait ça en tâche de fond, dès que la charge du bus disque le permet. prends un windows 2000 server après l'install sans rien toucher.
ouvre le gestionnaire des tâche pour voir l'occupation mémoire. ouvre un truc volumineux genre powerpoint.
ne touche plus à rien.
va boire un café. quand tu vas revenir, tu vas voir que powerpoint occupe à tout casser 5 Mo en RAM, il a foutu tout le reste en swap.
avec 2000 Pro, ça marche pas. cet OS comme XP passe son temps à rammer car il ne voit rien venir.
 
-- vi mais le swap tire grande partie du cache disque

là je suis d'accord de toutes manières un nt/2k/xp server est par défaut en mode serveur au niveau "optimisation", donc effectivement il doit chercher à conserver les pages mémoires des services au dépends des applis.
 
par contre justement non: le swap peut tirer parti du cache HD mais certainement pas du cache OS sinon il est implémenté comme une merde. (conserver le swap en cache OS ou en ramdisk est une aberration logique)

vivi, je parle bien du cache disque hard.
par contre, à condition qu'il soit sur un disque à part. s'il est sur le disque de travail, au contraire, non seulement le swap tirera peut profit du cache, mais en plus va plomber à 100% les ressources système. par contre, ce qui est effrayant, c'est que lorsqu'on a un disque dédié au swap, alors l'utilisation intensive du swap ne fait que très peu ralentir le PC. c'est assez logique, mais j'ai du le voir pour croire à quel point le gain est énorme (c'est comme passer d'un disque sans cache du tout à un disque avec 2 Mo de cache, le jour et la nuit)

là je suis d'accord....
 
mais là on diverge du topic

c'est pas très étonnant, le principal défaut étant la chute de perfs dès qu'il y a plusieurs accès au même disque. Si le swap est sur un disque qui ne sert à rien d'autre, il profite du débit maxi du disque au lieu d'avoir le débit ridicule qu'on a en accès multiple (surtout en IDE).
par contre quand tu dis que les versions client de windows ne voient rien venir, c'est pas exact, mais simplement elles le font plutôt pour la quantité de RAM d'un utilisateur moyen, alors que les versions serveur sont plutôt configurées pour TA quantité de RAM. L'échelle n'est pas la même, mais le principe semble proche, peut-être même identique.
Sur un OS client, on peut quand-même se retrouver avec une application dans le swap si on l'a pas utilisée depuis un moment, même s'il reste un peu de RAM libre. Simplement "un peu de RAM libre" ne signifie pas la même quantité selon la version de windows.
La version serveur va essayer de garder + de RAM disponible immédiatement, ce qui la rendra + performante avec tes 2Go de RAM, et insupportable avec moins de 512Mo.
Dans ce dernier cas, une version client sera + adaptée, mais le disque sera de toutes façons très sollicité, d'où l'intérêt d'avoir des caches permettant d'utiliser son débit maximal.

c'est sence etre un topic sur le swap ? ou sur la gestion des 2/8Mo embarques ??

Tout est lié

donc tu penses ke l'augmentation des perfs kan tu passes a 8Mo c essentielletn du au swap ?
 
dans tous les cas rien a voir ... les perfs c les perfs , swap ou pas swap le 8Mo est apparemtn meilleur ke le 2Mo ..
maitenant ca reste toujours un mystere :?

Moi j'aimerais bien le faire, mais je n'ai pas de licence Windows XP
(trop cher, je préfère m'acheter un 200Go pour le même prix ... avec 8Mo de cache).
Sérieusement ça serait intéressant, vu qu'on a les sources du noyau, et comparer kernel 2.6 à Win32 + MaxBoost.

ton exemple sur Linux est bien évidemment faux, sinon on aurait pas inventé le prelink ...
EDIT: sur le fond je n'en sais rien. Il y a consensus pour dire que le noyau Linux gère mieux la mémoire que celui de Win32, mais ça dépend tellement de l'utilisation ...
Ce qui est sûr en revanche c'est que le gestionnaire d'allocation/désallocation
des pages (écriture des dirty + chargement anticipé) est bien meilleur.
cf les diffs d'Ingo Molnar et le O(1) ...

pour ça, il faudrait déjà une application équivalente sur les 2 OS.
et encore, comme les 2 OS ne prennent pas la même quantité de RAM, l'un risque de swapper + que l'autre, ce qui fausserait les résultats.
Si on met beaucoup de RAM, ça fausse aussi les résultats vu que ça risque de supprimer beaucoup d'accès disques.
bref, c'est pas simple à comparer
quoique je commence à me demander si je vais pas écrire un petit bench de disque avec des accès simultanés...
ça pourrait donne une idée, mais ça restera un bench qui ne représente pas toutes les utilisations.

Au fait, ça y est, j'ai fini mon water-cooling (pour disques),
je vais donc pouvoir aller acheter des nouveaux disques.
Je repose ma question:
quel disque > 160 Go (par ex. 200Go) existe à la fois en version
2Mo et 8Mo de cache ? Sur rue-montgallet il n'y a que des 8Mo ...
Alternativement, si quelqu'un sait comment désactiver 6 des 8Mo,
même de façon irréversible ...

en mettant le bios de la version 2Mo?
 
 
 
OK je sors

firmware tu veux dire ?

oui enfin on va pas chipoter sur le vocabulaire employé pour dire des conneries

quitte à dire des conneries, autant le faire dans les règles de l'art et avec un aplomb microsoftien

pourquoi tu veux faire ça?

bah pour perdre un disque supérieur à 160 Go

Bon bah de toute façon, j'avais pas le choix, dans le magasin où je viens d'acheter mon PC, les HD 8 Mo étaient au même prix que les 2 Mo, alors tant qu'à faire, j'ai préféré prendre les 6 Mo inutilques quand même

dans le doute