Weekly pool and network statistics

[Lethos]

What sort of criteria does a pool have to fill to be included in your stats?
I've been mining at HHTT for a while and has grown quickly since then.
https://bitcointalk.org/index.php?topic=95378.0

[1715056631]

1715056631

[1715056631]

1715056631

[1715056631]

1715056631

[1715056631]

1715056631

[organofcorti]

What sort of criteria does a pool have to fill to be included in your stats?
I've been mining at HHTT for a while and has grown quickly since then.
https://bitcointalk.org/index.php?topic=95378.0

I would like to include HHTT - I love the fact its selling point is variable diff and it's hashrate jumped a lot recently.

Early on I just included all pools. I can't do that now. Every Sunday someone changes a webpage and I have to rewrite scripts to cope. Last weekend I discovered DeepBit had changed the stats table to the 13th position on the page, and Eclipse added a field to their json which I also had to account for. This is after I finally figured out the problem in each case.

So now I just ask for a csv blockhistory. If extra columns need to be added to for some reason my scripts can simply ignore the new data. If HHTT would like to be included, then I'd need the following columns as csv:

"blockheight"  |  "timestamp"  |  "shares"  |  "roundseconds" |  "difficulty"  |  "orphaned"  |  "blockhash"  

doublec did this for me and I know as long as the csv is available I'll never have to waste time on a Sunday trying to fix data for Bitparking!

[Lethos]

I do like mining at diff 32+ and enjoying a really nice PPS rate, that is nice.

With no standard model for stats, being agreed upon by all the pools, I can understand the headache.
I'm sure if frieduck is interested (I poked his thread), he'll let you know.

[organofcorti]

Cheers, Lethos!

[fireduck]

I would like to include HHTT - I love the fact its selling point is variable diff and it's hashrate jumped a lot recently.

Early on I just included all pools. I can't do that now. Every Sunday someone changes a webpage and I have to rewrite scripts to cope. Last weekend I discovered DeepBit had changed the stats table to the 13th position on the page, and Eclipse added a field to their json which I also had to account for. This is after I finally figured out the problem in each case.

So now I just ask for a csv blockhistory. If extra columns need to be added to for some reason my scripts can simply ignore the new data. If HHTT would like to be included, then I'd need the following columns as csv:

"blockheight"  |  "timestamp"  |  "shares"  |  "roundseconds" |  "difficulty"  |  "orphaned"  |  "blockhash"  

doublec did this for me and I know as long as the csv is available I'll never have to waste time on a Sunday trying to fix data for Bitparking!

I'm working on it.  Any particular format for the timestamp?  For the difficulty, do you want the network difficulty when it was solved or the difficulty that block would meet?

[organofcorti]

I would like to include HHTT - I love the fact its selling point is variable diff and it's hashrate jumped a lot recently.

Early on I just included all pools. I can't do that now. Every Sunday someone changes a webpage and I have to rewrite scripts to cope. Last weekend I discovered DeepBit had changed the stats table to the 13th position on the page, and Eclipse added a field to their json which I also had to account for. This is after I finally figured out the problem in each case.

So now I just ask for a csv blockhistory. If extra columns need to be added to for some reason my scripts can simply ignore the new data. If HHTT would like to be included, then I'd need the following columns as csv:

"blockheight"  |  "timestamp"  |  "shares"  |  "roundseconds" |  "difficulty"  |  "orphaned"  |  "blockhash"  

doublec did this for me and I know as long as the csv is available I'll never have to waste time on a Sunday trying to fix data for Bitparking!

I'm working on it.  Any particular format for the timestamp?  For the difficulty, do you want the network difficulty when it was solved or the difficulty that block would meet?

Great news - thanks fireduck!

For the time stamp unixtime in seconds. For the difficulty, the network difficulty when the block was solved. Also, the "shares" should be the equivalent number of diff1 shares per round.

[organofcorti]

23rd September weekly pool statistics

The biggest changes made this week involved ensuring that no previously recorded rounds were recorded a second time, and making the yellow colour in the hashrate history chart easier to see. Both suggestions were courtesy of Dr. Haribo, pool op of "Bitminter".

BTCGuild lost a little percentage of the network hashrate and 50BTC gained some, bringing them quite close to DeepBit's hashrate. DeepBit now has a challenger for the top spot for the first time in more than a year.

Most other pools this week lost or maintained their percentage of the network hashrate.

You can view all charts at http://organofcorti.blogspot.com

[eleuthria]

Sorry I borked your BTC Guild stats this week ;p  BTC Guild's stratum beta pool wasn't linked to the pool speed reporting, but the blocks were.  Luck was actually terrible, and speed was up, rather than down .  Luckily beta is over and now it all gets lumped together.

[organofcorti]

Sorry I borked your BTC Guild stats this week ;p  BTC Guild's stratum beta pool wasn't linked to the pool speed reporting, but the blocks were.  Luck was actually terrible, and speed was up, rather than down .  Luckily beta is over and now it all gets lumped together.

Thought that looked odd so I reviewed the script and found an error in my difficulty calculation which resulted in the current diff being applied to the week. Fixed that bug but I wouldn't have looked for it if the luck hadn't looked unusually good.

[Inaba]

I'm not sure Eclipse looks right, either.  Are my stats not coming out to you correctly?  How are you calculating the hashrate exactly?

[organofcorti]

I'm not sure Eclipse looks right, either.  Are my stats not coming out to you correctly?  How are you calculating the hashrate exactly?

I'll look at the script and see what's happening. I sum the total shares and divide them by the total round duration. I've had to put in sanity checks to remove rounds of 0 shares - this could be a source of error.

[wknight]

HHTT not added yet?

[organofcorti]

Unfortunately I haven't heard back from the pool op about a data api. I'll add it as soon as I can get the relevant data though.

[Inaba]

I think the API may not be correctly reporting Vardiff shares, I will take a look now.

[Inaba]

Ok... the API should report the correct amount of DIFF1 shares now.  Is the metric of how many actual shares are submitted vs the DIFF1 equivalent useful for anything?

[organofcorti]

The Mining pools list and the table in this thread have both been correct using equivalent D1 shares from EclipseMC. I'll be correcting the other charts as I have time.

I think it might be useful to have a history of the average difficulty of shares submitted. This could be tracked using shares submitted and equivalent D1 shares submitted. What do other pool ops think?

[Inaba]

I can add that to the API if you want, sure.

[eleuthria]

The Mining pools list and the table in this thread have both been correct using equivalent D1 shares from EclipseMC. I'll be correcting the other charts as I have time.

I think it might be useful to have a history of the average difficulty of shares submitted. This could be tracked using shares submitted and equivalent D1 shares submitted. What do other pool ops think?

My particular setup (being PPS only) doesn't keep track of the difficulty of shares submitted (when logging to the database).  When running at higher difficulty, I simply record high-diff submissions as multiple 1-diff shares.

[organofcorti]

The Mining pools list and the table in this thread have both been correct using equivalent D1 shares from EclipseMC. I'll be correcting the other charts as I have time.

I think it might be useful to have a history of the average difficulty of shares submitted. This could be tracked using shares submitted and equivalent D1 shares submitted. What do other pool ops think?

My particular setup (being PPS only) doesn't keep track of the difficulty of shares submitted (when logging to the database).  When running at higher difficulty, I simply record high-diff submissions as multiple 1-diff shares.

Do you keep a record of total shares submitted before converting to D1 equivalent? If so I could calculate the average D. If not, there are just some stats that are not available for some pools - there's no standardised reporting of block history just yet.

Edit: But would tracking average D be interesting, in any case?

[Inaba]

I think it would be interesting as all get-out over time.  It would show the average hashrate of users as an aggregate basically.