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 之外，我目前没有可以指出的选项可以做到这一点-桥。
