Mining Latency

矿池为彼得准备任务，把它发给挖矿软件。软件可能通过中间代理 proxy，将消息传到 ASIC，也就是专为挖矿设计的芯片。真正重要的是机器切换到新任务，而不只是消息到达电脑。随后，矿机会提交 shares：这些部分计算结果用于向矿池证明自己做了工作。在矿机通信协议Stratum V2中，channel_id 和 job_id 把消息与正确的通道和任务对应起来。没有这种对应关系，我们可能把一个任务的起点和另一个任务的终点算在一起。 [1]

彼得按照 Braiins 的诊断说明运行 ping。它可以检查服务器是否回应，以及请求去、回复回来的总时间，即 RTT，也称 round-trip time。这是有用的第一步。但两个方向可能经过不同路径、遇到不同排队，直接除以二并不能测出单向延迟。Ping 也不显示矿池准备任务或 ASIC 启动计算需要多久。因此，ping 很好与任务切换缓慢完全可能同时出现。 [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]