Prohashing Mining Pool Forums

alim wrote:I switched the coin and the merged mining is working.

Again the miner has said it has found a block, but is is not in the list, even as an orphan.

Which coin were you mining when you saw the number of blocks be mismatched with the number of found blocks in the miner?

Steve Sokolowski wrote:

jeffms2003 wrote:Well after a few hours of running, we're back down to my averages of 10% below what I should be showing. For example my miners are running at 55 TH/s for SHA, but the 2 hour measurement on prohashing is 50.3, which is my 10% variance I've consistently been seeing. Similar % breaks on scrypt and equihash. I'll probably run for a week on prohashing and then test a BTC/BCH pool that mines whichever is higher profit, litecoinpool.org for scrypt, and a pool that just mines zcash and compare unless you guys figure out if there is an issue. It'll be interesting to see the results.

It's possible that, because the hashrates are calculated over the last two hours, the displayed hashrates could be lower for one period of time, and then higher during other periods of time. The mining server doesn't have access to the actual hashrate of the miner; it can only extrapolate it from share data.

Have you ever seen a period when hashrate was higher than what the miner displayed?

I know that is a possibility, but I can't see a 24 hour calculated hash rate to determine if that is what is happening. More times than not it is below what my machines show, but it has gone above. I have never seen it above by 10%, which is why it seems as if it would be hard to bring the averages to be in line with what actual rates are. I'm assuuming you can look at the 24 hour history for my account on the back end. It would actually be a nice data point to have added to the data on the site.

My 2 hour rates look in line with expectations again right now, so that is good. Earnings since the reset last night are up a good bit too, so either the pool had a good night of mining or the changes I made last night helped out some. Not sure how to tell.

jeffms2003 wrote:

Steve Sokolowski wrote:

jeffms2003 wrote:Well after a few hours of running, we're back down to my averages of 10% below what I should be showing. For example my miners are running at 55 TH/s for SHA, but the 2 hour measurement on prohashing is 50.3, which is my 10% variance I've consistently been seeing. Similar % breaks on scrypt and equihash. I'll probably run for a week on prohashing and then test a BTC/BCH pool that mines whichever is higher profit, litecoinpool.org for scrypt, and a pool that just mines zcash and compare unless you guys figure out if there is an issue. It'll be interesting to see the results.

It's possible that, because the hashrates are calculated over the last two hours, the displayed hashrates could be lower for one period of time, and then higher during other periods of time. The mining server doesn't have access to the actual hashrate of the miner; it can only extrapolate it from share data.

Have you ever seen a period when hashrate was higher than what the miner displayed?

I know that is a possibility, but I can't see a 24 hour calculated hash rate to determine if that is what is happening. More times than not it is below what my machines show, but it has gone above. I have never seen it above by 10%, which is why it seems as if it would be hard to bring the averages to be in line with what actual rates are. I'm assuuming you can look at the 24 hour history for my account on the back end. It would actually be a nice data point to have added to the data on the site.

The best way to perform the comparison is to look at the "hashrate history" chart. On average, does the chart's line hover around the actual hashrate of the miners?

I wanted to make a post here pointing out that I discovered that the "found blocks" issue might be caused by these miners not understanding the concept of a "rejected block." My suspicion is that they were designed to mine very difficult coins, where the possibility that another miner on the same pool would find the block 100ms before you did is so low that it makes no sense to implement code to handle it. But here, we mine easier coins, and that situation is common.

Today, I'm going to add a new table to log rejected blocks to see how many there actually are. We'll try to release it tonight or tomorrow. Then, by the 5th or 6th, we should have enough data to draw a conclusion on this. If I'm correct, then the solution is to add a new display to the user interface showing the user how many of his or her blocks were rejected.

Steve Sokolowski wrote:

jeffms2003 wrote:

Steve Sokolowski wrote:
It's possible that, because the hashrates are calculated over the last two hours, the displayed hashrates could be lower for one period of time, and then higher during other periods of time. The mining server doesn't have access to the actual hashrate of the miner; it can only extrapolate it from share data.

Have you ever seen a period when hashrate was higher than what the miner displayed?

I know that is a possibility, but I can't see a 24 hour calculated hash rate to determine if that is what is happening. More times than not it is below what my machines show, but it has gone above. I have never seen it above by 10%, which is why it seems as if it would be hard to bring the averages to be in line with what actual rates are. I'm assuuming you can look at the 24 hour history for my account on the back end. It would actually be a nice data point to have added to the data on the site.

The best way to perform the comparison is to look at the "hashrate history" chart. On average, does the chart's line hover around the actual hashrate of the miners?

My guess as to where the regression line goes is as good as it gets for now, but may not be the most accurate.

Steve Sokolowski wrote:

jeffms2003 wrote:Have you ever seen a period when hashrate was higher than what the miner displayed?

Steve, I've reported this before to you... but it is not like it is an average. It generally stays high until it finds a block/gets a rejected share, then drops significantly. Sometimes the rate pops back up but most of time it doesn't.

Steve, what I have observed in one of the L2+ miners I have shows that the port 3333 DEAD connection and is connected on the proxy port 443, although this miner is next to the other that shows LIVE connection to the same port. Both miners are in the same location, as I said one next to the other, on the same network, router and internet connection.
Any Ideas?

jeffms2003 wrote:

Steve Sokolowski wrote:

jeffms2003 wrote:
I know that is a possibility, but I can't see a 24 hour calculated hash rate to determine if that is what is happening. More times than not it is below what my machines show, but it has gone above. I have never seen it above by 10%, which is why it seems as if it would be hard to bring the averages to be in line with what actual rates are. I'm assuuming you can look at the 24 hour history for my account on the back end. It would actually be a nice data point to have added to the data on the site.

The best way to perform the comparison is to look at the "hashrate history" chart. On average, does the chart's line hover around the actual hashrate of the miners?

My guess as to where the regression line goes is as good as it gets for now, but may not be the most accurate.

I'm not clear what "is as good as it gets" means. I was asking whether the average hashrate from the chart matches the hashrate your miners display in their consoles. Is that the case?

I'm not clear what my average hash rate is from eyeballing it on a chart without having data points is what I'm saying. I can look at a chart with a line drawn on it all day and guess, but I don't know. Just from eyeballing they still look low.