pentaPi

Le site de la fondation Raspberry Pi comporte l'article Build an OctaPi qui est à l'origine du présent atelier, dont l'objectif est double:

  1. perfectionner mes compétences de mise en oeuvre (réseau) de Raspberry Pis;
  2. envisager une éventuelle utilisation pour du calcul intensif (Basilisk).

Ce projet a aussi bénéficié des ressources suivantes:

Disons tout-de-suite que l'objectif #2 n'est pas réaliste au niveau matériel (du moins en 2019), mais il était déjà intéressant de tester la faisabilité logicielle d'une telle application.

Suivant en cela le projet Build an OctaPi déjà cité, le réseau local est basé sur wifi (et non ethernet); par contre j'ai utilisé des Raspberry Pi Zero W (au lieu de modèles Pi 3): ajouter un noeud au cluster revient alors à moins de 30€ (mais on dispose d'un seul coeur par noeud). La photo suivante montre le matériel utilisé: le "maître" (ou client ssh) est en fait un Raspberry Pi Zero WH recyclé d'un précédent projet et il y a 4 "esclaves" (ou serveurs ssh).

hardware

Même si Build an OctaPi conseille d'utiliser un router dédié, je me suis contenté de mettre à contribution la boîte Internet familiale. Le maître s'appelle wolfmaster et les esclaves sont wolf01 à wolf04:

wifi

Côté système, j'ai utilisé la distribution Raspbian Buster Lite, donné une IP statique aux différentes noeuds (maître et esclaves) et configuré l'accès SSH par clé publique (sans passphrase) depuis le maître vers chacun des esclaves (pas besoin de ssh-agent). J'ai choisi de ne pas installer de serveur NFS sur le maître mais plutôt de dupliquer l'exécutable vers chacun des esclaves, procédure automatisée avec un script ad hoc appelé cpe.sh dans la copie d'écran ci-dessous.

test.c

Cette session montre la compilation et l’exécution du programme de test disponible sur le tutoriel déjà cité. J'ai seulement dû commenter un printf pour éviter que l'application ne s'éternise (peut-être une première indication du débit relativement faible du lien wifi, qu'il faut veiller à ne pas trop solliciter?). Le programme (très légèrement) modifié est disponible ici pour référence. D'autre par un warning apparait au lancement du test (voir ci-dessus), mais pas toujours... ceci ne semble d'ailleurs pas gêner la communication MPI et le programme s'exécute normalement.

Le test suivant s'est avéré beaucoup plus difficile: en effet l'installation de Basilisk sur wolfmaster s'est déroulée sans souci mais les temps de calcul se sont avérés prohibitifs. Quatre machines ont été comparées:

  1. un PC portable d'entrée de gamme estampillé HP: Herminet7 (4 cœurs);
  2. un mini PC générique d'entrée de gamme: Herminet8 (4 cœurs aussi);
  3. le cluster piloté par wolfmaster: 5 appareils reliés par wifi (un seul cœur chacun);
  4. un Raspberry Pi 3 B+ (4 cœurs) doté d'un environnement de bureau complet (donc serveur X, ce qui n'est pas le cas de notre cluster): piDesk.

Toutes les CPUs tournent à ~1 GHz, mais le tableau suivant montre que ce n'est pas le paramètre principal:

wallclock time (min) séquentiel OpenMP MPI
Herminet7 1,3 0,7 1,2
Herminet8 1,5 1,0 1,0
wolfmaster 10,9 --- 235,7
piDesk 4,8 9,3 3,8

La configuration Basilisk utilisée ne nécessite pas un calcul très long: 1,3 min sur Herminet7 en mode séquentiel. Le temps de calcul descend à 0,7 min en parallélisation OpenMP, a priori la plus favorable sur une machine mono-processeur et multi-cœur. La parallélisation MPI s'évère décevante dans ce cas; sans doute le calcul n'est-il pas assez long pour justifier le surcoût des communications MPI. Notons aussi que le temps de calcul est loin d'être divisé par quatre par la parallélisation (même en OpenMP), mais la question du scaling ne sera pas abordée ici: le calcul s'avèrera cependant bien assez long pour notre inter-comparaison...

Herminet8 tourne presque aussi vite que Herminet7 en séquentiel mais s'avère curieusement (i) décevante avec OpenMP et (ii) meilleure avec MPI. Les différences portent sans doute sur la mémoire cache et la carte mère, ce qui ne sera pas investigué davantage ici.

Concernant les Pis Zero W(H), le premier constat concerne l'allongement alarmant du temps de calcul séquentiel: cette plate-forme destinée aux applications éducatives et IoT n'est évidemment pas adaptée au calcul intensif, malgré une CPU tournant à une vitesse respectable de 1 GHz. J'ai vérifié que la configuration Basilisk ne faisait pas swapper le Pi Zero (512 MB de mémoire vive) et testé l'option de compilation suivante:

-march=armv6 -mfloat-abi=hard -mfpu=vfp -mtune=arm1176jzf-s

mais sans succès: sans doute la bonne option était-elle automatiquement mise en oeuvre lors de la compilation in situ avec gcc.

La parallélisation OpenMP n'a pas été testée sur wolfmaster (un seul cœur) mais en MPI avec 5 noeuds (wolfmaster et ses quatre esclaves), on constate un écroulement de la puissance de calcul, à cause sans doute de la saturation du réseau wifi. Divers tests d'ajustement radio (sur la box Internet) n'ont pas amélioré la situation. Le constat est donc sans appel (il était prévisible): il faut absolument un réseau Ethernet pour une application de calcul intensif, et donc abandonner le Pi Zero W(H) qui ne dispose que d'une connectivité wifi. À cet égard le Pi 3 B+ (piDesk) est un meilleur candidat à l'intégration en cluster, même si ses résultats restent inférieurs à ceux de Herminet7 et Herminet8 malgré ses 4 coeurs et sa CPU à 1,4 GHz.

En conclusion l'option la plus réaliste (mais sans doute aussi la plus coûteuse) consistera pour EIF-services à déporter ses configurations les plus lourdes vers le cloud, par exemple AWS/EC2.

N.B. Les fichiers dump produits par Basilisk sur wolfmaster ou piDesk ne sont pas lisibles sur Herminet7 ou Herminet8. Par contre l'application bview de Basilisk fonctionne en client-serveur et nous avons testé avec succès cette possibilité (serveur bview sur piDesk, client bview sur Herminet8).

Voici pour finir un retour sur le tutoriel Build an OctaPi, afin de montrer que l'application-test en python fonctionne sans souci:

compute.py