to detect a totally non working fpga we only do that if the last
round had some valid nonces.
if we would count the errors the automatic megahertz adaption
would drop and never recover.
the ztex bitstreams gives back the latest checked nonce and
its hash7 value and two possible solutions.
every 250ms the latest nonce is checked and compared with hash7
to count hw errors and adapt the MHz value. one change is to
use the solutions even if the latest nonce is not correct. the
original java ztex code also does it this way.
since the second solution is often not correct we have alot
of hw errors. now we always check the second solution before
we submit it to the cgminer main code.
the java code also ignores all hw errors 500ms after a sendHash.
we now do the same. this can possibly yield in a higher MHz rate.
but the chance is so low nobody will ever notice in practice.
search the complete noncerange until the range to the end is more
work than at the last round. doing one more round would mean we
would have a overrun, which is a waste.
with actual ztex boards this means that a new getwork is needed
every 19 seconds in general and not every 10 seconds (without
rollntime).
- Adding fpga number to the ztex string representation
- Removing usb details from the ztex string representation
- First frequency set no longer reports a bogus old freq
Not yet using suspend and while we have fpga counting implemented it isn't being used yet, thus only the groundwork for quad board support is done, not actually working yet.