Nos implémentations de pilote d’impression récupèrent les données générées ligne par ligne au travers de la mémoire tampon située dans le Consumer et détaillée dans le chapitre 8 :
Agrégation et transmission des données à l’utilisateur. Grâce au Consumer, les données lui sont
fournies dans l’ordre, dès qu’elles sont disponibles et sans connaissance du Producer qui les a calculées.
Nous proposons deux méthodes d’accès à ces données : dans la première, le pilote d’impression va tenter d’écouler ces lignes le plus rapidement possible afin d’évaluer le débit maximal auquel le système peut fournir les données ; dans la seconde, il impose un délai d’attente avant la récupération de la ligne suivante afin de simuler la présence d’un traitement spécifique à une imprimante. La longueur de ce délai d’attente est définie en fonction de la vitesse d’impression de l’imprimante simulée et se détermine par l’équation10.1.
Soient :
— Dimprimantedébit de l’imprimante (en octets par seconde) ; — Ttravailtaille du travail (en octets) ;
— N blignesnombre de lignes dans le travail ; alors :
Délai d’attente pour chaque ligne = (Ttravail/ Dimprimante)
N blignes
(10.1)
Pour représenter un comportement probant, cette attente doit être réalisée avec une grande précision. En effet, ce traitement effectué à chaque ligne peut être bref, par exemple un simple transfert des données vers une interface de communication dédiée à très haut débit. Dans ces scénarios, le délai d’attente à produire est compris entre quelques centaines de nanosecondes et quelques millisecondes. Or, les mécanismes d’attente classique proposés par les systèmes d’exploitation actuels (tels que usleep(3), nanosleep(2), clock_nanosleep(2), select(2)) n’offrent pas une précision suffisante. En effet, lors de nos expérimentations préalables, leur temps d’attente effectif minimal est aux alentours de 55 ms. Ce délai élevé s’explique par les mécanismes de signaux et de changement de contexte qui sont utilisés par le noyau. Par
conséquent, nous utilisons une attente active sur la valeur de l’horloge monotonique qui utilise l’horloge interne nanométrique du processeur. Cette attente active nous permet de réaliser des délais d’attente avec un surcoût moyen observé de seulement 50 ns par rapport au temps demandé, soit une précision 1100× plus importante.
Malheureusement, comme toute attente active, elle présente le défaut de fortement solliciter des cycles d’exécution du processeur, ce qui n’est pas représentatif d’un envoi de données par une carte réseau. En effet, celle-ci serait davantage consommatrice de bande passante mémoire que de cycle de calcul. Cependant, au vu de la complexité et de la spécificité de ces échanges mémoires (taille, alignement des données, etc.) spécifiques à chaque carte réseau, nous considérons comme hors d’atteinte de réaliser une simulation probante de ces mécanismes à cette échelle de temps. La simulation des temps de traitement des pilotes d’impression est donc réalisée par une utilisation du processeur, qui est une simulation de qualité permettant de respecter le critère principal : une grande précision dans le temps d’attente.1
10.4
Limites et extensions
L’application des délais d’attente, exécutés par les pilotes d’impression entre chaque ligne de données récupérée, pourrait être développée pour approfondir les contraintes qu’ils repré- sentent. En effet, les imprimantes sont généralement dotées d’une mémoire tampon interne de petite capacité permettant notamment de lisser les éventuels aléas des communications. C’est également grâce à cette mémoire tampon qu’elles ne nécessitent pas un pilotage temps réel strict. Par effet de bord, ces mémoires tampon génèrent de légères variations de débit autour du débit moyen que nous utilisons comme référence pour définir les délais d’attente. Ainsi, pour améliorer le mimétisme des conditions réelles, nos délais d’attente pourraient intégrer aléatoirement des variations similaires. Il serait également possible de définir la survenue de ces variations en analysant les exécutions de différents pilotes d’impression, et ainsi de reproduire plus fidèlement l’exécution de pilotes d’impression réels.
10.5
Conclusion
Enfin, les deux simulations de pilotes d’impression que nous avons développées permettent d’évaluer de manière relativement réaliste les performances de notre solution de génération distribuée de flux de données ordonnées sous différents scénarios imposant des contraintes
1. Il serait possible d’améliorer la précision de ces délais d’attente en demandant au noyau d’effectuer un ordonnancement temps réel du processus du pilote d’impression. Cette approche lui fournirait la garantie d’une vérification régulière de l’horloge monotonique. Cependant, dans les systèmes réels, les pilotes d’impression ne sont pas exécutés de cette manière et sont donc soumis à la contrainte du partage d’accès aux cœurs du processeur et peuvent notamment être perturbés par l’exécution concurrente d’un Producer local. Ainsi, nous n’intégrons pas d’exécution temps réel de nos simulations de pilote d’impression pour ne pas dévier des conditions réelles de leur exécution.
variées. Ces évaluations sont présentées et commentées dans le chapitre 11 : Évaluations du
11
Évaluations du RIP distribué
Ce second chapitre est dédié aux évaluations, il présente l’analyse des performances de notre solution de chaîne de traitement graphique distribuée. Nous évaluons notre solution sur les dif- férentes topologies possibles et analysons ses performances sur trois aspects complémentaires : les débits maximaux atteignables par notre architecture par rapport aux débits théoriques de la plateforme d’évaluation ; les débits effectifs de notre solution distribuée avec implémentation des traitements de RIP ; et la capacité à produire des débits constants nécessaires pour le pilotage des imprimantes.
11.1
Plateforme d’évaluation
La même plateforme est utilisée pour les différentes évaluations, elle se compose de cinq nœuds identiques équipés d’un processeur Intel Xeon D-1521, de 2× 4 Gio de mémoire vive DDR4 à 2133 MT/s, de deux interfaces réseau 10 GbE, sur une carte mère Supermicro X10SDV-4C-TLN2F. Leur système d’exploitation est Ubuntu 18.04.1 LTS doté du noyau Linux 4.15.0-43-generic. Chacune des interfaces réseau est interconnectée aux autres par un unique switch Netgear XS512EM qui est capable d’alimenter simultanément ses douze interfaces avec le débit maximum de 10 GbE. Le réseau utilise des trames Ethernet avec un maximum
transmission unit (MTU) par défaut à 1 500 octets.
La présence de deux interfaces réseau sur chaque nœud nous permet de simuler jusqu’à huit nœuds distants en dédiant une interface réseau à chaque nœud simulé. Nous n’avons observé aucune perturbation des performances en utilisant cette méthode de simulation. Elle nous fournit un moyen réaliste d’augmenter artificiellement le nombre de nœuds dans nos expériences en évitant toute intrusion dans la pile réseau du noyau.