Prohashing Mining Pool Forums

This is a lot of useful information.

First, thanks for the offer of 0.1BTC, but we don't want to take money from anyone. If anything, we would pay the contributors here for their hard work in providing us with this data.

I'm also inclined to believe that work restarts aren't the cause of the problem, if only because we've spent so much attention on that area of the code. I did a lot of testing to make sure that work restarts were at the absolute minimum they could be, and it looks like paszokonik was able to verify that. But his tip about the change from Friday to today is interesting. It will take a lot of computing power to run that query, so we won't be able to get any results until tomorrow about that. I'll post that when I get more information.

The most useful information we could have here is how they determine what the "base hashrate" is. If you own a physical miner, there are two ways to determine its hashrate: what it reports from its chips on the screen, and the statistical distribution of the shares submitted. In this case, it's obvious that the "pool hashrate" is the statistical distribution of accepted shares. But how do they compute the base hashrate? There is no stratum method to query that data. Do they use some sort of custom miner software that sends what the miner reports to Nicehash's servers?

Another test for someone who is interested in running it: If you set "d=1024 c=litecoin", does that make any difference over "d=16384 c=litecoin"? Theoretically, it's possible that with a high difficulty, the 10% could simply be due to luck.

I believe they use some sort of custom stratum proxy, no special miner software is required to sell hashing power to nicehash.
With that arrangement I believe they would have access to obscene levels of detail about the ins and outs.

One note/comment/question, if you specify an r= and d= value then you are basically not doing restart or difficulty testing? So issues in that area would not apply?

That's right. Theoretically, if you used r=0 d=1024 c=litecoin, that should cause NiceHash to connect here and start mining litecoins as would occur on any other litecoin-only pool.

Since they are supposed to be equal but are not, I'm hoping that means there is a bug in our code, because if true we can significantly increase profitability by finding it.

One difference for them is they are constantly re-balancing load vs. demand.
You ask for 300MH and you might be using 3 miners one minute and 10 the next, 500MH one minute and 125MH the next.
Over time you get close to what you are asking for but, that is over hours not minutes. IMHO

Maybe a good test it to run 2 100MH orders at the same time, 1 @ PH with r=0 d=1024 c=litecoin and 1 @ a lite coin only pool, and see the diff.
Though it will not be a 1to1 comparison since each order will get different miners/hash but, over time the results may be telling.

My experiences are about the same as everyones' here.

One thing I didn't try was a fixed order. I noticed that the more miners were given/taken away from me on Nicehash, the less profitable I was here at Prohashing. I bet with a fixed order you'd probably see some better results since with those you are guaranteed your hash rate and not constantly gaining/losing miners.

@dman99 According to my tests price per GHs is irrelevant. Haven't tried fixed order, but put my order on top of standard orders to avoid GHs fluctuations and experienced delta=-15%. The fact is that after requesting more GHs the delta is decreasing for the transition period but as soon as GHs stabilizes at the new level the delta also stabilizes as bad as before or worse.

Same problem on miningrigrentals, no response to work restart. My rig is connected from there.

paszokonik,

Is there a way you could try obtaining a very minimum amount of hashpower and seeing what happens, like 1MH/s?

I wonder if the reason there is this problem is because they aggregate lots of miners. As hashrate goes up, more and more miners are brought in, increasing the odds that one of them could get stuck. If that's the case, a very tiny amount of hashrate should come out with exactly what was promised.

Minimum order is 100 MHs and there is no guarantee about the number of workers. This changes dynamically.
The number of workers is variable even with fixed order which guarantees hashrate.
Here is public link to order table
https://www.nicehash.com/?p=orders

As I told few posts earlier I can't see corelation between number of workers and hashpower drop

Any results of friday to monday database history comparison?

Unfortunately, the query returns what we expected: that the hashrate is what was reported.

However, I'm starting to think that this issue may be present with all miners, even non-Nicehash ones. The miners we own have never been able to get the hashrate they were promised, and kires always was dissatisfied with the hashrate of his miners. We never thought to connect our miners to another pool to troubleshoot that. Tonight, I'm going to try connecting our miners to another pool and then comparing the results.