10 stations qui doivent se synchroniser par ethernet ça n'a rien à voir avec une station qui exécute du code sur plusieurs cœurs.
Tes 10 stations ARM ce n'est rien de plus qu'un cas particulier. Qu'est ce qui t'empêche d'ajouter la latence qui va bien ? De produire volontairement des pannes ? De shooter des processus ? D'injecter des paquets TCP pourris ? De forcer les race conditions ?
Les caractéristiques de ton Ethernet là, elles n'ont rien avoir avec ce que tu trouveras en prod. Ca peut être du Myrinet ou de l'infiband si t'es sur un cluster HPC. Ca peut être deux datacenter dont tu tentes de syncrhoniser l'état. Ca peut être des applis p2p avec des lignes ADSL. Bref t'as tout à y gagner à savoir reproduire les caractéristiques principales de n'importe quel environnement en local plutôt que de compter sur le coup de bol. Le jour où tu chercheras pourquoi un client avec 500ms de latence et 30% de packet loss t’emmène ton appli ça sera beaucoup plus facile à diagnostiquer et à valider.
Et pour ce qui est de l'optimisation du parallélisme. Ta plateforme de test est tellement éloignée de ta plateforme de prod que l’intérêt est bien maigre.
On peut bien sur y trouver des utilisations. Mais architecturer son soft pour qu'il soit testable, et avoir les outils pour le torturer de manière reproductible ca me semble un meilleur début. Brancher le tout et regarder si ca tourne correctement, c'est du boulot de QA… qui généralement se fait sur la plateforme cible.
[^] # Re: Déjà épuisé, avant même la dépêche
Posté par ckyl . En réponse à la dépêche Le Raspberry Pi est arrivé. Évalué à 6.
Tes 10 stations ARM ce n'est rien de plus qu'un cas particulier. Qu'est ce qui t'empêche d'ajouter la latence qui va bien ? De produire volontairement des pannes ? De shooter des processus ? D'injecter des paquets TCP pourris ? De forcer les race conditions ?
Les caractéristiques de ton Ethernet là, elles n'ont rien avoir avec ce que tu trouveras en prod. Ca peut être du Myrinet ou de l'infiband si t'es sur un cluster HPC. Ca peut être deux datacenter dont tu tentes de syncrhoniser l'état. Ca peut être des applis p2p avec des lignes ADSL. Bref t'as tout à y gagner à savoir reproduire les caractéristiques principales de n'importe quel environnement en local plutôt que de compter sur le coup de bol. Le jour où tu chercheras pourquoi un client avec 500ms de latence et 30% de packet loss t’emmène ton appli ça sera beaucoup plus facile à diagnostiquer et à valider.
Et pour ce qui est de l'optimisation du parallélisme. Ta plateforme de test est tellement éloignée de ta plateforme de prod que l’intérêt est bien maigre.
On peut bien sur y trouver des utilisations. Mais architecturer son soft pour qu'il soit testable, et avoir les outils pour le torturer de manière reproductible ca me semble un meilleur début. Brancher le tout et regarder si ca tourne correctement, c'est du boulot de QA… qui généralement se fait sur la plateforme cible.