...
[Device 0] Average speed (5s): 8374.28 sol/s
[Device 1] Average speed (5s): 8435.19 sol/s
[Device 2] Average speed (5s): 8431 sol/s
[Device 3] Average speed (5s): 8510.09 sol/s
[Device 4] Average speed (5s): 8481.73 sol/s
...
Sorry, that snap was a bit too short
To do some debugging I need to know in which state the stratum connection was and what counters were running or were long expired at the time your connection stops working. So to get a complete picture of the situation I require the log from approx the moment where you got the last difficulty new job adjustment (but connection was working fine till then) until you decided to stop the miner because its not sending shares. That should be long enough so I can see which of my safety timers (that should prevent this) is not working.
The --max-connection-attempts will only work if you define a failover pool and then still the miner has to detect that the connection is broken. Usually it should detect this at some time and then reconnect, but somehow it does not do so. Therefore would be great having the longer log and the config. (But plz in private message - I guess this could be a loooooong post here else
)
What we can expect from 0.4?
0.08 more than 0.32?
Thats for sure ^^
I currently plan to do some changes in the work scheduling. I aim for making the stuff less dependent on the memory on the GPUs so the 4G cards should do same speed as the 8G (on AMD in particular), since this currently is not the case. Also I want to exclude the status message code into an external module. Currently there are only two large code fragments, one for mining and one for the connection. This will be connection, mining and logging then. Pulling out the stats code out of the mining section will allow me to do more fancy stuff with it, e.g. providing a JSON API for the miner, so you can grab statistics for external analysis.
One further point I have on my list - but do not know yet if that will be 0.4 or later is a re-design of my mining code itself. Currently AMDs are suffering from the code to eat vector registers when compiling like Candy preventing the AMD scheduler to do efficiently place work on the card and cover all latencies. The re-structuring there should also allow to introduce more switchable optimizations.
Yea, I think thats it
