Network is the largest fail-slow hardware type: 29 of 112 occurrences in 101 reports

The named comparison is root-cause occurrences, not a failure rate. Network is the largest hardware type at 29 of 112, then CPU 25, disk 23, SSD 22, and memory 13. Device errors (40) and firmware issues (20) are the two largest cause rows. On SSD, disk, and network the device-error cells are 10, 8, and 10, and the firmware cells are 6, 3, and 9. Memory is not a firmware story in this table: 9 device errors and 0 firmware. CPU is not mainly an internal-device story either: the CPU column is device errors 3, firmware 2, temperature 5, power 6, environment 4, configuration 3, and unknown 2. The 112 is the cell total. The caption of Table 3 says a report can have multiple root causes, environment and power or temperature among them, so 112 is larger than the 101 reports.

The external fault is a device that is functionally up but slow because of temperature, power, environment, or configuration. Proceedings Table 1 says 39% of root causes are external factors, so troubleshooting fail-slow hardware must be done online. The signal that catches that class is online diagnosis with full-stack monitoring, not a bench retest. ;login: says some reports suggest operators took days or even months because the problem could not be reproduced in offline testing, and that not all hardware is monitored. Its example is network cables: several organizations watched traffic flow as a proxy for cable health instead of monitoring the cables, and blame went to the main components first. The proceedings’ own network examples of external causes include loose network cables and pinched fiber. Offline reproduction misses a cause that appears only in the live rack. Full-stack monitoring still misses whatever component nobody instrumented. Section 3.5 says pinpointing took hours or even months, for reasons that include no full-stack visibility, environment conditions, and cascading causes. The minute-to-month percentage split in that section is not a row in the table on this page.

The internal fault is a device error or wear-out, or a firmware issue. Proceedings Table 1 tells vendors that when error masking becomes more frequent, the device should throw a more explicit signal instead of running with a high overhead, and that device-level performance statistics should be collected and reported, for example via S.M.A.R.T. That suggestion is not a measurement of SMART in these 101 reports. Section 2 says there were no analyzable hardware-level performance logs, which is why this is an interview-style study rather than a log study. The signal that table cannot show is a counter that was never collected. What remains unknown is the unknown row: 8 occurrences in which operators could not pinpoint the cause and replaced the hardware. That is separate from the 12% of reports that did not pinpoint a root cause. Replacing the part shows that the machine was put back, not which fault it was, and not whether the same fault will recur. The SMART failure-signal note and the Alibaba NVMe fail-slow note are other populations. Their percentages are not rates for these 12 institutions.

One report can prove that an institution recorded an unexpected degradation and, when the operators named it, a root cause tied to a hardware type. It cannot prove how often that fault occurs, how large the slowdown was across the 101, or a tie to age, model, size, or vendor. Section 7 states those as the questions the anecdotes could not answer. The introduction’s 100 KB/s disk, seconds-long SSD stall, Kbps network card, 25% memory, and 50% CPU examples are illustrations of that kind of story, not columns in Table 3. The journal author PDF’s 114 reports, 14 institutions, and 32% external figure are a later edition with an unfilled ACM template header. They are not substituted into this table. The FAST ’18 errata slip does not revise the cells.