Détection en ligne des erreurs par redondance temporelle logicielle

Comme les approches matérielles, les approches logicielles permettent de détecter et corriger les erreurs. Ces approches peuvent être implémentées au niveau de l’application, de l’OS ou de la machine virtuelle. Chaque niveau a ses avantages et ses inconvénients.

Au niveau de l’application, la détection et la restauration sont faciles à intégrer, mais une erreur au niveau de l’OS ne pourra pas être détectée. Au niveau de l’OS, la détection et la restau-

ration sont plus difficiles, puisqu’il faut modifier un OS entier. Au niveau de la couche de vir- tualisation, celle-ci étant à l’interface entre le matériel et le logiciel, la détection peut bénéficier d’un plus grand taux de couverture. Mais les mécanismes de détection et de restauration inclus au niveau de la couche de virtualisation sont les plus complexes.

Cette partie présente des méthodes implémentant la duplication au niveau de l’application.

Error Detection by Duplicated Instructions

L’approche Error Detection by Duplicated Instructions[57](EDDI) implémente du RMT au niveau logiciel, et contrairement aux approches matérielles, elle ne nécessite qu’un seul contexte hardware.

Les registres et la mémoire sont séparés en deux pour permettre deux copies redondantes des données. Ainsi, la mémoire est dans la sphère de reproduction, mais la quantité de mémoire disponible pour les applications est divisée par deux.

L’approche EDDI repose sur le compilateur qui duplique chacune des instructions du pro- gramme et ajoute des instructions de comparaison avant chaque store (voir tableau 3.2). Néan- moins, après la comparaison les données sont dupliquées dans la mémoire. Cela permet de dé- tecter une éventuelle faute transitoire ayant affecté la mémoire.

Couverture de fautes La méthode EDDI a été développée pour détecter des erreurs transi- toires. En effet, dans le cas d’erreurs permanentes ou intermittentes, la ré-exécution d’une in- struction donnera le même résultat, l’erreur ne sera pas détectée.

Coût en surface Pour implémenter EDDI, il n’est pas nécessaire de modifier l’architecture du processeur, seule l’application nécessite d’être modifiée. Cependant, le coût en surface n’est pas nul. En effet, il faut considérer l’ajout de mémoire engendrée par la duplication.

Impact sur les performances La dégradation des performances est de 36% à 111% sur un processeur super-scalaire avec deux contextes hardware. Nous pouvons supposer qu’elle serait supérieure pour un processeur simple ayant un seul contexte.

Sans EDDI Avec EDDI

LOAD R12 = [R11] LOAD R12 = [R11]

LOAD R22 = [R21]

ADD R11 = R12 + R13 ADD R11 = R12 + R13

ADD R21 = R22 + R23 COMPARE R11,R21 TABLE3.2 :Implémentation de EDDI[57]

Software Implemented Fault Tolerance et CompileR Assisted Fault Tolerance

Afin d’améliorer la technique précédente Software Implemented Fault Tolerance[58](SWIFT) et CompileR Assisted Fault Tolerance[64](CRAFT) ont été développées. La principale différence avec EDDI est que la mémoire n’est plus dans la sphère de reproduction. Il n’y a donc plus de perte de mémoire. En effet, les auteurs supposent que la mémoire est protégée par ECC. Ainsi, seuls les registres internes doivent être dupliqués.

Pour SWIFT, l’implémentation reste la même que pour EDDI, c’est à dire que le compilateur duplique les instructions de l’application et ajoute des étapes de comparaison.

Dans le cas de CRAFT, la comparaison lors des store est faite en matériel. Cette solution est donc hybride : c’est une solution logicielle bénéficiant d’accélérateurs matériels spécifiques. Couverture de fautes Les techniques SWIFT et CRAFT s’appuyant sur EDDI, elles sont adap- tées principalement à la détection des erreurs transitoires. De même, elles possèdent les mêmes inconvénients concernant la détection des erreurs permanentes et intermittentes.

Coût en surface Concernant SWIFT, comme EDDI, il n’est pas nécessaire de modifier l’archi- tecture du processeur, seule l’application nécessite d’être modifiée. Cependant, l’implémentant de SWIFT implique la duplication des registres internes et nécessite une mémoire protégée par ECC.

Concernant CRAFT, le processeur nécessite d’être modifié pour ajouter la comparaison matér- ielle des registres. Cependant, les structures ajoutées sont extrêmement simples, ainsi, le coût en surface est très faible.

Impact sur les performances La dégradation des performances induite par SWIFT et CRAFT dépend des applications ; elle est comprise entre 10% et 85% pour SWIFT et entre 10% et 70% pour CRAFT. De plus, grâce à la comparaison matérielle, CRAFT induit en moyenne moins de 10% de dégradations par rapport à SWIFT. Ces estimations ont été réalisées sur un processeur super-scalaire Intel Itanium 2. Nous pouvons supposer qu’elles seraient supérieures pour un pro- cesseur simple ayant un seul contexte hardware.

Inst. type NOFT SWIFT CRAFT

br faultDet, r1 != r1’ br faultDet, r2 != r2’ STORE st [r1] = r2 st [r1] = r2 st1 [r1 ] = r2 st2 [r1’] = r2’ br faultDet, r2 != r2’ LOAD ld r1 = [r2] ld r1 = [r2] ld1 r1 = [r2 ] mov r1’ = r1 ld2 r1’ = [r2’]

Synthèse et adaptation à nos contraintes

Dans cette partie, nous avons présenté trois techniques de détection en ligne des erreurs par redondance temporelle logicielle : EDDI, SWIFT et CRAFT. Le principal avantage de ces tech- niques est qu’elles ne nécessitent pas de modification des processeurs (sauf pour CRAFT). Seule l’application doit être modifiée, et cette étape est réalisée automatiquement par le compilateur. Ainsi, ces techniques peuvent être utilisées sur des architectures multiprocesseur.

Ces techniques ont été conçues pour détecter des erreurs transitoires, ainsi, elles ne sont pas adaptées à nos contraintes. De plus, la dégradation des performances des applications peut être très importante et dépasser 110%.

À la vue des remarques précédentes, les techniques de détection en ligne des erreurs par redondance temporelle logicielles ne peuvent répondre à nos contraintes.