Read-only forum archive. PROHASHING has closed. Posting, registration, and account access are unavailable. Preserved from the April 3, 2026 server backup.
You can't run a PPS pool with a 1.4% safety margin and remain profitable for a long time. Such a pool could go bankrupt very easily due to simple bad luck.
It's also bad business sense. They need to get 3.5x our hashrate at 1.4% just to make the same profitability as we do, assuming we were only mining litecoins.
Unfortunately, I have yet to get around to working on this issue because we had another problem with the AsianInvestmentBonds yesterday, our orphan rate calculations were off, and there was that bitcoin payout bug. Fortunately, I think these things are behind us and I should be able to look more info this now.
Last night, Chris spent a long time trying to reproduce the issue in the development environment, but failed to do so. Having been frustrated, he started a production backup and went on to other tasks. But he quickly discovered that, when the production backup caused the database to get behind temporarily, hashrate decreased.
Today, he's going to set up a simulation in the development environment to try to get the database behind and see if he can reproduce the problem there. If the mining server is indeed slowing down on the database, then we should be able to investigate the issue easily.
Thanks to the users who pointed this out. We're making progress now!
Some details of an order running with a fixed difficulty of 8192 (apologies for the layout):
Code:
From 2015-10-29 15:19:42 2015-10-29 15:12:42
To 2015-10-29 15:24:42 2015-10-29 15:24:42
Speed at pool 0.4009 GH/s 0.5750 GH/s
Speed paying 0.4290 GH/s 0.6586 GH/s
Delta -0.0281 GH/s (-6.56%) -0.0837 GH/s (-12.70%)
Rejected at pool 0.0000 GH/s (0.00%) 0.0000 GH/s (0.00%)
Extra rewards 0.0308 GH/s 0.0648 GH/s
Timed-out speed 0.0000 GH/s 0.0000 GH/s
Rejects at pool
Share above target 0.0000 GH/s 0.0000 GH/s
Stale share 0.0000 GH/s 0.0000 GH/s
Duplicate share 0.0000 GH/s 0.0000 GH/s
Invalid nTime 0.0000 GH/s 0.0000 GH/s
Invalid worker 0.0000 GH/s 0.0000 GH/s
Other 0.0000 GH/s 0.0000 GH/s
As you can see most of the "loss" is due to the extra rewards, defined as "Extra speed this order paid to NiceHash miners as virtual shares due to fast job switching or disconnects.".
Just setting r=0.0 and omitting the fixed difficulty results in the order being disconnected due to too low difficulty, however using r=0.0 d=8192 results in a running order, but first stats (only a couple of minutes) don't look to promising:
Speed at pool 0.1432 GH/s 0.0443 GH/s
Speed paying 0.1762 GH/s 0.0496 GH/s
Delta -0.0331 GH/s (-18.76%) -0.0053 GH/s (-10.68%)
Thanks for this. I just discovered a major issue that could cause work restarts to be sent to too many miners. I'm going to start testing it to see if this new code works. There was a variable that had been misspelled.
I'm going to change the pool's default difficulty from 1024 to 2048, because it seems that Nicehash thinks 1024 is too low now. Their difficulty settings seem to change constantly and are a huge problem.