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°C，但它應該穩定在或接近要求的溫度。
如果您發現在啟動或其他動態期間超出了目標溫度，超出了您的舒適度，則應該增加最小風扇速度。
現在，固定風扇速度也將在大約 1-2m 的延遲後在啟動時重新應用，儘管它是一次性應用。這意味著，如果底層 IceRiver 軟體因某種原因決定再次變更風扇速度，此模式將不會重新套用您的設定。考慮使用具有適當最小風扇速度的「目標溫度」模式作為替代方案。
所有晶片指標都添加了兩個小時的圖表，並帶有摘要過濾器（每板最小/最大/平均值）、板或所有晶片。
80c 晶片溫度似乎會帶來理想的算力性能（儘管這在沒有冷卻模組的KS0/Pro 上可能會很困難。）IceRiver 沒有提供有關安全晶片溫度限制的指導，但他們的礦工軟體似乎限制時脈升至95C 以上，並且實際上會將時脈節流到 110C 以上。至少遵循 G/CPU 的一般指導可能是謹慎的（例如 >90C 警告區域、>95C 危險區域、>105C 臨界區域）。
請注意，實時電壓永遠不會與您的設置匹配 - 負載下的驅動器會經歷電壓下降，這意味著運行電壓將始終低於您的電壓設置，負載越大，電壓下降越大。對於 KS5L/M，晶片電壓將被功耗取代，因為沒有可用的晶片電壓讀數。這些型號強制執行 3350W 的軟體限制，如果超過此限制，將以 4 個為一組的核心被停用。
已為所有型號添加了電路板溫度圖表，其中包括進氣和排氣感測器溫度，以及 KS0/Pro/Ultra、KS1 和 KS2 的功率級（驅動器）溫度。在總合模式下，顯示每個板的最大功率級溫度，而在板模式下，顯示每個組/控制器 (PSG) 的最大功率級溫度。根據晶片文檔，建議的最大工作溫度為 125C，但保持低於該溫度的健康裕度可能是明智的。
請注意，溫度並不是健康運作的唯一考慮因素。功率/電流消耗也是一個問題，目前我們還沒有可見性或規格。
算力圖表（以及標題統計數據）現在包括 30m 和 2hr 跟踪，還包括板級過濾。
滑鼠懸停工具提示已在所有圖表中同步，以幫助診斷問題/異常。
瞬時值顯示在圖例中，並且可以透過點擊標籤來停用/啟用單獨的線。圖形比例不再從零開始，並根據顯示的線條進行調整，這意味著它們不再因分辨率差而被人為壓平，並且您實際上可以看到每個測量中的可變性。
希望這有助於澄清 5m 讀數的實際變化。
不間斷的正常運作時間和作業發布率將會新增到池統計資訊部分。作業率只是池連接的一個附加健康指標 - 目前 Kaspa 網路的作業率應約為每秒 1 個（使用 Rust 部署很快將達到 10 個/秒），變化約為 +/- 15%。雖然由於Kaspa 的集體接受政策（假設池沒有不必要地拒絕“舊”股票），工作率持續高於或低於此水平從技術上講不會影響您的收入，但這是一個信號，表明池可能無法正常運行，並且您可能想要提醒泳池操作員，或者可能尋找其他選項。
kaspa-pool 業者表示，他們有意降低工作率以限制開銷，並且這不會影響他們的情況下的過時份額率
池部分新增了多個狀態指示器，以協助診斷不同的網路/池問題。灰色忙碌（旋轉）圖示表示 asic 正在嘗試連接到池。綠色忙碌圖示表示有網路連接，但尚未建立層連接。黃色警告圖示表示層連線成功，但尚未收到任何作業。
雖然連接埠 4111 上先前可用的 API 仍然可用，但現在可以透過 https（連接埠 443）使用包含 UI 中所有附加功能的新合理化 API。
完整文件以 json 格式提供。
許多功能已添加到旨在用於託管或其他大型部署的單獨“商業”版本中。這些版本在版本號後麵包含一個「c」（例如pbv081c_ks5mupdate.bgz ），目前需要額外支付 0.33% 的費用（1.33% 與標準的 1% 相比）。
除了標準的主/管理員使用者之外，還可以新增具有不同存取權限的多個使用者。例如，這允許進行設置，例如，機器所有者可以被授予對機器的直接存取權限，有權查看主監控頁面和更改池配置，同時限制更改網路、風扇或時脈/電壓參數。
ASIC 的算力可以根據可配置的百分比分配給多個端點，以允許設定託管費用。拆分數量不受限制，但請記住，韌體將為每個拆分維護一個池/層連接，這會倍增傳入流量。
此功能還可用於一次將算力分配給多個 KHeavyHash 代幣
「PbFarmer」標誌可以替換為您選擇的品牌形象。影像格式應為 112x60 PNG。
運行狀況檢查循環在主池可用性上運行。如果礦工出於任何原因切換到輔助池之一，一旦主池再次可用，您將立即切換回主池。
用更新的生產環境目標版本替換了庫存 Web 伺服器，添加了快取/記憶體控製配置，並修復了記憶體洩漏。這應該可以解決 HiveOS 和其他外部監控工具使用者遇到的問題，這些問題導致 Web 伺服器在頁面載入過多後崩潰（導致 ASIC UI 不可用）。
身份驗證和授權控制已完全替換，所有流量都透過 https 重定向。這意味著透過防火牆轉送http(s) 流量以進行場外監控應該更安全（儘管我仍然不一定建議這樣做- 只是由於最佳安全實踐...）登入不再通過不安全的http傳輸，人們不能再僅僅透過設定 cookie 來跳過登入來劫持您的 ASIC。由於檔案系統損壞而導致的隨機「登入不正確」訊息也應該成為過去。請記住，這意味著您的密碼將在首次安裝後重設為預設預設值。此外，安裝後首次啟動將需要 2 分鐘以上，因為電腦會產生 TLS 憑證。
此外，重新設計的 API 已透過存取令牌進行保護，透過該令牌可以指派精細的權限。令牌應包含在 API 請求的標頭中，格式為「Authorization: Bearer <token>」。
就像您更新登入密碼一樣，如果您打算公開公開您的計算機，請刪除/替換此 API 令牌，因為預設情況下，所有計算機上的令牌都是相同的。
https 的 TLS 憑證（和憑證授權單位）是在 ASIC 上自動產生的，這意味著它們將在您的瀏覽器中導致「不安全」警告，因為它們不是來自知名機構。雖然這些警告無害，但可能會很煩人，因此韌體提供了下載 CA 憑證的功能，以便將其上傳到瀏覽器的憑證儲存中。
例如，要在Chrome 中執行此操作，請前往chrome://settings/security，按一下“管理憑證”，選擇“受信任的根憑證授權單位”標籤（對於Linux，僅選擇“權威”） ，然後按一下導入按鈕。重新啟動瀏覽器後，您應該不會再看到「不安全」警告。
如果您有多個 ASIC，則預設情況下每個 ASIC 都會有一個不同的 CA。但是，您可以透過從一個ASIC 下載CA 憑證和CA 金鑰，然後將這兩個檔案上傳到所有其他ASIC，從而在所有ASIC 之間傳播單一CA，而不是將其中的每一個都新增到您的瀏覽器或其他裝置中，然後在其他每個 ASIC 上重新產生憑證。
如果您透過網域名稱或多個 IP 存取 ASIC，您也可以將它們新增至 TLS 憑證中，方法是將它們列在「重新產生憑證」欄位中並按一下「重新產生」。
新增了健康檢查循環，如果由於任何原因崩潰，它將自動重新啟動礦工或網路伺服器。
此外，已發現從人們的電腦（甚至是庫存設定）中隨機消失的「重置」可執行檔案現在與韌體打包在一起，並且添加了運行狀況檢查循環以在必要時替換/重新啟動檔案。這應該可以解決許多人遇到的 30m 重啟循環問題。
請勿在 KS0 Ultras 或 KS5* 型號上安裝 xyys（包括 tswift 品牌）韌體。在安裝此韌體或任何其他韌體之前，請務必遵循他的卸載說明！
這是一個標準韌體更新包，包括/改進了最新的 IceRiver 韌體，並像官方韌體一樣應用。應用任何先前的更新應該適用於 KS0/Pro、KS1、KS2 和 KS3* 型號。應用此韌體的庫存版本或早期版本也應適用於 KS0 Ultra 和 KS5* 型號。
但是，如果遇到問題，請嘗試以下過程：
另外，請確保重做您的礦池設置，因為它們將重置為預設的 Kaspa Dev Fund 地址。
KS0/Pro/Ultra 型號的筆記型電腦電源通常應為 19.5V，具有 5.5mm x 2.5mm 連接器，但安培額定值可能會根據您的 OC 目標而有所不同。然而，這種尺寸的桶形連接器往往額定為 5 或 10a，IceRiver 不太可能使用 5a 選項，因此可以合理地假設他們使用 10a（7.5a 是另一種可能性）。這意味著任何超過 200w 的適配器都可能超過插座的額定值，如果不主動冷卻，插頭可能會熔化甚至著火（即使這樣風險仍然存在）。如果您選擇使用較高功率的筆記型電腦充電器選項，請務必小心。
強烈建議您在機器上連接一個功率計，以確保您的功率在 PSU 限制之內。對於 KS3* 和 KS5* 型號尤其如此，即使在庫存設定下，這些型號的 PSU 餘裕也很小，而 KS0* 型號則由於電源範圍廣泛而如此。
KS0 Pro和Ultra型號需要特別注意散熱。這些功率級已經運行得非常熱，因此強烈建議對硬體進行修改以改善冷卻效果 - 包括散熱器和更好的氣流。
所有型號上的哈希晶片往往在 75-80c 範圍內表現最佳，但對於 KS0 Ultra 來說尤其如此，即使從 80c 降低到 75c，我也經歷過 2 小時哈希率下降超過 3%。
在健康的機器上，時鐘偏移百分比和算力增加百分比應該相等。
例如，如果您的時鐘偏移在 KS1 上為 30%，那麼您的算力應為 1.3TH/s，或比預設的 1 TH/s 高 30%。如果情況並非如此（在適當的測量視窗內），則表示您的晶片缺乏電壓。
適當的調整是一個需要時間的過程。使用其他人的設定通常不是一個好主意，因為每台機器都是不同的。最佳實踐是從保守的時脈偏移開始，從而在不改變電壓的情況下實現匹配的哈希率增加。當您進一步以小增量（例如 25mhz 或更低）提高時脈時，一旦您不再看到算力響應 1:1（甚至可能開始下降），則表示需要更多電壓。
此時，將電壓增加一步（KS0 Pro 為 2mv，所有其他型號為 7 或 6mv，取決於電流等級），然後查看算力是否為響應。如果是這樣，並且再次等於基於百分比的時脈偏移，則會返回提高時脈。繼續在時鐘和電壓偏移之間來回進行此操作，直到達到所需的哈希率，同時注意溫度和功率限制。
雖然 GUI 中的 5m 和 30m 算力是機器有時間加速後進行方向引導的有用工具，但最終的算力測量應該在較長的時間內完成。 5 分鐘的算力讀數變化很大，甚至 30 分鐘的算力讀數也不是很好，因為您仍然可能有幾個百分點的變化。根據我的經驗，UI 中 2 小時的讀數變化應該小於 1%（KS5L/M 和 KS0Ultra 上的變化可能略高於 1%），儘管它沒有考慮硬體錯誤/池拒絕。
最後，如果您嘗試複製另一個韌體的 OC 結果...
所有超頻韌體（包括此韌體）僅控制時脈和電壓。根據我的經驗，給定必要的電壓，算力會以 1:1 的比例線性響應時脈變化（按百分比）。但最終，我們所能做的就是改變時脈並希望 ASIC 能回應預期的算力變化。
ASIC UI 中的算力讀數與 CPU/GPU 挖掘中的算力讀數不同。 IceRiver ASIC 不會計算實際的雜湊值 - 它們只是根據產生的份額數量 * 難度來估計雜湊率。這正是礦池測量算力的方式，但問題是大多數礦池決定對 IceRiver ASIC 使用太高的難度，這會妨礙可靠的短期算力測量 - 差異較高，共享率較低，這意味著算力的劇烈波動。因此，IceRiver 發布了韌體更新，開始在自己的儀表板上使用完全不同的、較低的內部難度進行哈希率測量。
因此，即使在相同的精確時間範圍內，您也無法可靠地將池算力測量值與 ASIC UI 算力進行比較 - 它們沒有使用相同的數據。更糟的是，由於 IceRiver 機器早期產生了大量無效份額，許多礦池決定停止向 ASIC 報告被拒絕的份額，這樣用戶就可以停止抱怨（或切換礦池），而是將其報告為已接受，同時仍然默默地拒絕他們。根據真實的拒絕率，這可能意味著 ASIC 算力和礦池算力之間存在顯著差異，即使它們是使用相同的時間範圍和難度進行測量的。
無論選擇何種差異，基於份額 * 難度的算力測量都會根據運氣而波動。份額數越低（差異越大），運氣對算力的影響就越大，波動也越大。因此，要進行具有統計意義的算力測量，您需要足夠的份額來盡可能減少運氣的影響。 ASIC 上的 5m 讀數不適合於此，特別是在嘗試驗證單位數 OC 變化的結果時，短期池讀數甚至更糟。
您需要 1200 股才能以 99% 的置信度獲得 +/- 10% 的預期變異數。例如，對於 1TH/s 的預期雜湊率，在 1200 次分享後的 99/100 測量中，您將得到 0.9TH/s 到 1.1TH/s 之間的讀數。您需要 4800 股才能將差異減少到 +/- 5%。許多礦池正在使用困難，產生約 5 股/分鐘範圍內的份額率。因此，為了獲得預期變異數 <= +/- 10% 的算力讀數，您需要 1200 / 5 = 240 分鐘或 4 小時的讀數。如果您想要預期變異數為 +/- 5% 的讀數，則需要超過 16 小時的數據。您永遠無法確認 OC 水準的結果低於給定時間範圍的預期變異數。例如，您無法確定 5% OC 在 4 小時/1200 共享視窗（預期變異數為 10%）中是否正常運作。即使在 16 小時/4800 股的情況下，預期差異也可以完全抵消 5% 的 OC。
這導致了問題的關鍵 - 大多數礦池不提供高於 24 小時的測量，每分鐘約 5 股意味著大約 7200 股，這仍然是 4% 的預期變異數。您需要 10K 股才能獲得 3.3% 的方差，而大約 100K 股才能獲得 1% 的方差。 ASIC UI 中的 30m 讀數應有大約 2% 的方差，而新的 2hr 讀數應有小於 1% 的方差，但這兩者都沒有反映池拒絕。因此，唯一的解決方案是找到一個可以讓您設定自己的難度的池，以便您可以在可用時間範圍內產生統計上相關的份額數量。 Herominers 就是這樣一個池子，可以實現這一點。
設定自己的差異並查看足夠長的測量時間範圍的最佳選擇是單獨挖掘您自己的節點和 kaspa-stratum-bridge。預設的vardiff 設定將產生至少20 股/分鐘，這足以在4 小時內產生<= +/- 5% 的方差，並且儀表板(grafana) 允許在您想要的任何時間範圍/分辨率下進行測量，包括比24小時。
作為有效和無效測量之間差異的具體示例（以及 kaspa-stratum-bridge 如何提供幫助），這裡是 3 台機器的哈希值讀數，使用 diffs 產生 >= 30 股/分鐘，51% OC 的 KS0， KS1 為37% OC，KS3M 為1% OC。測量值由上至下分別為 24 小時（>= 43K 股）、1 小時（>= 1800 股）及 30m（>= 900 股）。您可以看到較短時間範圍內的測量結果與預期有多麼不同：
簡而言之，如果您試圖確認小型 OC 對 ASIC UI 的影響，您將需要使用 2 小時讀數，但您不會知道您是否正在產生將被拒絕的份額。為了獲得全面的了解，您將需要從允許高共享率的池中進行長期測量 - 除了挖掘到您自己的節點 + kaspa-stratum 之外，我目前沒有可以指出的選項可以做到這一點。
