Uptime

観測期間のうち 23 時間、条件を満たした機器を考えます。全期間が 24 時間なら、この例の uptime は約 95.83 % です。保守の時間を対象外にすると、機器がしたことは変わらないのに割合が変わります。したがって例外を明示しなければなりません。米国国立標準技術研究所（NIST）は可用性をサービスや情報への利用可能なアクセスに結び付けており、全マイニング共通の割合を決めてはいません。まずサービスと期間を定め、それから数値を評価します。 [1]

Hashrate は毎秒のマイニング試行回数です。Braiins は 2026 年の説明で Worker System Uptime と Worker Hashing Uptime を区別しています。前者は機器が応答したか、後者は hashrate がゼロでない時間帯を追います。そのため計算が止まっていても管理画面には接続できます。逆に、少し計算しているだけではメーカーの定格性能を達成したことになりません。両方を見ると有用ですが、どちらも単独では結果全体を説明できません。 [2]

Braiins Manager は必要なデータがないと Unknown を表示します。Agent Offline はデータを収集して中継するサービス、つまりエージェントが応答しない状態です。それだけで採掘停止とは言えません。監視が故障しても機器は働き続けているかもしれません。反対に、欠測を自動的に正常稼働と数えることもできません。不明な時間を別に示すか、計算上の扱いを説明します。そうしないと同じ欠測が異なる画面で逆の印象を生みます。 [3]

Mining Pool は採掘者の仕事をまとめ、独自の規則で報酬を配分します。機器は全試行ではなく、プールのより易しい条件を満たした結果、shares を送ります。Braiins Pool はこの提出結果から実効 hashrate を推定します。短期間では shares が見つかる偶然性や接続品質が数値に影響します。プール側の低い値を、そのまま同じ割合の停止時間に読み替えてはいけません。同じ期間を比べ、仕事が届いて受理されたかを先に確かめます。 [4]

Braiins Pool の監視で Offline は hashrate が検出されなかったことを示します。機器へのネットワーク接続を直接試しているわけではありません。資料では 5 分ごとに記録し、OK から Low への移行には設定しきい値未満が連続する二つの期間が必要です。Disabled は監視の無効化であって、採掘停止ではありません。赤や灰色の表示は調査の出発点であり、診断結果ではありません。別のツールなら同じ名前でも定義が異なり得ます。 [5]

Braiins Manager のダッシュボード資料は、データ更新を 5 分ごと、測定値を時間順に並べた時系列データの遅延を 20 分としています。画面更新の時刻と表示される出来事の時刻は別です。アラームを調べる際、最後の点に処置後の変化や現在の状態がまだ映っていない場合があります。判断前に出来事の時刻、タイムゾーン、点の古さを確認しましょう。この間隔は引用資料の仕様であり、すべての監視ツールに共通ではありません。 [6]

Curtailment は、電気代が高いときや電力系統から求められたときなどに、意図的に稼働を抑えることです。Braiins は、この場合の低い hashing uptime が技術的故障を意味するとは限らないと説明しています。報告では計画的制限、保守、予期しない故障を分けます。どれも計算時間を減らしますが、必要な判断は異なります。高い uptime だけで利益増とも言えません。電気代、性能、受理された仕事も重要です。 [2]

Worker はプールが仕事を記録する名前です。Braiins Pool は同名の複数機器を一括監視するため、その合計だけでは個々を診断できません。この例では両方の機器を同じ期間で比較します。各機器の重みは、両機器の定格 hashrate の合計に対する、その機器の割合です。例として 100 TH/s と 200 TH/s、つまり毎秒の兆単位の試行回数を持つ機器を考え、uptime を 100 % と 50 % とします。単純平均は 75 % ですが、定格 hashrate で重み付けすると 66.67 % です。高性能な機器の停止が重く数えられます。それでも受理済み shares の測定ではなく、稼働時間の別の集約方法です。重みを明示する必要があります。 [5]