支持协议的标志不等于当前已连接
核对比特币挖矿机连接资料，先确认字段出自哪种固件。LuxOS的pools文档列出Status，其含义是矿池连接状态，可取Dead、Connecting、Alive或Disabled。Stratum Active则在Alive时为真。它们是具体产品给出的状态定义，不能直接推广成所有矿机界面都使用同一判断。
同一页面的Has Stratum却被列为始终为真。这个差别很关键：名字里带有Stratum，不代表字段一定在测量当前连通性。若一份记录只有Has Stratum为真，却没有连接状态和读取时点，就不应据此写成矿池通信一直正常，更不能从网口指示灯推断服务器已接受计算结果。
收到任务与接受份额分别计数
LuxOS文档将Getworks定义为从服务器收到的任务数，将Accepted定义为接受的份额数。这是两个不同阶段。任务下发说明软件取得了工作资料；份额被接受才对应另一项处理结果，不能把收到十个任务写成已完成十个区块，也不能假定每次任务下发必然只产生一个份额。
Bitcoin开发指南对矿池工作方式解释了这种区别：矿池会使用比网络出块要求更容易达到的份额目标，很多提交能满足矿池要求，却不满足区块进入链的目标。只有其中满足网络目标的情况才涉及出块。因此，Accepted增加可以作为份额记录的一项证据，不能据此声称同等数量的区块已经形成。
数量、难度合计与时间不能混算
在这份LuxOS文档中，Difficulty Accepted表示接受份额的难度合计，并非Accepted的另一个名称。Rejected计的是被拒绝且非过时的份额，Stale另列过时份额。整理表格时应保留这些限定，不要把所有带Rejected字样的数量或百分比直接当作同一个指标。
Last Share Time也需要按定义解释：它是距离上次接受份额已经经过的时长字符串，不是那次份额的绝对时间戳。若要排列事件先后，还需要本次读取时间及其他对应日志。只看到一串类似时分秒的字符，就把它套进某个时区的钟点，会把持续时间错写成发生时间。
同一时段比较仍要保留判断边界
用虚构记录说明：同一统计周期内，两次读取的任务数从八增至十，接受份额数仍为十二。这只能说明两次读取之间任务计数增加、接受计数未变，不能仅凭这两项就断定硬件故障或网络中断。也应核实中间是否重启、是否切换矿池及计数周期是否一致，否则差值本身就可能没有可比性。
一份清楚的记录可以分列固件版本、矿池标识、读取时点、连接状态、任务数、份额类别与字段单位。本文只阅读公开文档和虚构数据，没有连接设备、修改矿池或执行诊断命令。需要查异常原因时，应从同一时段的具体响应和设备日志继续核对，不能把一个状态标签直接转成产量、付款或收益结论。