Low-cost program-level detectors for reducing silent data corruptions

Hari, Siva Kumar Sastry; Adve, Sarita V.; Naeimi, Helia

doi:10.1109/dsn.2012.6263960

Cited by 102 publications

(58 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Cost vs. SDC reduction: We note that the objective of estimating SDCs with metrics is to identify an optimal set of SDC-targeted error detectors. We therefore employ a 0/1 knapsack algorithm to find an optimal set of detectors that will provide the largest SDC reduction at a given cost -we assume duplication for detectors and charge one instruction as the cost of duplicating and comparing results for one instruction on average (similar to [11]). Thus, we obtain an SDC reduction vs. cost graph for each application using the known SDC count for each instruction from Relyzer.…”

Section: Metric Evaluationmentioning

confidence: 99%

GangES: Gang error simulation for hardware resiliency evaluation

Hari

Venkatagiri

Adve

et al. 2014

2014 ACM/IEEE 41st International Symposium on Computer Architecture (ISCA)

Self Cite

View full text Add to dashboard Cite

As technology scales, the hardware reliability challenge affects a broad computing market, rendering traditional redundancy based solutions too expensive. Software anomaly based hardware error detection has emerged as a low cost reliability solution, but suffers from Silent Data Corruptions (SDCs). It is crucial to accurately evaluate SDC rates and identify SDC producing software locations to develop software-centric low-cost hardware resiliency solutions.A recent tool, called Relyzer, systematically analyzes an entire application's resiliency to single bit soft-errors using a small set of carefully selected error injection sites. Relyzer provides a practical resiliency evaluation mechanism but still requires significant evaluation time, most of which is spent on error simulations. This paper presents a new technique called GangES (Gang Error Simulator) that aims to reduce error simulation time. GangES observes that a set or gang of error simulations that result in the same intermediate execution state (after their error injections) will produce the same error outcome; therefore, only one simulation of the gang needs to be completed, resulting in significant overall savings in error simulation time. GangES leverages program structure to carefully select when to compare simulations and what state to compare. For our workloads, GangES saves 57% of the total error simulation time with an overhead of just 1.6%. This paper also explores pure program analyses based techniques that could obviate the need for tools such as GangES altogether. The availability of Relyzer+GangES allows us to perform a detailed evaluation of such techniques. We evaluate the accuracy of several previously proposed program metrics. We find that the metrics we considered and their various linear combinations are unable to adequately predict an instruction's vulnerability to SDCs, further motivating the use of Relyzer+GangES style techniques as valuable solutions for the hardware error resiliency evaluation problem.

show abstract

Section: Metric Evaluationmentioning

confidence: 99%

GangES: Gang error simulation for hardware resiliency evaluation

Hari

Venkatagiri

Adve

et al. 2014

2014 ACM/IEEE 41st International Symposium on Computer Architecture (ISCA)

Self Cite

View full text Add to dashboard Cite

show abstract

“…In order to pinpoint the sources of inaccuracy between the actual improvement rates that were determined using accurate flip-flop-level error injection vs. those published in the literature, we conducted error injection campaigns at other 13 Same applications studied in [49]. levels of abstraction (architecture register and program variable).…”

Section: Resilience Librarymentioning

confidence: 99%

“…However, we perform final analysis by incorporating the input data used during evaluation into the training step in order to give the technique the best possible benefit and to eliminate the occurrence of false positives. Checks for control variables (e.g., loop index, stack pointer, array address) are determined using application profiling and are manually added in the assembly code.In Table X, we breakdown the contribution to cost, improvement, and false positives resulting from assertions checking data variables [50] vs. those checking control variables [49]. Table XI demonstrates the importance of evaluating resilience techniques using accurate error injection (explained in [26]).…”

mentioning

confidence: 99%

“…Depending on the particular error injection model used, SDC improvement could be over-estimated for one benchmark and under-estimated for another. For instance, using inaccurate architecture register error injection (regU), one would be led to believe that software assertions provide 3× the SDC improvement than they do in reality (e.g., when evaluated using flip-flop-level error injection).In order to pinpoint the sources of inaccuracy between the actual improvement rates that were determined using accurate flip-flop-level error injection vs. those published in the literature, we conducted error injection campaigns at other 13 Same applications studied in [49]. levels of abstraction (architecture register and program variable).…”

mentioning

confidence: 99%

See 1 more Smart Citation

Tolerating Soft Errors in Processor Cores Using CLEAR (Cross-Layer Exploration for Architecting Resilience)

Cheng

Mirkhani

Szafaryn

et al. 2018

IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst.

View full text Add to dashboard Cite

Abstract-We present CLEAR (Cross-Layer Exploration for Architecting Resilience), a first of its kind framework which overcomes a major challenge in the design of digital systems that are resilient to reliability failures: achieve desired resilience targets at minimal costs (energy, power, execution time, area) by combining resilience techniques across various layers of the system stack (circuit, logic, architecture, software, algorithm). This is also referred to as cross-layer resilience. In this paper, we focus on radiation-induced soft errors in processor cores. We address both single-event upsets (SEUs) and single-event multiple upsets (SEMUs) in terrestrial environments. Our framework automatically and systematically explores the large space of comprehensive resilience techniques and their combinations across various layers of the system stack (586 cross-layer combinations in this paper), derives cost-effective solutions that achieve resilience targets at minimal costs, and provides guidelines for the design of new resilience techniques. We demonstrate the practicality and effectiveness of our framework using two diverse designs: a simple, in-order processor core and a complex, out-of-order processor core. Our results demonstrate that a carefully optimized combination of circuit-level hardening, logic-level parity checking, and micro-architectural recovery provides a highly cost-effective soft error resilience solution for general-purpose processor cores. For example, a 50× improvement in silent data corruption rate is achieved at only 2.1% energy cost for an out-of-order core (6.1% for an in-order core) with no speed impact. However, (application-aware) selective circuit-level hardening alone, guided by a thorough analysis of the effects of soft errors on application benchmarks, provides a cost-effective soft error resilience solution as well (with ~1% additional energy cost for a 50× improvement in silent data corruption rate).Index Terms-Cross-layer resilience; soft errors I. INTRODUCTION HIS paper addresses the cross-layer resilience challenge for designing robust digital systems: given a set of resilience techniques at various abstraction layers (circuit, logic, architecture, software, algorithm), how does one protect a given design from radiation-induced soft errors using (perhaps) a combination of these techniques, across multiple abstraction layers, such that overall soft error resilience targets are met at minimal costs (energy, power, execution time, area)? Specific soft error resilience targets addressed in this paper are: Silent Data Corruption (SDC), where an error causes the system to output an incorrect result without error indication; and, Detected but Uncorrected Error (DUE), This research is supported in part by DARPA, DTRA, NSF, and SRC. The views expressed are those of the authors and do not reflect the official policy or position of the Department of Defense or the U.S. Government.E. Cheng, S. Mirkhani, and S. Mitra are with Stanford University (e-mail: eccheng@ stanford.edu).H. Cho is w...

show abstract

“…Subsequent work [21] uses program invariants to detect SDC but they are susceptible to false positives. Authors in [9] [10] insert program-level detectors in SDC-hot sites to detect them. In this work, to reduce SDCs, we identify the sections of code that are more susceptible to large fault rates and propose architecture independent code transformations.…”

Section: Introductionmentioning

confidence: 99%

Towards analyzing and improving robustness of software applications to intermittent and permanent faults in hardware

Sharma¹,

Sloan²,

Wanner

et al. 2013

2013 IEEE 31st International Conference on Computer Design (ICCD)

View full text Add to dashboard Cite

Abstract-Although a significant fraction of emerging failure and wearout mechanisms result in intermittent or permanent faults in hardware, their impact (as distinct from transient faults) on software applications has not been well studied. In this paper, we develop a distinguishing application characteristic, referred to as similarity from fundamental circuit-level understanding of the failure mechanisms. We present a mathematical definition and a procedure for similarity computation for practical software applications and experimentally verify the relationship between similarity and fault rate. Leveraging dependence of application robustness on the similarity metric, we present example architecture independent code transformations to reduce similarity and thereby the worst-case fault rate with minimal performance degradation. Our experimental results with arithmetic unit faults show as much as 74% improvement in the worst case fault rate on benchmark kernels, with less than 10% runtime penalty.

show abstract

Low-cost program-level detectors for reducing silent data corruptions

Cited by 102 publications

References 22 publications

GangES: Gang error simulation for hardware resiliency evaluation

GangES: Gang error simulation for hardware resiliency evaluation

Tolerating Soft Errors in Processor Cores Using CLEAR (Cross-Layer Exploration for Architecting Resilience)

Towards analyzing and improving robustness of software applications to intermittent and permanent faults in hardware

Contact Info

Product

Resources

About