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

Richy_T

legendary

Activity: 2576

Merit: 2267

1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k

Quote from: idonothave on October 18, 2015, 02:03:12 PM

question was: Have one p2pool process connecting to multiple bitcoind processes via RPC at the same time?
you have answered: No.
how should I undersand this: [BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

Fallback option?

You might be able to connect to multiple bitcoinds with a load balancer, maybe.

idonothave

full member

Activity: 238

Merit: 100

Quote from: jtoomim on October 18, 2015, 01:25:42 PM

Quote from: idonothave on October 18, 2015, 01:11:04 PM

is run_p2pool.py able to connect more than one bitcoind?

I'm not exactly sure what you're trying to do.

Have one p2pool process connecting to multiple bitcoind processes via RPC at the same time? No.

Have more than one p2pool process running at a time from the same directory tree with the same bitcoind process and RPC port? Yes, but you might run into trouble with stats records and stuff like that. You'll need to specify different ports for each p2pool process.

Have more than one p2pool process running at a time, each of which connects to a different bitcoind? Yes.

question was: Have one p2pool process connecting to multiple bitcoind processes via RPC at the same time?
you have answered: No.
how should I undersand this: [BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

jtoomim

hero member

Activity: 818

Merit: 1006

Quote from: idonothave on October 18, 2015, 01:11:04 PM

is run_p2pool.py able to connect more than one bitcoind?

I'm not exactly sure what you're trying to do.

Have one p2pool process connecting to multiple bitcoind processes via RPC at the same time? No.

Have more than one p2pool process running at a time from the same directory tree with the same bitcoind process and RPC port? Yes, but you might run into trouble with stats records and stuff like that. You'll need to specify different ports for each p2pool process.

Have more than one p2pool process running at a time, each of which connects to a different bitcoind? Yes.

idonothave

full member

Activity: 238

Merit: 100

is run_p2pool.py able to connect more than one bitcoind?

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Quote from: jtoomim on October 18, 2015, 10:13:33 AM

The miner that found it has 2 TH/s.

Crazy eh? There's room for small miners yet Grin

Thank the cryptogods that block is over.

jtoomim

hero member

Activity: 818

Merit: 1006

New block. Thanks Cryptal.

http://btcpool.cryptal.net:9332/static/share.html#0000000000000000037433dd74c771d11a0ab32c274069a52b225080c47001c6

The miner that found it has 2 TH/s.

p3yot33at3r

sr. member

Activity: 266

Merit: 250

It's coming. Hang in there. Be strong.

Any....minute....now.... Grin

jtoomim

hero member

Activity: 818

Merit: 1006

Quote from: Meuh6879 on October 16, 2015, 11:05:40 AM

Quote from: p3yot33at3r on October 16, 2015, 10:32:46 AM

Edit: BTW, here's what I got with the new Bitcoin Core client:

not work ... everytime.

It looks like you're running out of RAM and swapping to disk. I suspect there may be a memory leak in Bitcoin Core when using minrelaytxfee, causing memory usage by bitcoind to climb to the multi-GB range even though the mempool itself is only using 10 MB or so. I suggest restarting bitcoind every few days until we figure out a better way of doing it. I'm working on a new mempool size limiter for Bitcoin XT which might help.

Meuh6879

legendary

Activity: 1512

Merit: 1012

CPU vs. mempool treatment (already spend, free rate limiter, etcs ...).

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Quote from: Richy_T on October 16, 2015, 10:51:54 AM

Quote from: p3yot33at3r on October 15, 2015, 07:11:23 PM

Edit: If the results are OK in the morning I'll do a reboot to make sure the settings keep - if they do then it's all good & I'll update my other S5's

I believe it will not. In which case, I may tweak this firmware instead

If I do, I'll make 4.9.0 the default.

Yeah, I ended up reverting back to my previous setup after all. The lower loads were nice but not nice enough to offset the lower hash rate Sad

I never tested to see if the settings were kept after a reboot though.

@ Meuh6879: I've never seen 25 second latency spikes before......something wrong there buddy, connection issues perhaps?

Meuh6879

legendary

Activity: 1512

Merit: 1012

Quote from: p3yot33at3r on October 16, 2015, 10:32:46 AM

Edit: BTW, here's what I got with the new Bitcoin Core client:

....nice

not work ... everytime.

Richy_T

legendary

Activity: 2576

Merit: 2267

1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k

Quote from: p3yot33at3r on October 15, 2015, 07:11:23 PM

Edit: If the results are OK in the morning I'll do a reboot to make sure the settings keep - if they do then it's all good & I'll update my other S5's

I believe it will not. In which case, I may tweak this firmware instead

If I do, I'll make 4.9.0 the default.

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Well, it's been a strange day today. Got neg'd by dogie then verbally attacked & insulted by this Carlton Banks guy while wishing the best to a new p2pool node:

Quote from: p3yot33at3r on October 16, 2015, 06:10:01 AM

Quote from: Carlton Banks on October 16, 2015, 06:07:00 AM

Quote from: p3yot33at3r on October 16, 2015, 03:10:17 AM

+1 for p2pool, the more the merrier Wink

Wow, what a lying POS.

To all that it may concern: this is the same sock-puppet master who tried to destroy p2pool by bullying it's developer off the project. Recommendation is not to listen to one single word that comes out of it's slimy mouth.

What on earth are you talking about Huh

Feel free to come over to the p2pool thread & explain how you came to this conclusion, as I don't want to derail OP's thread.

...does anyone know what he's going on about? I know he reads this thread, so here's my last conversation with forrestv from a few weeks ago for him to read:

Click image or read it here:

https://github.com/p2pool/p2pool/issues/270

Hardly "bullying the developer" Roll Eyes

......I've done nothing but support & promote p2pool since day one.....I'm confused......what's with the p2pool haters?

Edit: BTW, here's what I got with the new Bitcoin Core client:

....nice

Nevril

member

Activity: 108

Merit: 10

Quote from: Polyatomic on October 16, 2015, 04:49:07 AM

Hi May I?

what is

Code:

It is optimized to serve miners with at least 1THs and, most importantly, it has been specifically tweaked to work without dead times on rented hashpower from NiceHash.

exactly.

Basically it has a minimum share difficulty target higher than the default one provided by the vardiff algorithm of P2Pool.
This solves the issue often encountered with NiceHash which turns a given hashpower order in dead state if the received (virtual) share difficulty is lower than 128.
This happens also if you set a specific share difficulty when passing the username (btc_addr+diff). It this case mining starts, but then vardiff may turn down the difficulty, for example, at the starting phase or if the hashrate experience a drop. In all these cases the NiceHash order becomes dead and mining stops.
The new minimum value has been chosen to serve miners that are capable of at least 1 THs (the minimum NiceHash order has 5 THs).

EDIT: Now that I'm thinking of... I probably said something not so correct about the minimum needed hashrate to mine on my node since we are speaking of virtual share difficulty not actual.
I need to re-think of it after I get some good sleep (and bed time is still far...), but either way the issue with NiceHash is actually solved and the local DOA is around 3% on average which is near what I was trying to achieve. I'll take a better look at it tomorrow morning, time to do my real work now!

Polyatomic

sr. member

Activity: 257

Merit: 250

Hi, May I?

what is

Code:

It is optimized to serve miners with at least 1THs and, most importantly, it has been specifically tweaked to work without dead times on rented hashpower from NiceHash.

exactly.

Nevril

member

Activity: 108

Merit: 10

EDIT: after gathering enough statistics I've decided to turn down my node.

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Quote from: kano on October 15, 2015, 09:45:14 PM

Quote from: jtoomim on October 15, 2015, 06:53:17 PM

Quote from: p3yot33at3r on October 15, 2015, 02:21:52 PM

Edit: Just flashed it & queue is set at 8192 Tongue

Searching for the parameters now to change it............

Edit 1: OK, changed the queue setting to 1 for testing. BEWARE: This firmware does not submit stale shares - I noticed the "no-submit-stale" parameter in the /etc/init.d/cgminer.sh file (line 69), so I deleted it as it is my understanding that the default cgminer setting will submit stales - very important for p2pool......I'll monitor it & report back later.

Bummer. I'm pretty sure that not submitting stale shares is true for the default Bitmain firmware as well, though.

Be aware that the bitmain fork also intercepts stale work and drops it inside their driver code - before the main cgminer engine gets to see it and decide based on the command line options.
... as can be seen in their fork here:
https://github.com/bitmaintech/cgminer/blob/master/driver-bitmain.c#L1274

Bloody hell. Why bitmain, why? Cheesy

Right, so what I need to do is replace the bitmain bork binary with the ck one at http://ck.kolivas.org/apps/cgminer/antminer/s5/ & drop it in /config/ in order to make it permanent after reboots - amiright? If so, I might need a little help with the commands on this one...... Tongue

(linux amateur I am)

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: jtoomim on October 15, 2015, 06:53:17 PM

Quote from: p3yot33at3r on October 15, 2015, 02:21:52 PM

Edit: Just flashed it & queue is set at 8192 Tongue

Searching for the parameters now to change it............

Edit 1: OK, changed the queue setting to 1 for testing. BEWARE: This firmware does not submit stale shares - I noticed the "no-submit-stale" parameter in the /etc/init.d/cgminer.sh file (line 69), so I deleted it as it is my understanding that the default cgminer setting will submit stales - very important for p2pool......I'll monitor it & report back later.

Bummer. I'm pretty sure that not submitting stale shares is true for the default Bitmain firmware as well, though.

Be aware that the bitmain fork also intercepts stale work and drops it inside their driver code - before the main cgminer engine gets to see it and decide based on the command line options.
... as can be seen in their fork here:
https://github.com/bitmaintech/cgminer/blob/master/driver-bitmain.c#L1274

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Quote from: jtoomim on October 15, 2015, 06:53:17 PM

Quote from: p3yot33at3r on October 15, 2015, 02:21:52 PM

Edit: Just flashed it & queue is set at 8192 Tongue

Searching for the parameters now to change it............

Edit 1: OK, changed the queue setting to 1 for testing. BEWARE: This firmware does not submit stale shares - I noticed the "no-submit-stale" parameter in the /etc/init.d/cgminer.sh file (line 69), so I deleted it as it is my understanding that the default cgminer setting will submit stales - very important for p2pool......I'll monitor it & report back later.

Bummer. I'm pretty sure that not submitting stale shares is true for the default Bitmain firmware as well, though.

Yes, it is Sad

After running a couple of hours I noticed the load was much lower with the smit firmware (down from ~2.6 to ~0.7!), making the GUI much more responsive, but the hash rate was very slightly lower. I changed the queue setting of 1 to 0 for a while & my DOA rate has reduced nicely (not that it was high anyway) with hardly any spikes - so I'm going to run it overnight & check it again in the morning. Very happy with the lower load readings though.

Edit: If the results are OK in the morning I'll do a reboot to make sure the settings keep - if they do then it's all good & I'll update my other S5's

jtoomim

hero member

Activity: 818

Merit: 1006

Quote from: p3yot33at3r on October 15, 2015, 02:21:52 PM

Edit: Just flashed it & queue is set at 8192 Tongue

Searching for the parameters now to change it............

Edit 1: OK, changed the queue setting to 1 for testing. BEWARE: This firmware does not submit stale shares - I noticed the "no-submit-stale" parameter in the /etc/init.d/cgminer.sh file (line 69), so I deleted it as it is my understanding that the default cgminer setting will submit stales - very important for p2pool......I'll monitor it & report back later.

Bummer. I'm pretty sure that not submitting stale shares is true for the default Bitmain firmware as well, though.

Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 138. (Read 2591920 times)