search

btccom / btcpool-ABANDONED

backend of pool.btc.com
https://pool.btc.com
MIT License
644 stars 408 forks source link

share_reject出现一个巨大的值 #370

Closed rocqina closed 5 years ago

rocqina commented 5 years ago

image stats_users_hour表

rocqina commented 5 years ago

image 这是stats_workers_hour表，某个矿工的拒绝率奇高

YihaoPeng commented 5 years ago

我们的sserver目前有一个问题，如果矿机一直提交拒绝share，可以无限推高难度。目前我们在statshttpd和slparser里面进行了抑制： https://github.com/btccom/btcpool/commit/0ab1780d347015f6f98cc310ccc850e41d066ab7 https://github.com/btccom/btcpool/commit/617990e810bb9b287977d90b2c3bb67cff87978d 你可以更新一下这两个模块然后重新解析一下sharelog

./slparser -c slparser.cfg -d 20190905

YihaoPeng commented 5 years ago

我们目前计划在sserver内实现相同的抑制逻辑，不过还没有做

rocqina commented 5 years ago

好的，感谢

rocqina commented 5 years ago

有个疑问，为什么无限推高难度，被拒绝share的提交还能计算如此高的难度出来，而如果只是提交低难度的share被拒绝，就会导致难度不断升高，那难度机制上一次改版不就是有问题的，机制就失效了

de1acr0ix commented 5 years ago

有个疑问，为什么无限推高难度，被拒绝share的提交还能计算如此高的难度出来，而如果只是提交低难度的share被拒绝，就会导致难度不断升高，那难度机制上一次改版不就是有问题的，机制就失效了

改版的主要原因是如果不将拒绝 share 的提交计入难度调整，而矿机又陷入某种特殊状态一直不能计算出正确的解，那么难度就会一直降低。然后对应的矿机可能会疯狂提交，sserver 的内存和负载都会增高。但是无限推高难度显然是考虑不周，实际上此时矿机的状态可能需要强制断开更好。