我想，您首先要收集 DRAM 等组件的错误率，就像 Google 对DRAM Errors in the Wild：一项大规模现场研究的研究他们发现每年有大约 1% 的机会出现一个无法纠正的错误。

我不确定这是否是你感兴趣的。我会对无法检测到的错误更感兴趣。典型的错误检查方法无法检测到的错误。例如，当您通过光学器件发送数据包时，它们会伴随着某种 CRC，这使得发生错误的可能性很小。

更新：这篇论文《多核处理器中的在线错误检测和恢复架构》讨论了可靠的多核架构，但它们也涵盖了系统可靠性的不同方面，并且有参考书目

您是否看过各种已发布的百亿亿次级报告？硬故障在今天并不是一个重要的问题——当然，它们会发生，但它们的频率还不足以引起严重的担忧。但估计它们在百亿亿次系统上足够频繁$O(10^8)$代码需要准备好做出适当反应的或更多内核。我相信这些问题已经在关于百亿亿次级路线图的报告中列出。

我的回忆是，在各种故障模式中，内存或处理器内核中的单个位翻转并不是最重要的问题。而是整个节点宕机，例如由于磁盘故障、操作系统故障等。因此，当前的百亿亿次设计都要求将代码定期检查点到闪存 RAM 中，最好将检查点数据传输到节点外。如果系统遇到一个节点已消失，代码将需要能够从先前保存的状态即时重新启动，并用系统中其他地方的热启动节点替换该节点。

进行此类估算所需的数字是否有良好的来源？

您可以尝试询问您正在计算的集群的管理员。我想作为他们验证过程的一部分，他们面临着估计硬件错误可能性的问题。

听起来很史诗。如果没有人做过这个实验，你可能会考虑运行 100k 个独立的内核，做一些像一遍又一遍地重新散列 sha1 输入的事情，看看错误率是多少。（我怀疑无法测量），从那里做同样的事情，但让他们经常交易哈希链结果以获得您的网络错误率。我想这也很小，但我怀疑你可以在几个小时内至少得到几个使用你的超集群:)

这种方法确保每次计算都是正确的，因为散列对单比特交换极为敏感，而即使是仅整数计算也可能隐藏分支中的错误，即整个计算在每个连续的内存状态上都不会是椭圆的。

我一直在努力确保代码已由外部集群正确运行，其动机是通过提交伪造的结果来作弊。我所采用的解决方案是以某种频率将散列集成到计算中，这使得作弊的效率低于实际工作的效率。