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

Hi community, I have a instance of p2pool running on windows.  I used the latest git available via forestv.  The pool has been running all night, over 12 hours but when I submit a share to it, it doesn't contain any additional transaction fees in the share.  How does p2pool include the transaction fees in shares, and what am I missing to have them included in mine.  I have also followed the p2pool tuning post and have the min-max tx fees included in the bitcoin.conf file as well as server=1.  Any other tips before I move the node to a Linux install to see if that corrects the issue.  It should be also noted that im running the bitcoin-qt gui and mining the pool against that, perhaps I need to run the daemon? but no information on the web to say the gui client is limited vs the bitcoind.exe.  

Yes that will run p2pool very nicely (don't forget SSD for bitcoin latency).

Pentium G2358 and overclock the snot out of it.   Two Haswell cores running at 3.7GHz or more should be able to do it, surely?

I was thinking, how to "pull  back" small miners (all miners?) to P2Pool and this is some assumptions for new version of share chain:
- we have 3-5 separate share chains
- each chain has own min and max share power/diff (let say sc1 is from 1k to 10k, sc2 11k-100k, 101k-1M etc)
- each share have flag, that tells it is already used/paid or not
- when user find a share in one of lower chains, earlier share is marked as used and power of new share and old share is summarized (we can`t pay from lowest chain directly because of dust threshold) 
- once power or his share reach chain threshold he need to find one stronger share to bump it to higher chain till it reach one that can be paid
- each miner (payout address) starts in highest chain for 1-10 mins that node can recognize its hash rate and select proper chain/diff for him
- goal is, that every miner found share every 1/10 -1/2 block ETA time

Pros:
- share chain length can be reduced because of "summing" thing, every miner can/need have 2 active shares in each chain, no more need
- no more "wasted work" when block time exceeds share chain length - new share sum power of last share and current, oldest share can be removed from payout computations
- virtually any miner can mine
- big miners are in high power chains that small miners can easily participate in mining

Cons:
- more P2P data overhead (more chains to transmit)
- more CPU overhead: more data to analyze to create payout tx, more job to be done when share found


Sadly, I`m too small in Python tot try implement that.

@forrestv: can this work? B-)

For p2pool yes, for bitcoind no. Yes I know, the pain... 

So, the E8400 (2x3GHz) I took out of the machine would have been better than the Q6700 (4x2.66GHz) I put in.  Humph.  I forgot about the whole single threadedness of p2pool.

Remember what single core machines do when you throw too many simultaneous requests at the OS; they slow down in response to the point where you can notice the CPU interrupts as a flicker in your hourglass-locked mouse pointer. Now recall that machines with multicore CPUs never behave that way when given multiple different tasks, and also that you haven't seen an hourglass mouse pointer since the day you ditched your last single core machine

People approach me for driver/mining/pool/software solutions based on what I've been providing online, I just don't really advertise it as such. Said p2pool deployment was delayed a couple of days, but it's still planned.

Ah.  I see your point.

M

That's pretending to be one guest core by serialising from one host core to another (i.e. jumping around). There is no way to parallelise serial work.

I say that because I'm pretty sure I've seen a single threaded VM with high CPU usage, yet the underlying OS has low CPU usage spread across multiple threads.

M

I find using niceness helps on Ubuntu too, -10 for both python & Bitcoind......

Only outright core speed matters since p2pool is in python which is single threaded. The faster the cores are the better. Having many cores does nothing as there is no way to "add them up". In fact, on an otherwise lightly loaded system, if you have a hyperthread CPU, disabling hyperthread in the BIOS will speed up python.

Would running it in a VM with 1 thread help?  I've often theorized that a VM with 1 thread on a multicore machine performs better than on the multicore machine, as those multiple threads are used to run the "one" thread in the VM.

But I never actually tried it.

M

If you have tons of clients hashing at high hashrates, run several p2pool instances and load-balance with iptables or something.

Can't see it happening tbh. I can't see Bitmain keeping their promise about doing something with it either......

Looking forward to someone rewriting p2pool, I was running it earlier on a Q6700, and was getting terrible latency - one core was flat out.   Single threaded .exe sucks.  A Core2Quad 2.66GHz with 6GB RAM should be able to totally maul p2pool.

Where do you keep finding them?........

All going well I'm going to be helping drop the biggest mine onto p2pool yet over the next day. Watch for it 

Grats!

M