Re: BFGMiner 4.7.0: GBT+Strtm, RPC, Mac/Lnx/W64, Spondoolies SP10, Nicehash
We have never faced this in the many boards we tested in lab. I would suspect a weak solder joint somewhere, or some issue with this board which went undetected.
@Morblias: You could send this board for replacement. Please let me know if you do so and when so I can accelerate the process and also see what's wrong with this board.
However, if you have the possibility of testing this card on another computer, it would be very helpful, as the issue may come from the actual computer / driver that you're using.
Thanks,
Nasser
@Morblias: You could send this board for replacement. Please let me know if you do so and when so I can accelerate the process and also see what's wrong with this board.
However, if you have the possibility of testing this card on another computer, it would be very helpful, as the issue may come from the actual computer / driver that you're using.
Thanks,
Nasser
I tried it on my RPi (with minepeon) and ubuntu 14. Both came up with those same errors. Then I tried it on a windows 7 64 bit machine, and this happens, except it continues to hash after the errors. On the linux ones it would just stop hashing completely, but the windows one continues around 620gh/s. I found another USB cable and tried that also with no luck. Still happens on all of the computers. 620gh/s isn't too bad though, so I might just leave it on the windows machine.
The images you show are actually hashing at 680GH not 620GH (For some reason, the Job-Rate is shown less than Nonce-Rate in Bfgminer, you might want to confirm this with your pool).
Also when a unit mines and then stops, it still has job-results in it's internal buffer. Upon restart, bfgminer will see those results but won't recognize them (as it doesn't know source of those jobs),
hence you get a "Was not able to find work for result". It's basically information, and should not be considered a failure.
I have already talked to Luke, and we have discussed a recovery mechanism that can be implemented on the Host-side if a USB packet gets corrupted (for Windows). On our own, we don't see these issues in our lab, especially
on Linux (On windows you do get an error every once in a while, but never affects speed or cause failure).
EDIT: I will be shortly publishing a special built of Bfgminer (version 4.2) which was custom-built and doesn't have slowdown/failure issues on windows.
Please let me know if you had any questions.
Thanks,
Nasser