The front-end of the mine77 pool is alive again (was stalled for 24 hours). Payouts have resumed as well. The pool itself was apparently running all the time, as previously suspected. Good thing is that hash power is now shared kind of 50/50 between mine77 and irdpool. I'd happily move some workers to the third pool (ird.uvac) as well once it allows fixed share diffculty setting. The other two pools have this feature, even though it is undocumented on their "getting started" pages.
Allow me to pick your brains a bit.
How exactly so you go about calculating the optimum fixed difficulty for your hash?
Thanks in advance.
If you are using Claymore, this is what you want to see.
You want that your worker submits shares every few seconds. This is only possible if the pool allocates you a proper share difficulty.
Many pools which use auto-diff
do not. They give you some ridiculous diff of say 100k, which means your worker will often not find and submit a single share before the round is over, which means you get ZERO rewards for that round.
A worker consisting of a single CPU and a worker consisting of 6 GPUs obviously need highly different diffs. When a pools is using a constant diff on a certain port, that diff fits basically nobody. It will be too high for the single CPU worker and much too low for the multiple GPU rig. Which means the single CPU worker will just heat the room by not finding a single share before a round is over, while the multiple GPU worker will bombard the pool server with shares multiple times every second putting an unnecessary load on the server.
This is why pools are using auto-diff. They have different start diffs on certain ports but then each new round after you connect they adjust the diff. What many of them however don't do, is to adjust it properly. They just increase it until max diff is reached, rendering the connected workers very inefficient with much too high diff.
Therefore a pools needs the option that a user can set a diff of his choice which works best for his rigs. Simply to overcome the badly implemented auto-diff.
Let's assume your worker has a total hashrate of 1000H/s. Try to set a diff of 3000 and see how frequently shares are found and submitted (the green lines saying "share found, share accepted"). If it is every few seconds, that's fine. If it takes longer, set a lower diff. If it is too frequent, set a higher diff. Once you have figured it out, use that diff forever for that particular algo.
However for coins where the block time is much shorter, say 15s, you want to have shares found and submitted much more frequently than 2-3s. Otherwise you will miss out all short rounds.
About the above screenshot: Claymore shows those yellow status lines with the temperatures every 30s. As you can see the diff I have configured is such that shares are found every 2-3s. Works fine for me. If you use a too high diff (manually set too high or the pool setting it for you) you will also notice that the hashrate shown in the pool is much lower than your actual hashrate (no, this isn't because Claymore is mining covertly with your rigs and such nonsense!). That's because your worker will produce many stale shares when the round is already over and he is still chewing on the old outdated work, wasting electricity for nothing. Therefore the right diff setting is essential for efficient mining.
EDIT: Here is what you don't want to see: