Applications sporadiques
BOINC a été conçu à l'origine comme un système de traitement par lots : vous soumettez des tâches, elles s'exécutent (indépendamment les unes des autres) et finissent par se terminer. Mais certaines utilisations potentielles de l'informatique distribuée ne correspondent pas à ce modèle. Elles peuvent nécessiter que les applications s'exécutent simultanément sur différents ordinateurs, et éventuellement qu'elles communiquent directement les unes avec les autres. Il s'agit par exemple du calcul parallèle de type MPI et de l'apprentissage automatique distribué. Le mécanisme d' "application sporadique" de BOINC est conçu pour prendre en charge ces types de systèmes et leur permettre de coexister avec le traitement par lots.
Dans ce schéma, il existe un système distribué - appelons-le "système invité" - qui existe en dehors de BOINC. Le système invité possède généralement son propre serveur qui traite les demandes et les transmet aux "nœuds de travail" qui exécutent le client BOINC. La partie "serveur" du système invité fonctionne comme une application sporadique sur ces nœuds. Les instances peuvent communiquer directement entre elles - de pair à pair ou par l'intermédiaire d'un relais - ainsi qu'avec le serveur.
Le système invité utilise BOINC pour
- Distribuer et exécuter en toute sécurité son code de travail (l'application sporadique).
- Appliquer les préférences informatiques des volontaires (quand calculer, combien d'unités centrales utiliser, etc.)
- Pour les volontaires qui utilisent déjà BOINC, répartir la puissance de calcul entre les projets.
Le système invité n'utilise pas les fonctions de traitement par lots de BOINC.
Les tâches d'une application sporadique s'exécutent (c'est-à-dire qu'elles sont présentes en mémoire) en permanence, comme les tâches non gourmandes en CPU (nci), mais elles ne calculent qu'une partie du temps. Comme les applications classiques, une application sporadique peut avoir plusieurs versions. Chacune d'entre elles possède une classe de plan, qui détermine l'utilisation du processeur (CPU et GPU) de ses tâches. Le planificateur BOINC d'un projet peut envoyer plusieurs tâches pour une application sporadique donnée, en utilisant la même version d'application ou des versions différentes.
Un projet BOINC peut fournir n'importe quelle combinaison d'applications régulières, sporadiques et non gourmandes en CPU (nci). Un client peut être connecté à plusieurs projets avec des applications sporadiques.
Comme les tâches régulières, une tâche sporadique ne peut calculer que lorsque BOINC l'autorise, c'est-à-dire :
- le calcul (et le calcul GPU le cas échéant) est activé par les préférences de l'utilisateur
- il y a suffisamment de ressources de traitement et de RAM
En outre, un travail sporadique ne peut calculer que lorsque le système invité le lui demande. Ainsi, un travail sporadique converse à la fois avec le client BOINC et avec le serveur du système invité ; il ne calcule que lorsque le serveur le lui demande et lorsque le client dit qu'il peut le faire.
(la suite ci-dessous)
L'API pour les applications sporadiques
Le protocole entre le client BOINC et une application sporadique utilise les messages suivants :
Client à l'application :
DONT_COMPUTE : l'application ne peut pas calculer maintenant (par exemple parce que les ressources ne sont pas disponibles)
COULD_COMPUTE : l'application peut potentiellement calculer
COMPUTING : l'application est en train de calculer en ce qui concerne le client.
L'application au client :
DONT_WANT_COMPUTE : l'application ne veut pas calculer maintenant
WANT_COMPUTE : l'application veut calculer
Le protocole entre l'application et le serveur invité n'est pas spécifié. Il peut être basé sur l'interrogation de l'application ou sur des requêtes bidirectionnelles.
Un scénario typique est le suivant :
Les étapes sont les suivantes :
- Dans un premier temps, le client indique à l'application qu'il ne peut pas calculer, peut-être parce que l'utilisateur a suspendu le calcul.
- L'application transmet cette information au serveur, ce qui lui indique de ne pas envoyer de requêtes. Le serveur peut savoir quels nœuds de travail sont disponibles pour le calcul à un moment donné.
- L'utilisateur finit par activer le calcul ; le client transmet un message COULD_COMPUTE à l'application, et l'application le transmet au serveur, indiquant qu'elle peut désormais accepter des requêtes.
- Le serveur envoie une requête à l'application, lui demandant d'effectuer un calcul (et éventuellement une communication réseau avec d'autres travailleurs).
- L'application envoie WANT_COMPUTE au client.
- Le client réserve les ressources informatiques nécessaires et envoie COMPUTING à l'application
- L'application effectue le calcul. Lorsqu'elle a terminé, elle envoie DONT_WANT_COMPUTE au client.
- Le client (en supposant que le calcul n'est pas suspendu) envoie COULD_COMPUTE
Il est également possible que l'application doive arrêter le calcul avant la fin de la requête - par exemple, parce que l'utilisateur suspend le calcul.
Dans ce cas,
- Le client envoie DONT_COMPUTE à l'application.
- L'application notifie au serveur qu'elle ne peut pas terminer la requête (ou elle peut attendre avant de le faire, au cas où le calcul serait réactivé rapidement).
L'application doit donc vérifier en permanence si le client lui envoie un message, même lorsqu'elle est en train de calculer.
Les interfaces API permettant de communiquer avec le client sont les suivantes :
enum SPORADIC_CA_STATE {
CA_NONE = 0,
CA_DONT_COMPUTE = 1,
CA_COULD_COMPUTE = 2,
CA_COMPUTING = 3
};
enum SPORADIC_AC_STATE {
AC_NONE = 0,
AC_DONT_WANT_COMPUTE = 1,
AC_WANT_COMPUTE = 2
};
extern void boinc_sporadic_set_ac_state(SPORADIC_AC_STATE);
extern SPORADIC_CA_STATE boinc_sporadic_get_ca_state();
Communication en réseau
Les applications sporadiques qui communiquent avec le réseau doivent respecter les règles d'accès au réseau. Elles ne doivent pas, par exemple, communiquer lorsque les préférences de l'utilisateur l'interdisent.
Priorité aux applications sporadiques
Dans l'implémentation initiale des applications sporadiques (client BOINC version 7.26), les applications sporadiques ont une priorité stricte sur les applications régulières. Ainsi, si une application sporadique effectue beaucoup de calculs, elle peut affamer une application régulière. Si plusieurs applications sporadiques sont en concurrence pour une ressource (par exemple, un GPU), la priorité entre elles est fixe ; l'une d'entre elles peut priver les autres de ressources.
Dans une version ultérieure, les applications sporadiques seront programmées en utilisant le même schéma que celui utilisé pour les applications régulières, dans lequel le partage des ressources du projet détermine la priorité et la famine est éliminée.
Source : https://github.com/BOINC/boinc/wiki/Sporadic-Applications/?_sm_au_=iMVVQsFDnj2p4366Q0WpHK6H8sjL6