Pages:
Author

Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 28. (Read 379076 times)

legendary
Activity: 1876
Merit: 1000
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 Wink

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


legendary
Activity: 1750
Merit: 1007
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.
legendary
Activity: 1449
Merit: 1001
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 Smiley
legendary
Activity: 1876
Merit: 1000
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?
newbie
Activity: 42
Merit: 0
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.
legendary
Activity: 1820
Merit: 1000
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.
legendary
Activity: 1750
Merit: 1007
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.
kjj
legendary
Activity: 1302
Merit: 1026
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.

Quote
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 Cheesy

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.
legendary
Activity: 1148
Merit: 1001
Radix-The Decentralized Finance Protocol
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.
newbie
Activity: 16
Merit: 0
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.
legendary
Activity: 1148
Merit: 1001
Radix-The Decentralized Finance Protocol
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?
newbie
Activity: 16
Merit: 0
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.
legendary
Activity: 1148
Merit: 1001
Radix-The Decentralized Finance Protocol
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?
legendary
Activity: 1876
Merit: 1000

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.
newbie
Activity: 42
Merit: 0
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.

6 can be substituted with any number and the result will still be the same for two pools with equal total hash rate but one has faster average workers than the other.
newbie
Activity: 42
Merit: 0

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.
sr. member
Activity: 404
Merit: 250
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.
newbie
Activity: 30
Merit: 0


It appears that E is scamming us... he is clearly adding solving blocks on his own and giving them to us...

24 Hour Luck       +9.2%



woohoo!
newbie
Activity: 42
Merit: 0
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.

Quote
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 Cheesy
legendary
Activity: 1876
Merit: 1000

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!
Pages:
Jump to: