iceriver oc
ver ASICs
すべての IceRiver ASIC のファームウェアを変更し、クロックと電圧の制御、センサーのグラフ作成、適切に保護されたログインと API アクセス、その他の機能を追加しました。
カスタマイズ可能な OC/OV、コミュニティに利益をもたらす少額の料金、デバイスへの不必要な変更は不要です。
ファームウェア ファイルは、このページの右側にあるリリース セクションからダウンロードできます。
何か問題がある場合は、Kaspa Discord で私 (pbfarmer) を見つけると、おそらく最も早く対応/解決できるでしょう。
これらのファームウェアはどれも、テストとフィードバックにおける多くの人々の努力なしには実現できませんでした。
しかし、特にある人物は最初から自分のマシンを犠牲にし、私に開発への直接アクセスを許可し、新しい機能をテストする際に彼のマシンを危険にさらすことを許可し、頻繁なアップデートと再起動中に何度もマイニングが中断されました。
この人は Discord のハンドル名 Onslivion を名乗っています。Kaspa Discord で彼に感謝の気持ちを伝え、チップやハッシュレートを送っていただければ幸いです。
カスパ:qzh2xglq33clvzm8820xsj7nnvtudaulnewxwl2kn0ydw9epkqgs2cjw6dh3y
クロックと電圧の設定が「マイナー」ページに追加されました。クロックは、(ハードウェアの制限内で) 任意の整数値に増減できます。変更は再起動しなくてもすぐに有効になりますが、クロックの増加は 30 秒ごとに 25Mhz ずつ徐々に適用されることに注意してください。その結果、フルスピードに達するまでに時間がかかる場合があり、選択したオフセットの大きさによっては、最大 10 分かかる場合もあります。
電圧は（ハードウェア制限内で）任意の整数値に増減することもでき、変更はすぐに有効になります。 KS0 Pro を除くすべての設定は、内部的に 6.25mV の最も近い倍数に切り捨てられます。覚えておくべき簡単なモデルは、25mv 増加ごとに、適切な増分は 7mv-6mv-6mv-6mv、つまり最初の 25mv では 7、13、19、25 であるということです。
KS0 Pro の場合、電圧は 2mV 単位で調整できます。
現時点では、KS3/M/L では電圧制御は利用できません。
重要: 現在のところ、このソフトウェアにはガードレールがなく、クロックや電圧についても制限が適用されていないため、注意して使用してください。
ハッシュ チップとボードの最大温度の両方を維持するためにファン速度を自動的に調整する新しいファン モードが追加されました。温度は 10 秒ごとに読み取られ、必要に応じてファン速度が調整されます。
この設定は設定温度を保証するものではありませんのでご了承ください。起動時やその他の動的期間中には最大 5℃ 超える可能性がありますが、要求された温度またはそれに近い温度で安定するはずです。
起動時やその他の動的期間中に、目標温度が快適さを超えていることが判明した場合は、最小ファン速度を上げる必要があります。
固定ファン速度は、1 ～ 2 メートルの遅延の後、起動時に再適用されるようになりましたが、これは 1 回限りの適用です。これは、基盤となる IceRiver ソフトウェアが何らかの理由でファン速度を再度変更することを決定した場合、このモードでは設定が再適用されないことを意味します。代わりに、適切な最小ファン速度を指定した「ターゲット温度」モードの使用を検討してください。
すべてのチップ メトリクスに対して 2 時間のグラフ作成が追加され、概要 (ボードごとの最小/最大/平均)、ボード、またはすべてのチップのフィルターが追加されました。
チップ温度が 80 度であれば、理想的なハッシュレート パフォーマンスが得られるようです (ただし、冷却モジュールなしの KS0/Pro ではこれは難しいかもしれません)。 IceRiver からは安全なチップ温度制限に関するガイダンスは提供されていませんが、同社のマイナー ソフトウェアは 95 度以上のクロック上昇を制限しているようです。 、110℃を超えると実際にクロックがスロットルされます。少なくとも G/CPU からの一般的なガイダンスに従うことがおそらく賢明です (例: >90℃ の警告ゾーン、>95℃の危険ゾーン、>105℃のクリティカル ゾーン)。
リアルタイムの電圧は決して設定と一致しないことに注意してください。負荷がかかるとドライバーは電圧降下を経験します。つまり、動作電圧は常に設定電圧を下回り、負荷が増えると降下が大きくなります。 KS5L/M ではチップ電圧の読み取りができないため、チップ電圧は消費電力に置き換えられます。これらのモデルには 3350W のソフトウェア制限が適用されており、この制限を超えるとコアが 4 つのグループで無効になります。
ボード温度グラフがすべてのモデルに追加されました。これには、吸気および排気センサーの温度と、KS0/Pro/Ultra、KS1、KS2 のパワー ステージ (ドライバー) の温度が含まれます。サマリー モードでは、最大パワー ステージ温度が各ボードに表示されます。一方、ボード モードでは、最大パワー ステージ温度が各グループ/コントローラー (PSG) に表示されます。チップのマニュアルによると、最大推奨動作温度は 125℃ ですが、この温度よりも低い温度に十分な余裕を持たせることが賢明でしょう。
正常な動作を考慮するには温度だけが考慮されるわけではないことに注意してください。消費電力/消費電流も懸念事項ですが、現時点ではそれに関する見通しや仕様がありません。
ハッシュレート グラフ (およびヘッドライン統計) には、30 分と 2 時間の追跡が含まれるようになり、ボード レベルのフィルタリングも含まれます。
マウスオーバーのツールチップはすべてのグラフで同期されており、問題や異常の診断に役立ちます。
瞬時値は凡例に表示され、ラベルをクリックすることで個々の行を無効または有効にできます。グラフのスケールはゼロベースではなくなり、表示される線に応じて調整されます。つまり、解像度が低いためにグラフが人為的に平らになることがなくなり、各測定値のばらつきを実際に確認できるようになります。
これが、5 メートルの測定値が実際にどれほど変動するかを理解するのに役立つことを願っています。
中断のない稼働時間とジョブ発行率がプール統計セクションに追加されます。ジョブ レートは、単にプール接続の追加の健全性指標です。現在、Kaspa ネットワークのジョブ レートは 1 秒あたり 1 程度 (Rust のデプロイでは間もなく 10/秒になる予定) で、変動はおよそ +/- 15% です。 Kaspa のブロック受け入れポリシーにより、ジョブレートが一貫してこれより高いか低い場合は、技術的には収益に影響を与えることはありませんが (プールが不必要に「古い」株式を拒否していないことを前提としています)、これはプールが適切に機能していない可能性があることを示す信号です。プール運営者に警告するか、別の選択肢を見つけたいと思うかもしれません。
kaspa プールのオペレーターからは、オーバーヘッドを制限するために意図的にジョブ レートを下げており、彼らの場合は古いシェア レートには影響しないと伝えられています。
さまざまなネットワーク/プールの問題の診断に役立つように、複数のステータス インジケーターがプール セクションに追加されました。灰色のビジー (回転) アイコンは、ASIC がプールへの接続を試行していることを示します。緑色のビジーアイコンは、ネットワーク接続はあるものの、まだ階層接続されていないことを示します。黄色の警告アイコンは、階層接続は成功したが、ジョブが受信されていないことを示します。
以前にポート 4111 で利用できた API は引き続き利用できますが、UI のすべての追加機能を含む新しい合理化された API が https (ポート 443) 経由で利用できるようになりました。
完全なドキュメントは json 形式で入手できます。
ホスティングやその他の大規模な展開を目的とした別の「商用」ビルドに、多くの機能が追加されました。これらのビルドにはバージョン番号の後に「c」が含まれており (例: pbv081c_ks5mupdate.bgz )、現在 0.33% の追加料金がかかります (標準の 1% に対して 1.33%)。
標準のプライマリ/管理ユーザーに加えて、異なるアクセス権限を持つ複数のユーザーを追加できます。これにより、たとえば、マシンの所有者にマシンへの直接アクセスを許可し、ネットワーク、ファン、またはクロック/電圧パラメータの変更を制限しながら、メインの監視ページを表示し、プール構成を変更する権限を与えることができるセットアップが可能になります。
ASIC のハッシュパワーは、構成可能なパーセンテージに基づいて複数のエンドポイントに分割され、ホスティング料金を設定できるようになります。スプリットの数に制限はありませんが、ファームウェアはスプリットごとにプール/ストラタム接続を維持するため、受信トラフィックが増加することに注意してください。
この機能は、一度に複数の KHeavyHash コインにハッシュレートを分割するために使用することもできます。
「PbFarmer」ロゴは、選択したブランド イメージに置き換えることができます。画像形式は 112x60 PNG である必要があります。
ヘルスチェック ループはプライマリ プールの可用性に対して実行されます。何らかの理由でマイナーがセカンダリ プールの 1 つに切り替えた場合、プライマリ プールが再び利用可能になるとすぐに、プライマリ プールに戻されます。
ストック Web サーバーを更新された運用環境を対象としたバージョンに置き換え、キャッシュ/メモリ制御構成を追加し、メモリ リークを修正しました。これにより、HiveOS やその他の外部監視ツールのユーザーが見ていた、ページの読み込みが多すぎると Web サーバーがクラッシュする (その結果、ASIC UI が使用できなくなる) という問題が解決されるはずです。
認証と認可の制御は完全に置き換えられ、すべてのトラフィックは https 経由でリダイレクトされました。これは、オフサイト監視のためにファイアウォールを介して http トラフィックを転送する方がはるかに安全であることを意味します (ただし、これを必ずしもお勧めするわけではありません。単にセキュリティのベストプラクティスのためです...) ログインは、セキュリティで保護されていない http 経由で送信されなくなりました。また、Cookie を設定してログインをスキップするだけで、ASIC を乗っ取ることはできなくなります。ファイル システムの破損によるランダムな「ログインが正しくありません」メッセージも過去のものとなるはずです。これは、最初のインストール後にパスワードが標準のデフォルトにリセットされることを意味することに注意してください。また、インストール後の最初の起動では、マシンが TLS 証明書を生成するため、2 分以上かかります。
さらに、再設計された API はアクセス トークンで保護されており、これによりきめ細かい権限を割り当てることができます。トークンは、API リクエストのヘッダーに「Authorization: Bearer <token>」という形式で含める必要があります。
ログイン パスワードを更新するのと同じように、マシンを公開する予定がある場合は、この API トークンを削除/置換してください。これは、デフォルトではすべてのマシンで同じであるためです。
https の TLS 証明書 (および認証局) は ASIC 上で自動的に生成されます。つまり、よく知られた認証局からのものではないため、ブラウザーで「安全ではありません」という警告が表示されます。これらの警告は無害ですが、煩わしい場合があるため、ファームウェアには CA 証明書をダウンロードしてブラウザの証明書ストアにアップロードできる機能が用意されています。
たとえば Chrome でこれを行うには、chrome://settings/security に移動し、[証明書の管理] をクリックし、[信頼されたルート証明機関] タブ (Linux の場合は単に [機関]) を選択し、インポートをクリックします。ボタン。ブラウザを再起動すると、「安全ではありません」という警告は表示されなくなります。
複数の ASIC がある場合は、デフォルトでそれぞれに異なる CA が設定されます。ただし、これらのそれぞれをブラウザや他のデバイスに追加する代わりに、1 つの ASIC から CA 証明書と CA キーの両方をダウンロードし、両方のファイルを他のすべての ASIC にアップロードすることで、すべての ASIC に単一の CA を伝播できます。次に、他の各 ASIC で証明書を再生成します。
ドメイン名または複数の IP を介して ASIC にアクセスする場合は、「証明書の再生成」フィールドにリストして「再生成」をクリックすることで、これらを TLS 証明書に追加することもできます。
ヘルスチェック ループが追加されました。これにより、マイナーまたは Web サーバーが何らかの理由でクラッシュした場合に自動的に再起動されます。
さらに、人々のマシン (ストックセットアップであっても) からランダムに消えることが判明した「リセット」実行可能ファイルがファームウェアにパッケージ化され、必要に応じてファイルを置換/再起動するためのヘルスチェックループが追加されました。これにより、多くの人が経験している 30 分間の再起動ループに対処できるはずです。
KS0 Ultras または KS5* モデルでは、xyys (tswift ブランドを含む) ファームウェアを上書きインストールしないでください。このファームウェアまたは他のファームウェアをインストールする前に、必ず彼のアンインストール手順に従ってください。
これは、最新の IceRiver ファームウェアを含む/改良された標準ファームウェア アップデート パッケージであり、公式ファームウェアと同様に適用されます。以前のアップデートを上書き適用すると、KS0/Pro、KS1、KS2、KS3* モデルに適用できるはずです。このファームウェアのストックまたは以前のバージョンに適用することは、KS0 Ultra および KS5* モデルにも機能するはずです。
ただし、問題が発生した場合は、次のプロセスを試してください。
また、プール設定はデフォルトの Kaspa Dev Fund アドレスにリセットされるため、必ずやり直してください。
KS0/Pro/Ultra モデルのラップトップ電源は通常、5.5mm x 2.5mm コネクタを備えた 19.5V である必要がありますが、アンプ定格は OC ターゲットによって異なる場合があります。ただし、このサイズのバレル コネクタは 5 または 10a の定格となる傾向があり、IceRiver が 5a のオプションを使用した可能性は低いため、10a を使用したと考えるのが合理的です (7.5a の可能性もあります)。これは、200 W を超えるアダプターはソケットの定格を超えている可能性が高く、積極的に冷却しないとプラグが溶けたり発火したりする可能性があります (それでもリスクは残ります)。高出力のラップトップ充電器オプションのいずれかを選択する場合は、細心の注意を払ってください。
PSU の制限内に収まっていることを確認するために、マシンにパワー メーターを接続することを強くお勧めします。これは特に、純正設定でも PSU ヘッドルームが非常に少ない KS3* および KS5* モデル、および電源の範囲が広いため KS0* モデルに当てはまります。
KS0 Pro および Ultra モデルでは、冷却に特別な注意が必要です。これらのパワーステージはすでに非常に高温になっているため、ヒートシンクやエアフローの改善など、冷却を改善するためのハードウェアの変更を強くお勧めします。
すべてのモデルのハッシュ チップは 75 ～ 80c の範囲で最高のパフォーマンスを発揮する傾向がありますが、これは KS0 Ultra に特に当てはまり、80c から 75c に下げただけでも、2 時間のハッシュ レートが 3% を超える低下を経験しました。
健全なマシンでは、クロック オフセットのパーセンテージとハッシュレートの増加パーセンテージは等しくなるはずです。
たとえば、クロック オフセットが KS1 で 30% の場合、ハッシュレートは 1.3TH/s、つまりデフォルトの 1 TH/s より 30% 大きい必要があります。これが当てはまらない場合（適切な測定ウィンドウ上で）、チップが電圧に不足していることを意味します。
適切なチューニングは時間のかかるプロセスです。マシンごとに異なるため、他の人の設定を使用することは一般的に良い考えではありません。ベスト プラクティスは、電圧を変更せずに一致するハッシュ レートの増加が得られる控えめなクロック オフセットから開始することです。さらにクロックを少しずつ上げていくと (例: 25mhz 以下)、ハッシュレートが 1:1 で応答しなくなる (あるいは低下し始める) と、より多くの電圧が必要であることを示しています。
その時点で、電圧を 1 ステップ (KS0 Pro の場合は 2mv、他のすべてのモデルの場合は電流レベルに応じて 7 または 6mv) 増加させ、ハッシュレートが応答するかどうかを確認します。一致し、パーセンテージベースで再びクロックオフセットと等しくなった場合は、クロックを上げる作業に戻ります。温度と電力の制限に注意しながら、目的のハッシュレートに達するまで、クロックと電圧のオフセットの間でこの作業を繰り返します。
GUI の 5m および 30m ハッシュレートは、マシンが立ち上がるまでの時間が経過した後の方向性を示すための便利なツールですが、最終的なハッシュレート測定は長期間にわたって実行する必要があります。 5 分間のハッシュレートの読み取り値は非常にばらつきがあり、30 分間のハッシュレートの読み取り値でも数パーセントの変動がある可能性があるため、それほど優れたものではありません。 UI での 2 時間の読み取り値の変動は、私の経験からすると 1% 未満であるはずです (KS5L/M および KS0Ultra では 1% をわずかに超える可能性があります)。ただし、ハードウェア エラーやプールの拒否は考慮されていません。
最後に、別のファームウェアの OC 結果を複製しようとしている場合...
このファームウェアを含むすべての OC ファームウェアは、クロックと電圧のみを制御します。私の経験では、必要な電圧が与えられれば、ハッシュレートはクロックの変化に対して 1 対 1 で直線的に応答します (パーセント単位)。しかし、最終的に私たちにできることは、クロックを変更し、ASIC が予想どおりのハッシュレート変更で応答することを祈ることだけです。
ASIC UI でのハッシュレートの読み取り値は、CPU/GPU マイニングからの読み取り値とは異なります。 IceRiver ASIC は実際のハッシュをカウントしていません。単に生成されたシェアの数 * 難易度に基づいてハッシュレートを推定しているだけです。これはまさにプールがハッシュレートを測定する方法ですが、問題は、ほとんどのプールが IceRiver ASIC に対して高すぎる難易度を使用することを決定していることです。そのため、信頼できる短期ハッシュレート測定が妨げられます。差分が高いと、共有率が低くなります。つまり、ハッシュレートの乱高下。その結果、IceRiver は、独自のダッシュボードでのハッシュレート測定に、まったく異なる、より低い内部難易度の使用を開始するファームウェア アップデートをリリースしました。
したがって、正確に同じ時間枠であっても、プールのハッシュレート測定と ASIC UI ハッシュレートを確実に比較することはできません。これらは同じデータを使用していないためです。これをさらに悪化させるのは、IceRiver マシンが初期に大量の無効な共有を生成していたため、多くのプールが拒否された共有を ASIC に報告することを中止することを決定し、ユーザーが苦情を言う (またはプールを切り替える) のをやめ、代わりに受け入れられたものとして報告するようにしたことです。 、それでも彼らの側では黙って拒否しながら。これは、実際の拒否率によっては、同じ時間枠と難易度を使用して測定された場合でも、ASIC ハッシュレートとプール ハッシュレートの間に大きな相違があることを意味する可能性があります。
選択した差分に関係なく、シェア * 難易度に基づくハッシュレートの測定は、運に基づいて変動する可能性があります。シェア数が低いほど（差分が高いほど）、運によるハッシュレートの影響が大きくなり、変動が激しくなります。したがって、統計的に意味のあるハッシュレート測定を行うには、運の影響をできるだけ減らすのに十分なシェアが必要です。 ASIC の 5 メートルの読み取り値は、特に 1 桁の OC 変更の結果を検証しようとする場合には適しておらず、短期のプール読み取り値はさらに悪くなります。
99% の信頼度で +/- 10% の予想分散に到達するには、1,200 株が必要です。たとえば、予想されるハッシュレートが 1TH/s の場合、1200 シェア後の 99/100 の測定では、測定値は 0.9TH/s から 1.1TH/s になります。この差異を +/- 5% に減らすには 4,800 株が必要です。多くのプールでは、最大 5 シェア/分の範囲のシェア レートを生成する難易度が使用されています。したがって、期待分散 <= +/- 10% でハッシュレートの読み取り値を取得するには、1200 / 5 = 240 分、つまり 4 時間の読み取り値が必要になります。予想分散 +/- 5% の読み取り値が必要な場合は、16 時間以上のデータが必要になります。特定の時間枠の予想分散を下回る OC レベルの結果を確認することはできません。たとえば、10% の予想分散がある 4 時間/1200 シェア ウィンドウで 5% の OC が適切に機能しているかどうかを判断することはできません。 16 時間 / 4800 株であっても、予想される差異により 5% の OC が完全に打ち消される可能性があります。
そして、これが問題の核心につながります。ほとんどのプールでは 24 時間の測定値以上のものは提供されていません。これは、〜 5 株/分で約 7,200 株を意味しますが、それでも 4% の予想差異です。差異が 3.3% の場合は 10,000 株が必要で、差異が 1% の場合は約 100,000 株が必要です。 ASIC UI の 30 分の読み取り値には約 2% の差異があり、新しい 2 時間の読み取り値には 1% 未満の差異があるはずですが、どちらもプールの拒否を反映していません。したがって、唯一の解決策は、独自の難易度を設定できるプールを見つけて、利用可能な時間枠に対して統計的に適切な数のシェアを生成できるようにすることです。 Herominers は、これを可能にするプールの 1 つです。
独自の差分を設定し、十分な長さの測定タイムフレームを確認するための最良のオプションは、独自のノードと kaspa-stratum-bridge へのソロマイニングです。デフォルトの vardiff 設定では、最小 20 シェア/分が生成されます。これは、4 時間で <= +/- 5% の分散を持たせるのに十分です。また、ダッシュボード (grafana) では、これより大幅に長い時間枠を含む、任意の時間枠/解像度での測定が可能です。 24時間。
有効な測定と無効な測定の違い (および kaspa-stratum-bridge がどのように役立つか) の具体例として、30 シェア/分以上、51% OC の KS0 を生成する差分を使用した 3 台のマシンのハッシュレート測定値を次に示します。 KS1 は 37% OC、KS3M は 1% OC です。測定値は上から順に、24 時間 (>= 43,000 シェア)、1 時間 (>= 1,800 シェア)、および 30 分 (>= 900 シェア) です。短い時間枠で測定値が予想からどの程度乖離する可能性があるかを確認できます。
つまり、ASIC UI での小規模な OC の影響を確認しようとしている場合は、2 時間の読み取り値を使用する必要がありますが、拒否される共有を生成しているかどうかはわかりません。全体像を把握するには、高いシェア率を可能にするプールから長期的な測定が必要になります。そして、現時点では、独自のノードとカスパ層へのマイニング以外にこれを実行できるオプションはありません。 -橋。
