ProgPoW: Progress Update #1
ProgPoW Testnet
The testnet is almost up to block 250,000 and has a number of miners, pools, and clients testing. You can observe the status of the network here: http://boot.gangnam.ethdevops.io/
Details for connecting to the testnet are here: https://gist.github.com/holiman/c8944c8be26f798e391822b9a70cb91c#gistcomment-2783941
AMD OpenCL Compiler Bug
We have discovered what appears to be a bug in the AMD OpenCL compiler. For certain periods AMD GPUs when running on the OpenCL platform will always produce incorrect results. The same kernel produces correct results when run on AMD’s ROCm platform or Nvidia’s OpenCL or CUDA platforms.
Members of the ethminer team and us are actively engaged with AMD engineers to understand the failure and how to work around it. Turning off the optimizer (setting -cl-opt-disable) produces functionally correct kernels, but causes a >10x slowdown.
For more details see this bug report: AMD GPU occasionally looses its mind for a single PROGPOW interval.
Tweaking Parameters
We suggest that 3 parameters be changed from how they are currently set. If the community agrees with these changes they will need to be coordinated onto the testnet.
PROGPOW_PERIOD: 50 -> 10
PROGPOW_CNT_CACHE: 12 -> 11
PROGPOW_CNT_MATH: 20 -> 18
Reducing PERIOD
The hashrate of every period will naturally be slightly different (+/- 5%) due to the different random sequences generated. Reducing the period from ~10 minutes to ~2 minutes prevents the overall difficulty from drifting significantly in response to an individual period. As an added bonus this makes FPGAs even more impractical.
Typically compiling the kernel takes <1 second, even on a relatively slow machine. In the case of a series of quick blocks and a system with an exceptionally slow CPU compiling for a few seconds every 10 blocks should not be a problem. This will especially be true once the planned ethminer optimization that compiles period N+1’s kernel while period N is executing is in place.
Reducing Compute
After testing on a wider variety of GPUs we’ve discovered the current parameters unintentionally causes some AMD GPUs to be compute limited instead of memory limited. Reducing the random cache and math counts by 10% increases the hashrate on those AMD GPUs. This has no effect on the hashrate of other AMD GPUs or any the Nvidia GPUs we tested.
This is the lowest the counts can be reduced while keeping the important property of (PROGPOW_DAG_LOADS(4) + PROGPOW_CNT_CACHE(11) + PROGPOW_CNT_MATH(18) > PROGPOW_REGS(32)). This property ensures that every mix[] destination gets written to.
