Bitcoin Forum
December 11, 2016, 08:07:02 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 [495] 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2035608 times)
wlz2011
Member
**
Offline Offline

Activity: 71


View Profile
August 05, 2014, 07:27:16 AM
 #9881

Please help me

LAN 192.168.0.250:9332, 192.168.0.252: 9332.

How these two pools of fixed interconnected team.

Which folder should be modified? Thank you. Smiley
1481443622
Hero Member
*
Offline Offline

Posts: 1481443622

View Profile Personal Message (Offline)

Ignore
1481443622
Reply with quote  #2

1481443622
Report to moderator
1481443622
Hero Member
*
Offline Offline

Posts: 1481443622

View Profile Personal Message (Offline)

Ignore
1481443622
Reply with quote  #2

1481443622
Report to moderator
1481443622
Hero Member
*
Offline Offline

Posts: 1481443622

View Profile Personal Message (Offline)

Ignore
1481443622
Reply with quote  #2

1481443622
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jedimstr
Hero Member
*****
Offline Offline

Activity: 784



View Profile
August 05, 2014, 10:14:49 AM
 #9882

On number 2 Grin
I have been wondering about this. This isn't really about shares, but diff with high hashrate miners question. When Mr 80TH's shows up on pool it's just killing everyone else it seems. Default diff is 999 or so. Based on what you're saying that is not actually correct because if you get a share it's worth more.
Currently one address around 12TH/s and you just see all the estimated earnings going down for smaller miners.

Have your smaller miners use /0 or whatever you think is appropriate so their share diff is not raised from the larger ones. On my front end I show the miners share diff and expected time to share by address so they can adjust it as necessary.

This is if you use a public node...if you have your own it really shouldn't matter.

Did you lift some of your suggested settings from Norgz' Antminer settings page?
http://www.norgzpool.net.au/antminer.html


bryonp
Member
**
Offline Offline

Activity: 77


View Profile
August 05, 2014, 10:37:54 AM
 #9883

On number 2 Grin
I have been wondering about this. This isn't really about shares, but diff with high hashrate miners question. When Mr 80TH's shows up on pool it's just killing everyone else it seems. Default diff is 999 or so. Based on what you're saying that is not actually correct because if you get a share it's worth more.
Currently one address around 12TH/s and you just see all the estimated earnings going down for smaller miners.

Have your smaller miners use /0 or whatever you think is appropriate so their share diff is not raised from the larger ones. On my front end I show the miners share diff and expected time to share by address so they can adjust it as necessary.

This is if you use a public node...if you have your own it really shouldn't matter.

Did you lift some of your suggested settings from Norgz' Antminer settings page?
http://www.norgzpool.net.au/antminer.html



OK this link is the easiest for me to follow and accomplish...
Do you really feel that this will make my outcome much better?? I hate to screw around with the settings and have amess on my hands.
! am running 16 S-1's

As soon as we jump up in hashing... my income drops to peanuts?

PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
August 05, 2014, 10:38:31 AM
 #9884

Greetings guys/gals,

Been out of the country for a few weeks so only got to setting up my S3's a few days ago, but I'm now able to get back to mining with p2pool again & thought I'd share my experience with them after tinkering for a few days trying to find the optimal settings. Generally I'm quite impressed with the S3, even though the performance can vary massively between different devices with the same settings.

They are all B1 units flashed with the latest (non beeping) firmware for my own sanity. I done some reading up on other users experiences/settings & decided to stay away from using the --scan-time 1 --expiry 1 on the advice of ck, choosing to play with the --queue settings & frequencies instead. I have always used --queue 0 with p2pool, believing this to be the optimal requirement, but found that --queue 1 resulted in the lowest discard rate & stopped the cpu maxing out at 100% - why this is I'm not sure, but I'll roll with it. All of my S3's cpu rate now hover ~85% with a much more acceptable discard rate. The freq settings are either 218.75, 237.5 or 250 depending on the unit - some flat refuse to go above 218.75 without losing the plot - others sit there at 250 with less HW errors/discards/rejects than those running at 218.75   Huh I also found 225 to be the worst performing freq of the lot!

Generally I'm quite impressed with them though and it's good to be back on p2pool. I had an email from Bitmain saying they would have a solution for various p2pool issues soon, that was 4 weeks ago & I've not heard a dickey bird since. I did also try their recommended setting of /256 +256 but found them to make no difference whatsoever, so I let p2pool decide the diff which seems to work pretty well. All the units were stripped & checked for lose screws etc before using, but generally the build quality was sound.

With everything that is going on with AMT, KNC, Rockminer, Black Arrow, Spondoolies etc, it seems Bitmain have not only come out with another little gem - but have probably saved p2pools bacon by ensuring that the S3's are at least usable with p2pool, even if not 100% efficiently - hopefully this will be addressed soon with a little more whining encouragement from p2pool users.....the increase in p2pool hashrate is testament to this and I'm wondering if the massive hashrate fluctuations are actually Bitmain keeping true to their promise of investing their equipment into p2pool......that would be nice  Grin

Did we get a new dev yet by the way?

Peace  Smiley

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
CartmanSPC
Legendary
*
Offline Offline

Activity: 1148



View Profile WWW
August 05, 2014, 06:42:42 PM
 #9885

On number 2 Grin
I have been wondering about this. This isn't really about shares, but diff with high hashrate miners question. When Mr 80TH's shows up on pool it's just killing everyone else it seems. Default diff is 999 or so. Based on what you're saying that is not actually correct because if you get a share it's worth more.
Currently one address around 12TH/s and you just see all the estimated earnings going down for smaller miners.

Have your smaller miners use /0 or whatever you think is appropriate so their share diff is not raised from the larger ones. On my front end I show the miners share diff and expected time to share by address so they can adjust it as necessary.

This is if you use a public node...if you have your own it really shouldn't matter.

Did you lift some of your suggested settings from Norgz' Antminer settings page?
http://www.norgzpool.net.au/antminer.html


Nope, have not seen that site before. Their recommendation on /0+220 seems good for S1's. You could play with the 220 until you get a pseudo share diff that your comfortable with.

In regard to the --scan-time 1 --expiry 1 settings I read a detailed post (I think from ck) saying those were essentially obsolete. Wish I would have saved it.

Duce
Full Member
***
Offline Offline

Activity: 155


View Profile
August 05, 2014, 06:50:17 PM
 #9886

On number 2 Grin
I have been wondering about this. This isn't really about shares, but diff with high hashrate miners question. When Mr 80TH's shows up on pool it's just killing everyone else it seems. Default diff is 999 or so. Based on what you're saying that is not actually correct because if you get a share it's worth more.
Currently one address around 12TH/s and you just see all the estimated earnings going down for smaller miners.

Have your smaller miners use /0 or whatever you think is appropriate so their share diff is not raised from the larger ones. On my front end I show the miners share diff and expected time to share by address so they can adjust it as necessary.

This is if you use a public node...if you have your own it really shouldn't matter.

Did you lift some of your suggested settings from Norgz' Antminer settings page?
http://www.norgzpool.net.au/antminer.html


Nope, have not seen that site before. Their recommendation on /0+220 seems good for S1's. You could play with the 220 until you get a pseudo share diff that your comfortable with.

In regard to the --scan-time 1 --expiry 1 settings I read a detailed post (I think from ck) saying those were essentially obsolete. Wish I would have saved it.

Here it is https://bitcointalk.org/index.php?topic=18313.msg8036549#msg8036549
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 05, 2014, 11:38:21 PM
 #9887

On number 2 Grin
I have been wondering about this. This isn't really about shares, but diff with high hashrate miners question. When Mr 80TH's shows up on pool it's just killing everyone else it seems. Default diff is 999 or so. Based on what you're saying that is not actually correct because if you get a share it's worth more.
Currently one address around 12TH/s and you just see all the estimated earnings going down for smaller miners.

Have your smaller miners use /0 or whatever you think is appropriate so their share diff is not raised from the larger ones. On my front end I show the miners share diff and expected time to share by address so they can adjust it as necessary.

This is if you use a public node...if you have your own it really shouldn't matter.

Did you lift some of your suggested settings from Norgz' Antminer settings page?
http://www.norgzpool.net.au/antminer.html


Nope, have not seen that site before. Their recommendation on /0+220 seems good for S1's. You could play with the 220 until you get a pseudo share diff that your comfortable with.

In regard to the --scan-time 1 --expiry 1 settings I read a detailed post (I think from ck) saying those were essentially obsolete. Wish I would have saved it.
Ok... did a little investigating on this issue.  First off, setting the difficulty to /0 or +0 actually initially sets both to the highest possible values.  First the code in work.py in get_user_details:
Code:
desired_pseudoshare_target = None
desired_share_target = None
for symbol, parameter in zip(contents2[::2], contents2[1::2]):
  if symbol == '+':
    try:
      desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
    except:
      if p2pool.DEBUG:
        log.err()
  elif symbol == '/':
    try:
      desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
    except:
      if p2pool.DEBUG:
        log.err()
Now the code for bitcoin_data.difficulty_to_target:
Code:
def difficulty_to_target(difficulty):
    assert difficulty >= 0
    if difficulty == 0: return 2**256-1
    return min(int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5), 2**256-1)

So for sure don't set your miners to /0 or +0.

The only time I can find any mention of the dust threshold of the coin in the code is when you have not set a difficulty.  In this case if the expected payout per block is less than the dust threshold, it resets your desired difficulty such that your expected payout is greater than that threshold.  Here's the code:
Code:
if desired_share_target is None:
            desired_share_target = 2**256-1
            local_hash_rate = self._estimate_local_hash_rate()
            if local_hash_rate is not None:
                desired_share_target = min(desired_share_target,
                    bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167)) # limit to 1.67% of pool shares by modulating share difficulty

            local_addr_rates = self.get_local_addr_rates()
            lookbehind = 3600//self.node.net.SHARE_PERIOD
            block_subsidy = self.node.bitcoind_work.value['subsidy']
            if previous_share is not None and self.node.tracker.get_height(previous_share.hash) > lookbehind:
                expected_payout_per_block = local_addr_rates.get(pubkey_hash, 0)/p2pool_data.get_pool_attempts_per_second(self.node.tracker, self.node.best_share_var.value, lookbehind) \
                    * block_subsidy*(1-self.donation_percentage/100) # XXX doesn't use global stale rate to compute pool hash
                if expected_payout_per_block < self.node.net.PARENT.DUST_THRESHOLD:
                    desired_share_target = min(desired_share_target,
                        bitcoin_data.average_attempts_to_target((bitcoin_data.target_to_average_attempts(self.node.bitcoind_work.value['bits'].target)*self.node.net.SPREAD)*self.node.net.PARENT.DUST_THRESHOLD/block_subsidy)
                    )

I'm going to keep digging through the code to see what more I can learn from it.

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
contactlight
Full Member
***
Offline Offline

Activity: 168


View Profile
August 05, 2014, 11:48:58 PM
 #9888

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.
CartmanSPC
Legendary
*
Offline Offline

Activity: 1148



View Profile WWW
August 05, 2014, 11:49:55 PM
 #9889

Ok... did a little investigating on this issue.  First off, setting the difficulty to /0 or +0 actually initially sets both to the highest possible values.  First the code in work.py in get_user_details:

So for sure don't set your miners to /0

I'm going to keep digging through the code to see what more I can learn from it.

Keep digging...don't think your assertation is correct. I know from experience that /0 absolutely sets your miners to get shares at the smallest possible p2pool share difficulty (currently at 4608650.012 for BTC).

ceslick
Full Member
***
Offline Offline

Activity: 161

digging in the bits... now ant powered!


View Profile WWW
August 05, 2014, 11:52:33 PM
 #9890

Then Norgs guide saying add /0+220 to your address is not optimum?

Should it just be +220?

http://www.integratedideas.net  - Home of Rock Solid Miners
NZ Based BTC P2Pool: http://www.integratedideas.net/p2pool-btc/  -  NZ Based DOGE P2Pool: http://www.integratedideas.net/p2pool-doge/
Cloud mining with CEX.IO: https://cex.io/r/2/ceslicknz/0/
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 06, 2014, 12:14:32 AM
 #9891

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.

Try running a local p2pool node.  Point your miners to it, and see what p2pool says for "expected time to share".

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 06, 2014, 12:22:33 AM
 #9892

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.
I've got 5 S3s pointed to p2pool and have found 11 shares in the past 24 hours.  There's nothing wrong with how they function with p2pool.  I wish you the best of luck on Eligius.  Wizkid's got a good pool there.

Ok... did a little investigating on this issue.  First off, setting the difficulty to /0 or +0 actually initially sets both to the highest possible values.  First the code in work.py in get_user_details:

So for sure don't set your miners to /0

I'm going to keep digging through the code to see what more I can learn from it.

Keep digging...don't think your assertation is correct. I know from experience that /0 absolutely sets your miners to get shares at the smallest possible p2pool share difficulty (currently at 4608650.012 for BTC).
That's why I'm still looking.  I want to be absolutely sure.  To this point, however, there is nothing in the code that I've seen to indicate anything other than what I've posted.  Besides, why take the chance?  If you intend to set your difficulty manually to some silly low value, just use /1 instead.

Basically, my search is now concentrating on finding some comparison to the effect of "take the greater of my desired share difficulty and p2pool's minimum share difficulty" during miner payout calculations.  If your assertion is correct, then I need to find some other piece of code that says, "if desired share difficulty equals 2**256-1, set share difficulty equal to minimum p2pool share difficulty".

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
ceslick
Full Member
***
Offline Offline

Activity: 161

digging in the bits... now ant powered!


View Profile WWW
August 06, 2014, 12:27:53 AM
 #9893

In other news p2pool approaching 2.5PHash

http://www.integratedideas.net  - Home of Rock Solid Miners
NZ Based BTC P2Pool: http://www.integratedideas.net/p2pool-btc/  -  NZ Based DOGE P2Pool: http://www.integratedideas.net/p2pool-doge/
Cloud mining with CEX.IO: https://cex.io/r/2/ceslicknz/0/
contactlight
Full Member
***
Offline Offline

Activity: 168


View Profile
August 06, 2014, 12:49:35 AM
 #9894

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.

Try running a local p2pool node.  Point your miners to it, and see what p2pool says for "expected time to share".

M

I've tried that as well. I live in San Francisco and I have dedicated servers in a datacenter in San Francisco as well. I set up a full Bitcoin node on one of them and set up P2Pool. My latency was under 20ms and my DOA was around 2%. It was pretty much the most optimal setup that you can get without having them on the same network.

Expected time to share was about 5 hours and I haven't gotten any shares in over 24 hours with that setup either.

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.
I've got 5 S3s pointed to p2pool and have found 11 shares in the past 24 hours.  There's nothing wrong with how they function with p2pool.  I wish you the best of luck on Eligius.  Wizkid's got a good pool there.

While Eligius is really good and I am fine with switching to them, I really want to stick with P2Pool if possible. It is the "right" way to mine in my mind.

I have two S3s and you would expect them to have found around 4 shares since your 5 found 11. Variance, bad luck etc. but still 0 shares? That doesn't make much sense to me. We can't just decide not to even try to debug a distributed system because it has a random component. It's like saying it's not a bug, it's a feature.
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 06, 2014, 01:02:22 AM
 #9895

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.

Try running a local p2pool node.  Point your miners to it, and see what p2pool says for "expected time to share".

M

I've tried that as well. I live in San Francisco and I have dedicated servers in a datacenter in San Francisco as well. I set up a full Bitcoin node on one of them and set up P2Pool. My latency was under 20ms and my DOA was around 2%. It was pretty much the most optimal setup that you can get without having them on the same network.

Expected time to share was about 5 hours and I haven't gotten any shares in over 24 hours with that setup either.

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.
I've got 5 S3s pointed to p2pool and have found 11 shares in the past 24 hours.  There's nothing wrong with how they function with p2pool.  I wish you the best of luck on Eligius.  Wizkid's got a good pool there.

While Eligius is really good and I am fine with switching to them, I really want to stick with P2Pool if possible. It is the "right" way to mine in my mind.

I have two S3s and you would expect them to have found around 4 shares since your 5 found 11. Variance, bad luck etc. but still 0 shares? That doesn't make much sense to me. We can't just decide not to even try to debug a distributed system because it has a random component. It's like saying it's not a bug, it's a feature.
I agree it sucks that you haven't found any shares but what exactly would somebody debug?  If every S3 suffered the problem (like the S2's documented loss of hash rate) then there would be something to look into.  If your miners are reporting good hash rates with low errors, low rejects and low DOA then they're working properly.  Didn't you previously post that the same hardware was finding shares a few weeks ago?  If that wasn't you then I apologize.  My point though is that the most likely answer is simply bad luck.  There just isn't enough evidence to point to problems with the hardware.

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
contactlight
Full Member
***
Offline Offline

Activity: 168


View Profile
August 06, 2014, 01:10:19 AM
 #9896

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.

Try running a local p2pool node.  Point your miners to it, and see what p2pool says for "expected time to share".

M

I've tried that as well. I live in San Francisco and I have dedicated servers in a datacenter in San Francisco as well. I set up a full Bitcoin node on one of them and set up P2Pool. My latency was under 20ms and my DOA was around 2%. It was pretty much the most optimal setup that you can get without having them on the same network.

Expected time to share was about 5 hours and I haven't gotten any shares in over 24 hours with that setup either.

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.
I've got 5 S3s pointed to p2pool and have found 11 shares in the past 24 hours.  There's nothing wrong with how they function with p2pool.  I wish you the best of luck on Eligius.  Wizkid's got a good pool there.

While Eligius is really good and I am fine with switching to them, I really want to stick with P2Pool if possible. It is the "right" way to mine in my mind.

I have two S3s and you would expect them to have found around 4 shares since your 5 found 11. Variance, bad luck etc. but still 0 shares? That doesn't make much sense to me. We can't just decide not to even try to debug a distributed system because it has a random component. It's like saying it's not a bug, it's a feature.
I agree it sucks that you haven't found any shares but what exactly would somebody debug?  If every S3 suffered the problem (like the S2's documented loss of hash rate) then there would be something to look into.  If your miners are reporting good hash rates with low errors, low rejects and low DOA then they're working properly.  Didn't you previously post that the same hardware was finding shares a few weeks ago?  If that wasn't you then I apologize.  My point though is that the most likely answer is simply bad luck.  There just isn't enough evidence to point to problems with the hardware.

If P2Pool was better documented, I would be able to form some sort of hypothesis but I can't due to the lack of documentation.

I know that P2Pool server essentially "lies" the the miner with psuedoshares so that it keeps mining. That's why I don't think the miner-side statistics would be very helpful in this case. I could look into the code and try to figure out what might be going wrong but that's what I do all day with my job anyway. Smiley

And you're correct, that was me. When I first started mining with my S3s on P2Pool, I found four, maybe five shares in a row but I pretty much never found any other shares after that.

I am running on the latest firmware by the way. I am not sure if others upgraded to it. It could be a problem with that firmware.

As far as I can tell Antminer S3s are running a modified version of "cgminer 3.12.0". This seems to be outdated and I might try cross-compiling the newest version. However, that lacks the Bitmain modifications and it will be less than ideal.
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 06, 2014, 01:11:23 AM
 #9897

I've tried that as well. I live in San Francisco and I have dedicated servers in a datacenter in San Francisco as well. I set up a full Bitcoin node on one of them and set up P2Pool. My latency was under 20ms and my DOA was around 2%. It was pretty much the most optimal setup that you can get without having them on the same network.

My node (http://96.44.166.190:9332) is in LA.  Looks like I have two folks there with a pair of S3s.  Try pointing your workers there and see if you notice a difference.

Also, despite all the talk going on here, I don't recommend messing with share size with + or /.  Just use your payout address and see what happens.  Once you know that's working, then try customizing it.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
contactlight
Full Member
***
Offline Offline

Activity: 168


View Profile
August 06, 2014, 01:15:20 AM
 #9898

I've tried that as well. I live in San Francisco and I have dedicated servers in a datacenter in San Francisco as well. I set up a full Bitcoin node on one of them and set up P2Pool. My latency was under 20ms and my DOA was around 2%. It was pretty much the most optimal setup that you can get without having them on the same network.

My node (http://96.44.166.190:9332) is in LA.  Looks like I have two folks there with a pair of S3s.  Try pointing your workers there and see if you notice a difference.

Also, despite all the talk going on here, I don't recommend messing with share size with + or /.  Just use your payout address and see what happens.  Once you know that's working, then try customizing it.

M

Switching them to your node right now with the default settings. Let's see what happens. I'll test them on your node until 7am tomorrow.

My miner is the address ending with "osx".
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 06, 2014, 02:04:27 AM
 #9899

I've tried that as well. I live in San Francisco and I have dedicated servers in a datacenter in San Francisco as well. I set up a full Bitcoin node on one of them and set up P2Pool. My latency was under 20ms and my DOA was around 2%. It was pretty much the most optimal setup that you can get without having them on the same network.

My node (http://96.44.166.190:9332) is in LA.  Looks like I have two folks there with a pair of S3s.  Try pointing your workers there and see if you notice a difference.

Also, despite all the talk going on here, I don't recommend messing with share size with + or /.  Just use your payout address and see what happens.  Once you know that's working, then try customizing it.

M

Switching them to your node right now with the default settings. Let's see what happens. I'll test them on your node until 7am tomorrow.

My miner is the address ending with "osx".

Yes, I saw it pop on shortly after I posted my message.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
wlz2011
Member
**
Offline Offline

Activity: 71


View Profile
August 06, 2014, 08:24:27 AM
 #9900

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.

I've tried that as well. I live in San Francisco and I have dedicated servers in a datacenter in San Francisco as well. I set up a full Bitcoin node on one of them and set up P2Pool. My latency was under 20ms and my DOA was around 2%. It was pretty much the most optimal setup that you can get without having them on the same network.

Expected time to share was about 5 hours and I haven't gotten any shares in over 24 hours with that setup either.

While Eligius is really good and I am fine with switching to them, I really want to stick with P2Pool if possible. It is the "right" way to mine in my mind.

I have two S3s and you would expect them to have found around 4 shares since your 5 found 11. Variance, bad luck etc. but still 0 shares? That doesn't make much sense to me. We can't just decide not to even try to debug a distributed system because it has a random component. It's like saying it's not a bug, it's a feature.



其实你的问题很简单,P2POOL是PPLNS股份制的池,当前BTC网络难度,当前难度  18,736,441,558

那么你在P2POOL矿池,如果有2TH/S的矿机算力,将会看见 3小时左右1个Share。这是一个基本算力要求。

而P2POOL的Share,应该是BTC网络中的Share链长度,Share的难度会随着P2POOL的总算力增加,因为P2POOL有效Share,全球控制在17350个Share,

而一个块=25BTC,为了保证最低支付0.0001BTC,这个Share difficulty会根据全球P2POOL节点挖到的S来增加难度,P2POOL全球算力越大,Share difficulty就会越大,

那么相对应的算力挖到Share的时间就会更久,但是长期挖P2POOL,你会发现有时候Share 会在很短的时间内连续的被发现,这也证明了Share difficulty = BTC网络中的链长。

当大家都没有挖到当前难度的 Share ,P2POOL 17350的S大概是1小时就会失效100个Share,那么Share difficulty 就会降低。如果有效Share超过了17450个,你会发现Share difficulty大幅上涨。

能看见Share difficulty 5000000.

只要你持续挖P2POOL,100GH/S,大概一周时间也是可以挖到Share的。

你一定要坚定的相信,挖到Share只是时间问题,希望你有足够的信心。

http://111.205.1.246:9332

http://5.63.146.189:9332/static/graphs.html?Month

这需要很大的勇气和耐心 Grin
非常抱歉,我的英语不好,我看明白了你的问题,我只能用中文回复你 Smiley
Pages: « 1 ... 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 [495] 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 ... 744 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!