[~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More

[jjiimm_64]

On top of the everything you guys are discussing,  I have noticed that  I get up to 10% difference in accepted shares with the same hashrate


cardx  400Mh  get 1000 accepted shares
cardy  400Mh  gets 910 accepted shares


my point is that it is not just hash rate that counts.


cma:  I am way behind you guys in understanding all this!

For me, I get higher stales on my slower card, that's why I'm thinking along the lines that the latencies count for something. Not a direct 1 to 1 correlation since that would make a huge difference but just enough cases to cause a divergent in the expected blocks found per pool per GH/s vs reality.

After all, if every MHash is equal, why is there a consistent difference? It's been a 10% gap since day 1 and 3 days later, it's still 10%.

I would write a script to crawl through further blocks to get a better basis but without historical data on pool hash rate, it's not useful just to know which pool found what.

I would like to add that I have < .1% stales on all cards.  I still see more shares on some cards with the exact same hashrate.

[1713987061]

1713987061

[1713987061]

1713987061

[1713987061]

1713987061

[1713987061]

1713987061

[1713987061]

1713987061

[hugolp]

Eleuthria, the 24 hour luck indicator is going up but the last block awarded keeps stuck in the same block count. What is going on? Have we found a block but the count is stuck and not reseting? There is something wrong with the 24 hour luck indicator?

[freedenizen]

Eleuthria, the 24 hour luck indicator is going up but the last block awarded keeps stuck in the same block count. What is going on? Have we found a block but the count is stuck and not reseting? There is something wrong with the 24 hour luck indicator?

If you notice now it has gone down.  I without looking at it closely I would guess it is cause there was a long block that dropped off from the rolling 24 hour stats.  It doesn't factor in the luck involved in the current block, once that was solved the 24 hour luck percentage went down.

[hugolp]

Eleuthria, the 24 hour luck indicator is going up but the last block awarded keeps stuck in the same block count. What is going on? Have we found a block but the count is stuck and not reseting? There is something wrong with the 24 hour luck indicator?

If you notice now it has gone down.  I without looking at it closely I would guess it is cause there was a long block that dropped off from the rolling 24 hour stats.  It doesn't factor in the luck involved in the current block, once that was solved the 24 hour luck percentage went down.

Yes, I understand that, but the problem is that the luck was at 9'X and without solving any block it went to 10'X. Thats what cought my attention.

If there is no block solved how is the luck going up?

[freedenizen]

Eleuthria, the 24 hour luck indicator is going up but the last block awarded keeps stuck in the same block count. What is going on? Have we found a block but the count is stuck and not reseting? There is something wrong with the 24 hour luck indicator?

If you notice now it has gone down.  I without looking at it closely I would guess it is cause there was a long block that dropped off from the rolling 24 hour stats.  It doesn't factor in the luck involved in the current block, once that was solved the 24 hour luck percentage went down.

Yes, I understand that, but the problem is that the luck was at 9'X and without solving any block it went to 10'X. Thats what cought my attention.

If there is no block solved how is the luck going up?

because maybe 23 hours 40 minutes ago a 2 hour block was solved, then 20 minutes go by and that block is no longer included in the calculation, so the avg goes up.  It is a rolling average.

[hugolp]

because maybe 23 hours 40 minutes ago a 2 hour block was solved, then 20 minutes go by and that block is no longer included in the calculation, so the avg goes up.  It is a rolling average.

I guess this is posible depending on how the 24h luck is calculated.

[kjj]

1) You are double counting.  There is no measurement of hashing speed, just an estimate.  Stale shares (the end result of latency) are already not factored into the speed estimates.

I don't see the relevance here. It's not like I'm scoring the pools based on their estimated hash rate and deducting points for stales.
If anything, stales are just an indication of what I mean, just that I'm talking about a particular stale -> the winning share that became stale/invalid.

2) Your argument is circular.  You have no knowledge about the distribution of hashing rates within the pools, but you assume that bigger pools have higher average speeds, and then you count that assumption as a confirmation.

Claiming every MHash is equal is also making assumptions, assumptions about each individual miner's network speed, each pool's network speed being equal. When working with large enough numbers, things tend to follow a similar distribution so usually assumptions are made. As long as the assumptions are reasonable and applied equally, then it's a valid basis until proven wrong.

Since this is a hypothesis, I wouldn't be surprised to be wrong in either the hypothesis or assumptions leading to it but you've got to at least put some data on the table to convince me otherwise you know

You are the one making the claim.  The burden of proof is on you.  I'm just poking holes in it, I have to prove nothing.

Let me try it another way.  You are saying that 10 miners doing 500 Mhash/sec each are better than 100 miners doing 50 Mhash/sec each.  As evidence in support of your hypothesis, you say that the big pools are getting more blocks than you would expect based purely on their (estimated) fraction of the (estimated) global hashing power.

The problem is that you don't have any idea on the composition of the miners inside the pools.  Let me give you an example.  BTC Guild is reporting about 2.3 THash/sec now, but it provides no data on the number or speed of the miners that make that number.  Could be 9000 miners turning in ~260 Mhash/sec each, or it could be 15,000 miners doing ~150 Mhash/sec each.  Could be anything, really.

So, you aren't actually providing any evidence to support your claim.  Unless you have some reason to believe that the distribution of miners in the larger pools is unusual in some way, the whole topic of pools is an unrelated distraction.

[eleuthria]

because maybe 23 hours 40 minutes ago a 2 hour block was solved, then 20 minutes go by and that block is no longer included in the calculation, so the avg goes up.  It is a rolling average.

I guess this is posible depending on how the 24h luck is calculated.

24H luck is a rolling window based on the SOLVED BLOCK END TIMES.  IE:  When a 6.8m share block gets knocked off the 24h list, the luck will shoot up because the average shares per block in the last 24 hours has just decreased significantly.

[Dargo]

I don't see why it's going to matter. Suppose you have one individual with a 40 Ghps cluster (say 100 5870s) mining at pool x. At pool y, you have 100 individuals minining at 400 Mhps (1 5870 each). Either way, each 5870 is an individual worker, and will be communicating with the pool individually. Either way, the pool is communicating with 100 5870s, and the only difference is that at pool x all 100 are tied to the same account while at pool y there are 100 accounts, but I don't see why this would make any difference. Am I overlooking/not understanding something?

It still shouldn't matter. If there was one account with an uber video card at 4 Gh/s and another account with 4000 celeron cpu miners at 1 Mh/s, assuming the pool can push work to all of them in the same amount of time (honestly probably not realistic), they should each have an equal shot of finding a block. Shares don't really matter, it is the hashing the matters. Shares are just when you happen to solve a block of difficulty 1.

Saying something like 'well assume that the block will be found on share 6' isn't really a good argument, because we can never assume something like that.

That may be right - I was just offering another reason why it shouldn't matter and the point was that people with a lot of hashing power are getting it via a bunch of individual cards that by themselves don't really have much more hashing power compared to people who just have one or two cards, even though those with just one or two cards will be hashing at a much lower rate overall.

[epdp14]

I hereby accuse E of adding fake blocks into the pool to artificially increase the luck... especially now that we are at nearly 10% good luck.

[jjiimm_64]

I hereby accuse E of adding fake blocks into the pool to artificially increase the luck... especially now that we are at nearly 10% good luck.

I concur..  E, what do you have to say for yourself?

[farfiman]

I hereby accuse E of adding fake blocks into the pool to artificially increase the luck... especially now that we are at nearly 10% good luck.

I concur..  E, what do you have to say for yourself?

He still has to insert a few more to make up for the -11% in the difficulty

[eleuthria]

Don't worry, I'm working some magic on the blockchain.  You guys are going to like the next hour of reveals.  I'll give you a hint:  BTC Guild has done the last 4 blocks on the network in a row.

[jjiimm_64]

Don't worry, I'm working some magic on the blockchain.  You guys are going to like the next hour of reveals.  I'll give you a hint:  BTC Guild has done the last 4 blocks on the network in a row.

Nice!  let the hoppers try and come into the forum and analyze your personal comments for block starts

edit:
E:  Like to request this again..  since you have had such a relaxing two weeks..  Please add sortable columns on the worker stats table.  for me it would give me the ability to identify lower performing workers by shares ..

thank you sir.

Jim

[Coolhwip]

More(some) info about the planned Mining teams feature would be cool.

Thanks

[dyngnosis]

Also, though it may seem trivial it would be very nice to be able to set time zone on block completion for my browsing pleasure (Block Completion Time)

[jjiimm_64]

Also, though it may seem trivial it would be very nice to be able to set time zone on block completion for my browsing pleasure (Block Completion Time)

i concur.  local time zones would help me too...  I find myself confused everytime I try and subtract 4 hours from all times.... or is it 5 now?

edit...  a 27 second block..  very kool
2011-07-29 01:34:37   0:00:27   12676   115 until confirmed   40   0.15383401

[Xephan]

You are the one making the claim.  The burden of proof is on you.  I'm just poking holes in it, I have to prove nothing.

point ceded

Let me try it another way.  You are saying that 10 miners doing 500 Mhash/sec each are better than 100 miners doing 50 Mhash/sec each.  As evidence in support of your hypothesis, you say that the big pools are getting more blocks than you would expect based purely on their (estimated) fraction of the (estimated) global hashing power.

The problem is that you don't have any idea on the composition of the miners inside the pools.  Let me give you an example.  BTC Guild is reporting about 2.3 THash/sec now, but it provides no data on the number or speed of the miners that make that number.  Could be 9000 miners turning in ~260 Mhash/sec each, or it could be 15,000 miners doing ~150 Mhash/sec each.  Could be anything, really.

*cough* In the last block, the effective hash rate was 2.354TH/s, the fastest miner had an estimated hashrate of 34214.55 MH/s, the slowest groups of miners out of 2957 miners for that block seems to be CPU miners with 3.38MH/s

One thing I like about BTCG is that the stats are public. Unfortunately triplemining is the only other pool I've found to provide similar data. If there was a third or fourth pool with hash rates somewhere in between, I might be able to test the theory better.

So, you aren't actually providing any evidence to support your claim.  Unless you have some reason to believe that the distribution of miners in the larger pools is unusual in some way, the whole topic of pools is an unrelated distraction.

I am using and collecting available data, so far the 10% gap remains. If it was all equal, then this gap should disappear over time assuming I just happened to pick an abnormal period to start tabulating. But the longer it gets, the more likely that a higher hashrate may have a small but discernible impact on "luck".

[kjj]

*cough* In the last block, the effective hash rate was 2.354TH/s, the fastest miner had an estimated hashrate of 34214.55 MH/s, the slowest groups of miners out of 2957 miners for that block seems to be CPU miners with 3.38MH/s

You are confusing miner, the human with an account on BTC Guild, with miner, the hardware/software combination that does the work.  In pool terminology, the second sort of miner is sometimes called a worker.  But you have to be careful there too.  There is no requirement that a miner (human) has to use a different worker entry for each of their miners (devices).

There is no device capable of mining at 34 gigahashes per second.  That is clearly an aggregation of many, many devices.  So, you still have no idea of the distribution of hashing speed by devices.

And your hypothesis only makes sense when applied to devices, not people or aggregations.

[Xephan]

There is no requirement that a miner (human) has to use a different worker entry for each of their miners (devices).

Quite true.

There is no device capable of mining at 34 gigahashes per second.  That is clearly an aggregation of many, many devices.  So, you still have no idea of the distribution of hashing speed by devices.

And your hypothesis only makes sense when applied to devices, not people or aggregations.

Yes, I know that the fastest workers are comprised of many devices and that the latency angle I'm looking at may not be applicable in this sort of scenario. Since mathematically speaking, a super group of 20 large groups of 10 devices should be equal to a super group of 200 devices. But I cannot shake off the feeling that the overall hashrate has an effect similar to latency.

In the process of putting together a crude simulation to test my hypothesis