From the research I have done to understand the minimum difficulty it boils down to a balance between server/client bandwidth limitations and time to put at risk.
The pool which you connect to distributes work for miners to solve. The more difficult each "package" of work sent to you, the longer you will take to find a solution and reply back to the pool with this solution, named share.
As explained in this Post you will on average be rewarded the same solving problems of 10k difficulty at 10 seconds per share, as solving problems of 1k difficulty at 1 second per share.
On the Antminer s9 Miner Status Tab the stats I believe, it may not be correct, I have deciphered are the following:
- Elapsed - Time passed since online
- Utility - Number of Accepted shares per minute
- WU (Worker Utility) - Total Difficulty Submitted (Accepted + Rejected) per minute
- Accepted - Number of Shares Accepted by the pool
- DiffA# - Total difficulty of accepted shares
- DiffR# - Total difficulty of rejected shares
- Rejected - Number of submited Shares rejected by pool
- either good hashes of bad work or bad hashes of good work
- Discarded - Discarded Work that has not been worked on. According to a developer of cgminer, meaningless.
- Stale - Number Shares that were sent after a block was already solved.
- LSDiff - Last Accepted Share Difficulty
- LSTime - Time since Last Accepted Share
You can now check to see which difficulty the pool has automatically assigned to you in the Miner Status Page.
So back to the initial question / response of the "optimum" difficulty is a balance of how many packages back and forth the network connection between the server and client is comfortable with handling and time to put at risk.
- If the difficulty is very low, the network and server will be flooded with shares of solutions you have found and may reject some as it can not handle so many packets per second.
- So some work you have done in solving problems has gone to waste as these solutions have been rejected.
- you are spending some time waiting for recieving new work from the server and also spending time sending the solutions to the server that could have been used for finding solutions.
- If the difficulty is very high, you may be working on solving a problem which no longer needs solving and so you will get no credit for the work. As far as I understand, these submited shares would be marked as Stale or Perhaps Rejected.
Currently a new bitcoin block is found every 10 minutes or so, sometimes under a minute sometimes more than 15 minutes. So, if you set the difficulty to a value which allows you to generate 1 share per minute --> Utility = 1.0 then when blocks get found under 1 minute, you have lost that minute because the pool will generate new work with the latest new block to mine and the work you were working on that you couldn't complete in time would be useless. But if the next block were found in 1 minute and 2 seconds, you would have only lost 2 seconds theoretically cause you would have probably managed to submit a share.
So, ultimately you don't want to overload the pool but you want to make sure that you risk as few shares as possible.
Your Risk would be approximately = "1 / ( Average Accepted Shares per minute * Average Minutes per Block )"
From my experience hashing at 13.5 TH/s at a difficulty of 13.3K will produce approximately 1 share every 4.5 seconds or so --> Utility = 13.5 --> "WU = 13.5*13312 = 179712" , Risk of approx 0.74%
To optimize your difficulty you should look to maximize the WU : Worker Utility Value. Theoretical Max WU you can achieve is approximately 1 per 71.6 MH/s, so a 13.5 TH/s machine can not achieve a better than a WU of 197706.
I currently have a system configured at 10k Difficulty with a Utility of 18.0 obtaining a Worker Utility of 190k, mining at KanoPool. I have aimed for 18 shares per minute as that is what is recommended by the pool.
Just though I may contribute my research on the subject incase it helps :)
Disclaimer: This response are just compiled bits from forum replies, github code and other bits here and there I have found and my own understanding of how it apparently works. This is not necessarily 100% correct information.
Some of sources:
- CGMiner Github Repo
- BFGMiner Github Repository
- BFGminer Forum talk