[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[Richy_T]

this flat section is a freeze of bitcoind process (freeze of bitcoin deamon server RPC-JSON).
you have this, too ... when sharechain of P2Pool (local files) have a problem ... (remember this : 17500 shares valid v14 but 20650 shares available ...).

XT node with maxmempooltx purge system draw this :

No offline section.

That would explain things... if the bitcoind process was frozen and you were still mining to that node that actually explains everything.  Because bitcoind wasn't fetching new blocks, p2pool was always mining to an old block.  You were submitting shares just fine on your node.  The rest of the network was rejecting your shares (since they were from old blocks).  Then when things came back to life on your node, things caught back up, the shares you submitted were immediately dropped and your expected payment went to what the network thought it should be.

In effect, even though your miners were mining, they weren't doing anything useful because they were solving shares for blocks that were already on the chain.

Yes - that sounds like the problem to me too - well spotted Meuh6879  

Looks like that's my answer then. Thanks guys.

I guess the increased bandwidth was probably because I kept spewing shitty info to other nodes and they kept re-requesting it (or however that bit works).

I guess the question is how best to prevent this going forward. I don't have any objection to XT (I'm already running the BIP101 patch) so that may be the way to go.

[1713491501]

1713491501

[1713491501]

1713491501

[1713491501]

1713491501

[p3yot33at3r]

That system is using spinning-disk media.

A HDD? Do people still use them? 

I'd ditch that if I were you - they're terrible for Bitcoin wallet, p2pool & mining in general. Only good for servers now.

Glad we got to the bottom of this, it was a head banger for me, so I'm sure it was doing your nut in! 

[yslyung]

That system is using spinning-disk media.

A HDD? Do people still use them? 

I'd ditch that if I were you - they're terrible for Bitcoin wallet, p2pool & mining in general. Only good for servers now.

Glad we got to the bottom of this, it was a head banger for me, so I'm sure it was doing your nut in! 

not really .... mine runs on hdd (wd reds) on RAID 10 is as fast or faster than a regular ssd & much more cost efficient, lots of space & if any of the hdd fails it still works.

[p3yot33at3r]

That system is using spinning-disk media.

A HDD? Do people still use them? 

I'd ditch that if I were you - they're terrible for Bitcoin wallet, p2pool & mining in general. Only good for servers now.

Glad we got to the bottom of this, it was a head banger for me, so I'm sure it was doing your nut in! 

not really .... mine runs on hdd (wd reds) on RAID 10 is as fast or faster than a regular ssd & much more cost efficient, lots of space & if any of the hdd fails it still works.

RAID 10 & WD Reds are for server/nas, and although it's a good quality configuration & will run fine, if you compare a read/write test result between those discs & the same setup but with quality SSD's instead of HDD's, the SSD's will win hands down, every time. Always. I use Reds on my server, performance is great, but after testing the speeds, I went with a SSD setup on a dedicated mining rig. Also, SSD's use a fraction of the electricity, which is handy for a rig that's on 24/7.

[Richy_T]

That system is using spinning-disk media.

A HDD? Do people still use them?  

I'd ditch that if I were you - they're terrible for Bitcoin wallet, p2pool & mining in general. Only good for servers now.

Glad we got to the bottom of this, it was a head banger for me, so I'm sure it was doing your nut in!  

Haha, yeah. It's pretty OK for Bitcoind as mostly you're just storing 60GB of history and they are great for long-term storage of bulky data that is not speed sensitive. I do have a 125G SSD that I just upgraded from from my workstation so I may throw that in as the boot disk but I doubt I'd put the blockchain on it.

Now, if someone want to tell me it would really benefit to have p2pool use one, I'm willing to listen.

[Meuh6879]

I guess the question is how best to prevent this going forward. I don't have any objection to XT (I'm already running the BIP101 patch) so that may be the way to go.

the following post indicate somes values for the maxmempooltx that you can try : https://github.com/bitcoinxt/bitcoinxt/issues/82

I use 800-1200 (mempool = 3Mb to 6Mb for 0 minfee and 0,00001 relayfee).
Daily modified to ensure the fluidity and the max block rotation (1Mb).

that's why i have write this post (github) to push the dev. to install a automated way (of peace) to manage this problem.

[p3yot33at3r]

That system is using spinning-disk media.

A HDD? Do people still use them?  

I'd ditch that if I were you - they're terrible for Bitcoin wallet, p2pool & mining in general. Only good for servers now.

Glad we got to the bottom of this, it was a head banger for me, so I'm sure it was doing your nut in!  

Haha, yeah. It's pretty OK for Bitcoind as mostly you're just storing 60GB of history and they are great for long-term storage of bulky data that is not speed sensitive. I do have a 125G SSD that I just upgraded from from my workstation so I may throw that in as the boot disk but I doubt I'd put the blockchain on it.

Now, if someone want to tell me it would really benefit to have p2pool use one, I'm willing to listen.

My rig, running 64bit Xubuntu, runs a 60GB Corsair system SSD. I use a 256GB HyperX SSD for the 13 wallet data directories that I'm merge mining with p2pool - plus 7 other coin wallets that I mine with another p2pool instance on occasion, ie: when I'm playing  The speed is faster than my crappy internet, which I believe to be the cause of most of my orphans/doa's - of which there are few, my node very rarely goes below 105% efficiency & sometimes, when my internet is stable, it goes up to 125%.

I couldn't do this with HDD's. No way. So yeah, SSD's are the way to go - but use quality ones. I'm a huge fan of the HyperX - I run one in my PC too, and my Netbook. 

[Richy_T]

I couldn't do this with HDD's. No way. So yeah, SSD's are the way to go - but use quality ones. I'm a huge fan of the HyperX - I run one in my PC too, and my Netbook. 

I had good lock with the Sandisk in 125 so I stuck with the make when I went to 250 but stepped up to Ultra II. I like it so far and I've bought a couple more to throw in laptops when I get time to do the imaging...

Looking at my server where I also run the bitcoind, it looks like the system partitions would fit on with room to spare so I may go with bitcoind and p2pool on there. That's if I can remember how to get through the nightmare that is setting up a drive to work with UEFI on my motherboard.

[idonothave]

OK, think I'm done with this pool. My payout on the last block according to the graph should have been 0.012 but was actually around 0.005. Then I had to restart the pool and bitcoind and my shares dropped again. Something screwy, chaps.

I'm not sure what front end your running, but the predicted payout reported by p2pool is exact if a block is found "now". Perhaps you had some shares drop off from when you saw it and when the block was mined?

Nope. The block was mined at 08:59:53.

The graph shows 0.014 up until I had to kill the p2pool and bitcoind at 09:05 because it was interfering with my Cisco phone. (I blame the Cisco phone for this FWIW).

Payout was around 0.005 (Won't say the exact amount)

Then the graph shows a gap before I started bitcoind and p2pool again when my call was done.

Then the graph continues to show 0.014 for a few minutes then it drops to 0.005, apparently losing most of the shares I had taken the last 24 hours building up.

Someone suggested that maybe the payout address had changed for my earlier issue of losing shares. Besides the fact that I had been running p2pool without restarting from way before it happened so that couldn't have been the case, I also just changed my payout address (to one that I'm OK with sharing) and the payout dropped to 0 (as you would expect) whereas before when it happened, it didn't.

would this happen if data directory is deleted/corrupted?

[Richy_T]

[Deleted] Want to do some more research before jumping on this one.

[Richy_T]

OK, The issue has now been affecting me since 9am this morning I have tried restarting bitcoind and p2pool both separately and together and the problem persists. I have actually tried copying the p2pool directory and cleaning out the data/bitcoin directory. When I did this, I noticed p2pool was not able to stay connected to peers to download shares. I copied the "addresses" file into the directory again and a few shares are downloading but I am still getting a lot of disconnects. The error is this:

2015-10-22 19:43:23.180634 Lost peer xx.xx.xx.xx:9333 - Connection was aborted locally, using.

I am beginning to think that I am getting blocked by p2pool on other hosts. Is there any way to check this?

[Richy_T]

More of a clue?

2015-10-22 19:08:36.403770 Peer xx.xx.xx.xx:9333 misbehaving, will drop and ban. Reason: was connected to self
2015-10-22 19:08:36.403893 Bad peer banned: (u'xx.xx.xx.xx', 9333)

Where this is my IP in the logs.

I also see this for other IP addresses so maybe I was somehow connected to myself and other nodes saw it and have banned me? How can this be avoided in future?

[Polyatomic]

err is that an internal ip, there reserved.
I'm thinking it should be ok to not hide them.

[Richy_T]

err is that an internal ip, there reserved.
I'm thinking it should be ok to not hide them.

Sorry, no, I should have specified. That is my external public IP

Though also in the log with the same error are the private IP of my p2pool node and the private IP of my router. Looks like p2pool got itself into a state somehow. These are also in the addrs file so that would be why it persists I guess.

[p3yot33at3r]

More of a clue?

2015-10-22 19:08:36.403770 Peer xx.xx.xx.xx:9333 misbehaving, will drop and ban. Reason: was connected to self
2015-10-22 19:08:36.403893 Bad peer banned: (u'xx.xx.xx.xx', 9333)

Where this is my IP in the logs.

I also see this for other IP addresses so maybe I was somehow connected to myself and other nodes saw it and have banned me? How can this be avoided in future?

See this post:

https://bitcointalk.org/index.php?topic=18313.msg829445#msg829445

I get them now & again too, I don't think it's a problem.

I think it's a corruption issue that's causing your problems. Have you checked your memory & HDD's for errors?

[Richy_T]

See this post:

https://bitcointalk.org/index.php?topic=18313.msg829445#msg829445

I get them now & again too, I don't think it's a problem.

I think it's a corruption issue that's causing your problems. Have you checked your memory & HDD's for errors?

Not recently but I do other stuff on that system that runs with no issue. I'll schedule a disk scan and some time with memtest but I personally don't think that's going to be it.

I am trying with a clean install of p2pool to see where that gets me though.

[Polyatomic]

Richy_T: noes!, you quoted my typo.
@typo
<p2pool-bot> Polyatomic's typo is awesome.

[jcumins]

I have 14 Bitmain s-5 and i have approx 5 that lockup almost daily, and require a power cycle to get them back on line.  And a couple of then run at half there hash rate. 

Does any one have any ideas,  it makes not different what version of firmware to include the nicehase version there still doing the same thing. I have 8 to 10 that run rock solid like my s-3 do. 

I am out of ideas and am wondering if anyone else has this issue.

Thanks

John

[p3yot33at3r]

Two of mine locked up with the nicehash firmware too - so I dumped it. Are you running them overclocked?

Try this firmware:

https://www.dropbox.com/s/gk6gva5e12g4qsr/SD-S5-20150107_cgm_4_9_0-queue_0_no-submit.tar.gz?dl=0

It's been solid for me & has the correct settings, ie submit stale, queue & lowmem. If you must OC, Start off at default clock speed & work up gradually keeping an eye on HW errors. If it locks up it usually means you're over cooking it. Bear in mind that p2pool is quite miner intensive & hash rates will always be slightly lower. Bitmain firmware can't cope, cos its poo......

Edit: It should also stick after reboots.

[Meuh6879]

I have 14 Bitmain s-5 and i have approx 5 that lockup almost daily, and require a power cycle to get them back on line.  And a couple of then run at half there hash rate.  

change supply.