Mining Latency

プールはペトル向けの仕事を用意し、採掘ソフトウェアへ送ります。ソフトウェアは、中継役のプロキシを通して、採掘専用チップである ASIC までメッセージを渡す場合があります。大切なのは新しい仕事への実際の切り替えであり、コンピューターにメッセージが届いた時点だけではありません。機械はその後、プールに仕事を示す部分的な計算結果である shares を送ります。採掘機器の通信プロトコルであるStratum V2のchannel_id と job_id は、メッセージを適切なチャネルと仕事に結び付けます。この対応がないと、ある仕事の開始と別の仕事の終了を測りかねません。 [1]

ペトルは Braiins の診断手順に従って ping を試します。これでサーバーが応答するか、要求が行って返答が戻るまでにどれだけかかるかが分かります。これが RTT、round-trip time です。役立つ最初の確認ですが、往路と復路で経路や待ち行列が違う場合があります。そのため、単純に半分にしても片道の遅れは測れません。Ping ではプールの仕事の準備時間や ASIC の開始時間も分かりません。良好な数値と遅い仕事の切り替えは両立します。 [2] [3]

ここでの例では、送信側が Tsend = 1000 ms、受信側が Trecv = 1040 ms と記録します。差は 40 ms ですが、受信側の時計が 30 ms 進んでいるかもしれません。その場合、単純な引き算は実際の転送時間にはなりません。ms はミリ秒、千分の一秒を意味します。ネットワーク測定の標準であるRFC7679が時計の同期の不確かさやタイムスタンプを取る位置を考慮するのはそのためです。これらが不明なら、サーバー間の差は高速化の証拠ではなく、単に時計の設定の差かもしれません。 [3]

新しいブロックの後に仕事全体を待たずに済むよう、Stratum V2 では Future Job を先に送れます。これは将来のチェーン接続に備えた仕事で、今すぐ始める指示ではありません。SetNewPrevHash が、正しい前ブロックへの参照と対応する job_id を使って有効にします。準備済みの仕事に取引が入っていると、新しいブロックに同じ取引がすでに含まれているなどの理由で、一部を再利用できなくなる場合があります。遅延を減らしたいからといって、この競合を無視してよいわけではありません。誤った仕事を早く始めても、有益な時間短縮にはなりません。 [1]

ペトルには share を送ったことが分かりますが、確認は後から届きます。Stratum V2 の SubmitShares.Success は、受理した複数の shares をまとめて報告できます。意図的なまとめ処理でメッセージ量を抑えるためです。したがって、待ち時間全体を通信の遅れとしたり、その間プールが結果を知らなかったと決め付けたりはできません。SubmitShares.Error も後の検証を経て届くことがあります。sequence_number は返信と提出結果の対応付けに役立ちます。調査では受信、検証、通知を分けて考えます。 [1]

採掘では、誰かがブロックを公開したことを早く知る必要もあります。これは機械とプールの接続とは別の段階です。BIP152 はノード間で送るデータを減らします。high-bandwidth モードでは、ノードはブロックの圧縮された説明である cmpctblock を直接送れます。受信側は手元のデータから大半の取引を補い、不足分を getblocktxn で要求し、blocktxn で受け取ります。このため追加のやり取りが必要になることもあります。データが少ないことは待ち時間ゼロを意味せず、ブロックの全規則を調べる完全な検証の代わりにもなりません。 [4]

ペトルは通常の動作だけでなく、ときどき処理が詰まる場面も知りたいと考えます。p50/p95 はパーセンタイルで、一つの平均ではなく、測定時間の分布の異なる部分を示します。時間を短い順に並べると、p50はおよそ中央、p95は遅い側の端に近い位置になります。約50%の値が前者を、95%の値が後者を下回ります。これによって、普段の待ち時間と長い遅れを区別できます。 ただし、届かなかったメッセージをどう扱ったかの説明が必要です。RFC7679 は待機の上限 Tmax を使い、超過を普通の速い測定とは扱いません。そのパーセンタイル計算では、未定義の遅延を無限大として並べます。黙って除外すれば、紙の上でだけ結果が良くなります。空の標本も遅延ゼロではなく、判断材料がないという意味です。 [3]

ペトルは、同じ段階を似た負荷の下で同じ長さの期間にわたって比較します。ms 単位の測定ごとに、タイムスタンプの位置、時計の不確かさ、対応する job_id を記録し、ping と RTT は別に扱います。停止や拒否された結果も加え、速い平均が不安定さを隠さないようにします。そのうえで、別のサーバー、ネットワーク、機械設定が役立つかを調べます。目標は古くなった仕事に費やす時間を減らすことであり、ブロック発見を約束することではありません。低遅延でも、採掘の偶然性や有効性の規則は変わりません。 [1] [2] [3]