Demo Data from EDBT 2026 / reviewers in the wild / expert
Menachem Berg
dblp:85/5850
· DBLP profile ↗
1ranked-venue papers
1as first author
0since 2021 · last 1987
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 1 · 1 first-author
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Hardware reliability and fault tolerance · 100% |
Topics — the 2 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Hardware reliability and fault tolerance
error recovery |
0.0 | 1 | 1987 | On Switching Policies for Modular Redundancy Fault-Tolerant Computing Systems · IEEE Trans. Computers 1987 |
Hardware reliability and fault tolerance › redundancy
modular redundancy |
0.0 | 1 | 1987 | On Switching Policies for Modular Redundancy Fault-Tolerant Computing Systems · IEEE Trans. Computers 1987 |
Methods — techniques the papers use, named apart from their topics
markov modeling · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1987 | On Switching Policies for Modular Redundancy Fault-Tolerant Computing SystemsabstractThe objective of fault-tolerant computing systems is to provide an error-free operation in the presence of faults. The system has to recover from the effects of a fault by employing certain recovery procedures like program rollback, reload, and restart, etc. However, these recovery procedures, result in interruptions in the system's operation, thus reducing the availability of the system for user applications. Fault-tolerant systems for critical applications include, therefore, standby spares that are ready to replace active modules which fail to recover from the effects of a fault. A standby spare may also be used to replace a module suffering from frequent fault occurrences resulting in too many repetitions of the recovery process, in order to increase the availability of the system for user applications. In this case a module switching policy is needed indicating upon a fault occurrence, whether to retry a failing module or switch it out and replace it by a spare, considering the remaining mission time and the probability of a system crash. A module switching policy for dynamic redundancy systems is presented in this paper and the improvement in application-oriented availability due to the use of this policy is illustrated. Menachem Berg, Israel Koren |
IEEE Trans. Computers | 1 |