在官方CTO的帮助下,我将一台奖励明显偏低的服务器报告解析如下
首先,奖励偏低的node,一定有如下错误
在排查前最好检查自己一天的的node日志出现的频率是否过高,日志生成参考:链接
2024-03-12T19:18:42.970333Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3417177 to_next_slot=3417178
2024-03-12T23:03:53.841201Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3430883 to_next_slot=3430884
2024-03-12T23:14:28.649307Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3431527 to_next_slot=3431528
2024-03-12T23:44:24.767989Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3433349 to_next_slot=3433350
2024-03-12T23:54:49.690373Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3433983 to_next_slot=3433984
2024-03-13T00:34:31.930028Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3436383 to_next_slot=3436384
2024-03-13T00:49:24.102653Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3437288 to_next_slot=3437289
2024-03-13T01:51:29.358894Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3441067 to_next_slot=3441068
2024-03-13T02:51:59.943461Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3444750 to_next_slot=3444751
2024-03-13T03:01:51.410814Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3445350 to_next_slot=3445351
2024-03-13T03:07:26.560577Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3445690 to_next_slot=3445691
2024-03-13T03:43:37.177761Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3447892 to_next_slot=3447893
2024-03-13T03:55:43.723378Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3448629 to_next_slot=3448630
2024-03-13T04:08:55.304595Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3449432 to_next_slot=3449433
2024-03-13T04:29:14.733894Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3450669 to_next_slot=3450670
2024-03-13T05:30:54.331070Z WARN Consensus: sc_proof_of_time::source: Proof of time chain was extended from block import from_next_slot=3454422 to_next_slot=3454423
可以看到，它始终是 1 个时隙的差异，并且不会一直发生，只是偶尔发生。
协议的工作方式如下：
- 槽位到达
- 农民进行审核，如果有解决方案，候选人将尝试生成证明
- 解决方案准备就绪，节点等待未来的槽（+4 来自为其生成解决方案的槽）
- 一旦未来的时间证明到来，区块就会被创建、签名并发送到网络
在这里用通俗易懂的话说一下奖励低的原因
node因为墙的原因或者其他不知名原因,分叉了,虽然这个分叉后面会被纠正,但是你的farm如果挖到分叉奖励上面去了,他不会被sub主链的共识所认可,自然也就丢失奖励了
farm和node在一起的
farm和node在同一台机器上的,需要检查一下给node的CPU分配,最少保证node得有几个固定的核心使用,如果farm把CPU占满了,node也会出问题,node不适合运行在频率太低的CPU上面
解决方案
目前运行更快的计时器,可以极大概率减少的node分叉的可能性,跟CPU主频有关系,CPU频率低于5.5可能不会有帮助,任然会分叉
不是分叉导致的node
除了分叉导致的丢奖励,其他的比如你本身网络是移动这种丢包率极高的,包都丢了,node甚至bps一天有几个小时都是0bps,同步不正常等等,这种情况不适用使用计时器
其他方案
境外节点并不适合,如果线路过差丢包率一样导致你的farm跟node连接不正常,甚至farm中途掉线,专线的价格也太昂贵,其价格还不如搞一台酷睿服务器托管到离farm最近的电信专线机房
计时器运行方法:
在node添加如下参数即可
--timekeeper \
--timekeeper-cpu-cores 5-6 \
其中第一行代表开启计时器
其中第二行代表指定核心,我这里指定的是使用5核心或者6核心,计时器只会使用一个核心,不建议使用CPU的第一个也就是0核心,因为系统调度一般都是使用,建议预留空闲核心