Looking for more information about reduced hashrate miners

[ryguy]

Steve, from what I'm seeing, the charts appear to show the correct hashrate for Scrypt.

However, people may be trying to compare the chart data and the 2 hr avg from the live worker status, which I'm not sure are matching up. I'll update once I can compare them.

UPDATE: Numbers appear to be matching up to expectations.

[Steve Sokolowski]

Steve, from what I'm seeing, the charts appear to show the correct hashrate for Scrypt.

However, people may be trying to compare the chart data and the 2 hr avg from the live worker status, which I'm not sure are matching up. I'll update once I can compare them.

UPDATE: Numbers appear to be matching up to expectations.

OK, that's great. Then, is it possible that the reason that everyone is confused is because they aren't paying attention during the times when the estimated hashrates are greater than the actual hashrates, and that the issue is solely a display error caused by estimation?

[ryguy]

I would say that's most likely the case. There are definite periods of time on the chart where the 15 min period is greater than the amount of hashrate I could possibly have sent to the pool, so it is most likely just an issue with displaying/estimation .

[djliss]

As mentioned before a 24 Hour Ave Hash rate value would be useful on each worker tab

[jeffms2003]

Well I've been checking my 2 hour average hash rates reported in the dashboard all day (frequently) and it has shown between 85 - 90 TH/s for SHA. I'm mining at about 95 TH/s according to my miners, so there isn't anything on the site that would indicate I'm getting the full credit for my hashing power. I know this is contradictory to what ryguy said earlier, but he also indicated in another thread he is using nice hash, which wouldn't be a real reliable measurement from my perspective.

[jeffms2003]

I guess this no longer concerns anyone.

[ZiGen]

In the past 2-3 weeks my miners' hashrate is NOT as usual ... All the time before that I was mining at around 2.5GH ...now it is sitting at 2.3x ...which is 95% or so ... My hashrate is very STABLE ...with very LOW fluctuations ... For me it is a problem ...and it is at the Prohashing end ...Please advice ...

[Steve Sokolowski]

I guess this no longer concerns anyone.

This is a big concern; however, this is an extremely complex problem that will require a significant amount of additional information to resolve.

We need to first complete the ZCash changes, and then release them along with the dependent stale block code. Once enough stale blocks have been recorded, we'll be able to examine the data to determine what could cause the issue.

We are still on target to begin reviewing this data around July 9 or 10, as indicated in a previous message.

[CSZiggy]

When my brother points his miner to this pool he never goes over 580 as a hashrate even at 100% efficiency. But on litecoinpool its over 610 for the 24-hour average.

Could this be reason my brother and I have very often seen higher payouts on litecoinpool.org It could very well be that PH does actually pay out the highest payout per hashrate. But with Litecoinpool.org seeing all of the hashrate being applied it just ends up paying out higher each day?


I guess I only ever thought about leaving coins on the table. Never thought to count the hashrate and make sure it was being credited equally and not being left on the table.

[Steve Sokolowski]

When my brother points his miner to this pool he never goes over 580 as a hashrate even at 100% efficiency. But on litecoinpool its over 610 for the 24-hour average.

Could this be reason my brother and I have very often seen higher payouts on litecoinpool.org It could very well be that PH does actually pay out the highest payout per hashrate. But with Litecoinpool.org seeing all of the hashrate being applied it just ends up paying out higher each day?


I guess I only ever thought about leaving coins on the table. Never thought to count the hashrate and make sure it was being credited equally and not being left on the table.

Part of this problem could be caused by work restarts that reduce hashrate because the miners require time to spin up to the next coin they are assigned. Litecoins have few work restarts because their block time is so long.

Last week, I modified the coin assignments so that we assigned a lower percentage of hashrate to the other coins, so that we don't get period of lots of blocks being found for those coins within a few seconds of each other.

However, the difference between 580 and 610 MH/s is less than the 12% advantage we had over straight LTC this week. The system automatically determines if it makes sense to assign miners to coins that would reduce their hashrate and only does so if the increase in profitability at the lower hashrate exceeds the reduced hashrate. While I'll continue to investigate this issue, if the reduction in hashrate is caused by work restarts, it isn't actually lowering profitability enough to cause other pools to be advantageous.

That said, I did find just now that we are not recording all stale shares to the database. I'm going to make some changes to record all stale shares. As with the stale blocks, this change will help us get a better idea of whether there are a large number of rejected shares due to some reason that we aren't aware of.