Utilisation RAID0 "performante" sous windows XP
Le
Blaise Potard
Bonjour à tous,
Je ne sais pas si je suis dans le bon forum, mais la question concernant des fonctions assez avancées de l'OS visé (windows XP), je pense qu'elle y a tout de même un peu sa place.
J'expose ma situation : j'ai une machine "puissante" (2x4 coeurs, 8Go de RAM, RAID0 matériel avec quatre disques) pour pouvoir enregistrer en temps réel plusieurs flux vidéo non-compressés reçu par des cartes d'acquisition spécifiques. Mon système est équipé de Windows XP en 32 bits (parce qu'il n'y a pas de pilote pour la carte d'acquisition en 64-bits, apparemment). Je précise immédiatement que je ne suis pas du tout un spécialiste de Windows, je suis même plutôt un habitué de la fosse à troll des linuxiens (ça va peut-être se voir un peu par moment, mais contrairement aux apparences, ce post n'est pas un troll, mais une vraie question).
Une question accessoire que vous pouvez ignorer dans une premier temps, un peu naïve sans doute (et un peu trollatoire parce que tout de même, on ne peut pas ignorer trop longtemps sa vraie nature) : pourquoi l'OS ne m'affiche que 2.3Go de mémoire disponible sur les 8Go installés ? Les processeurs 32 bits savent matériellement adresser jusqu'à 32Go en utilisant le système des pages depuis fort longtemps (depuis le Pentium Pro, ça remonte donc pas mal), donc je ne vois pas trop où est le problème (d'ailleurs, linux en 32 bits sait le faire, même si il paraît que c'est une mauvaise idée d'utiliser cette fonctionnalité). Je n'ai pas vraiment besoin de beaucoup de RAM pour mon application donc ce n'est pas vraiment gênant, juste un peu dommage.
Ma vraie question concerne les performances des fonctions fread/fwrite dès lors que je veux écrire/lire sur le RAID.
Une première chose très surprenante est que le mode binaire est apparemment cassé dans Visual Studio 2008, puisqu'en ouvrant explicitement un fichier en écriture avec le mode "wb" sur le RAID, j'obtiens des performances faméliques de l'ordre de 10Mo/s. En ouvrant en mode texte classique "w" en utilisant exactement les mêmes conditions, j'obtiens de l'ordre de 120Mo/s en écriture. Or, théoriquement, je devrais pouvoir atteindre jusqu'à 400Mo/s, puisque c'est ce qu'obtiennent mes différents outils de benchmark
Après pas mal d'heures d'arrachage de cheveux, je pense avoir trouvé l'origine du mystère : le RAID0 n'a pas de mémoire cache embarqué et n'utilise pas celui des disques, et il semble que l'OS découpe systématiquement les transferts d'IO vers disque en blocs de 64ko maximum. Du reste, mes outils de benchmark atteignent des débits comparables avec des blocs de cette taille. Ce qui n'a pas trop (voire pas du tout) d'impact avec un disque qui a un gros cache en a énormément avec un contrôleur matériel sans cache !
Je cherche désespérément depuis plus de 24h des informations sur comment modifier la taille de ces blocs au niveau logiciel, mais j'ai l'impression qu'on ne peut le faire qu'à un très bas niveau, i.e. en dessous du filesystem, ou en désactivant le cache avec les appels bas niveau. Lorsque l'on veut simplement écrire un fichier de façon efficace avec fread/fwrite, il n'y a pas de solution simple, à part, apparemment, de passer à Vista, cf. le topo de Russinovich sur les améliorations au noyau de Vista:
"One final change in the I/O system worth mentioning relates to the size of I/O operations. Since the first version of Windows NT, the Memory Manager and the I/O system have limited the amount of data processed by an individual storage I/O request to 64KB () In Windows Vista storage I/O request sizes are no longer capped." [1]
J'aimerais donc savoir si vous avez déjà rencontré ce problème, comment vous y avez remédié, ou sinon quelle serait à votre avis la meilleure stratégie:
- acheter une carte d'acquisition ayant des drivers pour windows Vista?
- acheter un contrôleur raid capable de compenser les défauts de l'OS (ce que font les disques ATA/SATA du reste maintenant la raison de ces caches exponentiels s'explique !) ?
- utiliser les appels systèmes bas-niveaux CreateFile/WriteFile en désactivant le cache, et en réimplémentant une sorte de scheduler de façon à pouvoir multithreader proprement l'écriture des différents flux sans provoquer trop de déplacements des têtes de lecture (pour l'instant c'est la solution que j'essaye d'adopter, ça marche mais c'est loin d'être vraiment satisfaisant) ?
Merci d'avance pour vos réponses !
Blaise
[1]: http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx
Je ne sais pas si je suis dans le bon forum, mais la question concernant des fonctions assez avancées de l'OS visé (windows XP), je pense qu'elle y a tout de même un peu sa place.
J'expose ma situation : j'ai une machine "puissante" (2x4 coeurs, 8Go de RAM, RAID0 matériel avec quatre disques) pour pouvoir enregistrer en temps réel plusieurs flux vidéo non-compressés reçu par des cartes d'acquisition spécifiques. Mon système est équipé de Windows XP en 32 bits (parce qu'il n'y a pas de pilote pour la carte d'acquisition en 64-bits, apparemment). Je précise immédiatement que je ne suis pas du tout un spécialiste de Windows, je suis même plutôt un habitué de la fosse à troll des linuxiens (ça va peut-être se voir un peu par moment, mais contrairement aux apparences, ce post n'est pas un troll, mais une vraie question).
Une question accessoire que vous pouvez ignorer dans une premier temps, un peu naïve sans doute (et un peu trollatoire parce que tout de même, on ne peut pas ignorer trop longtemps sa vraie nature) : pourquoi l'OS ne m'affiche que 2.3Go de mémoire disponible sur les 8Go installés ? Les processeurs 32 bits savent matériellement adresser jusqu'à 32Go en utilisant le système des pages depuis fort longtemps (depuis le Pentium Pro, ça remonte donc pas mal), donc je ne vois pas trop où est le problème (d'ailleurs, linux en 32 bits sait le faire, même si il paraît que c'est une mauvaise idée d'utiliser cette fonctionnalité). Je n'ai pas vraiment besoin de beaucoup de RAM pour mon application donc ce n'est pas vraiment gênant, juste un peu dommage.
Ma vraie question concerne les performances des fonctions fread/fwrite dès lors que je veux écrire/lire sur le RAID.
Une première chose très surprenante est que le mode binaire est apparemment cassé dans Visual Studio 2008, puisqu'en ouvrant explicitement un fichier en écriture avec le mode "wb" sur le RAID, j'obtiens des performances faméliques de l'ordre de 10Mo/s. En ouvrant en mode texte classique "w" en utilisant exactement les mêmes conditions, j'obtiens de l'ordre de 120Mo/s en écriture. Or, théoriquement, je devrais pouvoir atteindre jusqu'à 400Mo/s, puisque c'est ce qu'obtiennent mes différents outils de benchmark
Après pas mal d'heures d'arrachage de cheveux, je pense avoir trouvé l'origine du mystère : le RAID0 n'a pas de mémoire cache embarqué et n'utilise pas celui des disques, et il semble que l'OS découpe systématiquement les transferts d'IO vers disque en blocs de 64ko maximum. Du reste, mes outils de benchmark atteignent des débits comparables avec des blocs de cette taille. Ce qui n'a pas trop (voire pas du tout) d'impact avec un disque qui a un gros cache en a énormément avec un contrôleur matériel sans cache !
Je cherche désespérément depuis plus de 24h des informations sur comment modifier la taille de ces blocs au niveau logiciel, mais j'ai l'impression qu'on ne peut le faire qu'à un très bas niveau, i.e. en dessous du filesystem, ou en désactivant le cache avec les appels bas niveau. Lorsque l'on veut simplement écrire un fichier de façon efficace avec fread/fwrite, il n'y a pas de solution simple, à part, apparemment, de passer à Vista, cf. le topo de Russinovich sur les améliorations au noyau de Vista:
"One final change in the I/O system worth mentioning relates to the size of I/O operations. Since the first version of Windows NT, the Memory Manager and the I/O system have limited the amount of data processed by an individual storage I/O request to 64KB () In Windows Vista storage I/O request sizes are no longer capped." [1]
J'aimerais donc savoir si vous avez déjà rencontré ce problème, comment vous y avez remédié, ou sinon quelle serait à votre avis la meilleure stratégie:
- acheter une carte d'acquisition ayant des drivers pour windows Vista?
- acheter un contrôleur raid capable de compenser les défauts de l'OS (ce que font les disques ATA/SATA du reste maintenant la raison de ces caches exponentiels s'explique !) ?
- utiliser les appels systèmes bas-niveaux CreateFile/WriteFile en désactivant le cache, et en réimplémentant une sorte de scheduler de façon à pouvoir multithreader proprement l'écriture des différents flux sans provoquer trop de déplacements des têtes de lecture (pour l'instant c'est la solution que j'essaye d'adopter, ça marche mais c'est loin d'être vraiment satisfaisant) ?
Merci d'avance pour vos réponses !
Blaise
[1]: http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx
Windows XP (ou Vista 32) (et ses prédecesseurs) est limité à 4Go. Moins
une fenêtre pour accéder à la carte graphique (tu dois arriver à
environ 3,5Go). Pour faire mieux il faut soit :
- Utiliser un XP 64 bits
- Utiliser un Windows 2000 Advanced Server (8Go) ou Data Center Server
(64Go). Pour XP/2003, Microsoft a préféré se concentrer sur la version
64 bits au lieu d'utiliser les béquilles du système de pagination.
Voir aussi si la carte RAID fait du vrai RAID matériel, et non pas du
RAID bancal en se faisant aider par l'OS (j'avais lu ça, je crois, dans
un forum Linux...). Est-ce que par exemple, sous Linux tu as les mêmes
problèmes, ou ça va mieux ?
- Plutôt, une carte d'acquisition avec un pilote 64 bits (XP ou
Vista...).
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
> Subject: Utilisation RAID0 "performante" sous windows XP
> User-Agent: KNode/0.99.01
> MIME-Version: 1.0
> Content-Type: text/plain; charset=""
> Content-Transfer-Encoding: 8Bit
le charset utilisé n'est pas "" mais sûrement une m...e d'UTF,
le message est illisible.
mais on va pas troller sur l'incapacité de configurer un
lecteur de news, hein.
Sylvain.
Blaise Potard a écrit :
Alors tu ne m'en voudras pas si je te casse un peu. J'aime bien
GNU/Linux et les systèmes libres, or qui aime bien châtie bien. Au lieu
de passer ton temps dans la fosse à trolls tu ferais mieux de régler ton
Knode pour qu'il déclare le bon jeu de caractères (visiblement c'est de
l'UTF8 mais tes en-têtes contiennent charset="") et coupe les lignes à
moins de 80 caractères.
Le système PAE, et c'est jusqu'à 64 Gio.
L'ennui, c'est que si la version 32 bits de Windows XP active bien le
PAE à partir du service pack 2, c'est uniquement pour activer la
fonctionnalité "NX" (Non eXécution des pages de données pour éviter
l'exécution de code arbitraire suite à un buffer overflow par exemple),
mais sans augmenter la quantité de mémoire gérée. Cf.
on peut le voir sur cette page, en 32 bits seules les versions serveur
"avancées" peuvent gérer plus de 4 Gio d'espace mémoire physique. La
raison invoquée concerne la compatibilité de certains pilotes de
péripériques. Comme cet espace mémoire physique ne contient pas que la
RAM mais aussi la mémoire des périphériques système (notamment carte
graphique), la quantité de RAM disponible est inférieure à 4 Gio,
généralement entre 3 et 3,5 Gio d'après ce que j'ai lu. En revanche 2,3
Go me paraît une valeur bien basse.
Ça diminue un peu les performances. Mais franchement, pourquoi ce serait
une mauvaise idée de pouvoir utiliser toute la RAM physique si on en a
besoin et si pour une raison X ou Y on ne peut/veut pas installer un
système 64 bits ? C'est mieux de swapper ? Un accès mémoire même un peu
plus lent sera toujours beaucoup plus rapide qu'un accès disque.
avancées ?
peux-tu indiquer quelles fonctions avancées est utilisé avec le mode
"wt" ?? pas des trucs aussi avancés que fopen / fopen_s si ?
dans quel environnement ? si sous debug c'est normal.
si le fichier est ouvert avec fopen pour lequel tu ne contrôles
rien, c'est peut être normal; CreateFile offre quelque options
utiles.
sans connaitre le controleur RAID ni la connectique et sa version
des disques, il est difficile - sauf à jouer à la divination -
de diagnostiquer ton système.
Sylvain.