OVH Cloud OVH Cloud

Utilisation RAID0 "performante" sous windows XP

4 réponses
Avatar
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

4 réponses

Avatar
Sergio
Blaise Potard a émis l'idée suivante :

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.



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.

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 !



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 ?


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?



- 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
Avatar
Sylvain SF
Blaise Potard a écrit :

> 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.
Avatar
Pascal Hambourg
Salut,

Blaise Potard a écrit :

je suis même plutôt un habitué de la fosse à troll des linuxiens



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.

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



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.
<http://en.wikipedia.org/wiki/Physical_Address_Extension#Windows>. Comme
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.

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é



Ç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.
Avatar
Sylvain SF
Sergio a écrit :
Blaise Potard a émis l'idée suivante :

la question concernant des fonctions assez avancées de l'OS visé





avancées ?

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





peux-tu indiquer quelles fonctions avancées est utilisé avec le mode
"wt" ?? pas des trucs aussi avancés que fopen / fopen_s si ?

j'obtiens des performances faméliques de l'ordre de 10Mo/s.





dans quel environnement ? si sous debug c'est normal.

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





si le fichier est ouvert avec fopen pour lequel tu ne contrôles
rien, c'est peut être normal; CreateFile offre quelque options
utiles.

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





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.