bonesoul / CoiniumServ

Next-gen crypto currency mining pool software
Other
788 stars 497 forks source link

MPOS Hashrate #587

Open Marty19 opened 9 years ago

Marty19 commented 9 years ago

I have just started using CoiniumServ in MPOS mode and have noticed the hashrates are higher than I normally get. Could this be because stratum-mining writes worker difficulty to the shares database instead of the share difficulty as written by Coinium?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/5329169-mpos-hashrate?utm_campaign=plugin&utm_content=tracker%2F401667&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F401667&utm_medium=issues&utm_source=github).
bonesoul commented 9 years ago

Could be related, will check.

artbatista commented 9 years ago

I think this may be the hashrate problem solution.

See the latest comment on #332

I was looking at the database and Coinium is writing the individual share diff numbers to the database instead of the job diff number.

Is that how it should be?

I mean, individual result diff numbers are wildly variable and that seems to correlate with the highly variable and inflated diff calculated by both MPOS and Coinium's own front end.

Marty19 commented 9 years ago

Any chance of a quick resolution to this as miners are being confused by the hashrates? If its going to be a while then I'll swap back to stratum-mining until its sorted.

Cheers.

Marty19 commented 9 years ago

I have tweaked my Shares.cs and hashrates are now ok:

// calculate the share difficulty //Difficulty = ((double)new BigRational(AlgorithmManager.Diff1, HeaderValue)) * Job.HashAlgorithm.Multiplier; Difficulty = miner.Difficulty;

bonesoul commented 9 years ago

Which algorithm you were using? x11 / x13 etc?

Caberhagen commented 9 years ago

i've tried your fix, but on scryt it shows 10 times slower as it is.

artbatista commented 9 years ago

This seems to have worked for me on a scrypt coin (orbitcoin)

Will try different coins and algos in a while.

Caberhagen commented 9 years ago

in my debug.log the share come in not with right diff. after tihs fix. [Debug] [ShareManager] [Feathercoin] Share accepted at 2409.41/2409.412 by miner [Debug] [ShareManager] [Einsteinium] Share accepted at 1291.96/1291.963 by miner [Debug] [ShareManager] [Einsteinium] Share accepted at 1291.96/1291.963 by miner

in original coinium: [Debug] [ShareManager] [Litecoin] Share accepted at 1525.08/128 by miner [Debug] [ShareManager] [Feathercoin] Share accepted at 174.25/128 by miner [Debug] [ShareManager] [Feathercoin] Share accepted at 480.63/128 by miner [Debug] [ShareManager] [Feathercoin] Share accepted at 190.67/128 by miner

by you the same? so i am back to original.

artbatista commented 9 years ago

I see the same thing in my logs, however, I am getting the right hashrate now in MPOS for both scrypt (Orbitcoin, Lottocoin) and sha256 (bitcoin), or at least pretty close.

I have nominally 1600 KH on scrypt and 90 GH on bitcoin, and it's pretty close now.

artbatista commented 9 years ago

On the other hand, by making that code change you break the Coinium built in web server hash rate display, always at zero now.

Not that I matters, since I am using MPOS for now.

Marty19 commented 9 years ago

My server hashrate was 0 before the change but not worried as using MPOS.

My workaround was just a temp solution until Dev does a permanent fix, it was not meant to be a general code change, just saved me having to back out coinium :)

CyberDexter commented 9 years ago

Looks like this is still an issue :(

crusher72 commented 7 years ago

Can we get a permanent dev fix? :)