Open mutatrum opened 2 months ago
I'm adding support for client.reconnect
and see if resetting send_uid
on a socket restart fixes this.
In the file component/stratum/stratum_api.c file , it does not look like the “STRATUM_V1_receive_jsonrpc_line” and “STRATUM_V1_submit_share” functions will properly detect an orderly socket close by the server. The recv call would return ‘0’ in this case and the check against -1 would miss the event, and loop forever in the read. The writes don’t check for ECONNRESET either, so they will also fail to recognize the error.
Depending on the compiler optimization and ESP32 behavior , it may also be necessary to declare GLOBAL_STATE->sock as volatile to ensure that it is pulled from the heap and not cached register values.
According to lwIP recv() docs, the API is not like POSIX, and rather than return -1, it returns the actual errcode.
After replacing an Half-Defective-Chinese-Fan (The Fan-Sound has Changed and the Airflow was massively reduced) with an Noctua-Fan (NF-A4x20) the Error:
stratum_api: Error: recv
stratum_api: Restarting System because of Error: recv
is gone and the Bitaxe is running like a charm again (many hours not just minutes).
I assume some interference is causing the bitaxe to restart. What do you think is it possible that the Bitaxe restarts caused by electric or/and magnetic interference?
"version": "v2.1.8", "boardVersion": "204",
"temp": 48 (Half-Defective-Chinese-Fan)
"temp": 58 (Noctua-Fan)
When the wifi haa a timeout
wifi:bcn_timeout,ap_probe_send_start
, it tries to restart the socket and stratum connection, but some bits are left in a wrong state resulting in the device hashing but almost no shares accepted. There are several issues hiding that prevent a proper reconnection.It starts with:
Some things that caught my eye:
mining.notify
andversion-rolling
responses are unhandled.mining.submit
messages, even though the socket is not alive.rx
in this log seems like a continuation of the ids from before. It looks like this is relevant, although I'm not sure who is driving this sequence, is that the pool or the miner, or both?It looks like it reconnected correctly, and starts mining with the ckpool default 10000 difficulty. A while later, when a share has been found it's rejected with
Above target
:This looks like #212 and it might be a red herring. However, on the next
mining.submit
tx:The pool requests a
client.reconnect
, as I assume they see something out of sync as well. Not sure what, maybe because of the still increasing ids?And finally, a little while later it seems the parser is in a proper error state and requests a socker restart:
This dance will continue forever, restarting the socket every few minutes.
BitAxe 400, latest master 04c8b80.