Quote from: luthermarcus on February 20, 2016, 01:46:08 AM

Quote from: jtoomim on February 19, 2016, 11:35:15 PM

There appears to be an issue with p2pool producing lots of orphaned shares if the blocksize is greater than about 750 kB. This is caused by the limit on the number of transactions per share being too low.

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

As Bitcoin Classic sets the default block size limit to the largest allowed by the consensus rules, this can result in Bitcoin Classic nodes failing to produce valid shares. Consequently, if you run Bitcoin Classic with p2pool, you should use blockmaxsize=750000 or lower in your ~/.bitcoin/bitcoin.conf.

In the case of blockmaxsize=1000000, I was testing this earlier but have a small data set so far. I'm running bitcoin 0.12.( I recommend this bitcoin 0.12.0 for p2pool users who have high getblocktemp latency. It reduced mine under 1s which was not the case before and keeps it steady.) My first attempt like the man says there is a problem. Stale rate shot up almost 100% effective rate was (0-38%). It also stagnated payout marginally but i caught the issue because i was keeping an eye on it and acted swiftly so i don't know how much it would have impacted payout in the long run. I though it was bitcoin issue though so i changed some parameters.

blockmaxsize=1000000
mintxfee=0.00001
minrelaytxfee=0.00001
maxuploadtarget=144 (I just threw this in but im testing it with max connections so I don't know how effective it is alone.)
maxconnections=20 (Was around 45 when bitcoin started to act up and p2pool started to loss connection.

Things seem good now but something worth mentioning is that p2pool is now relatively synced. Which wasn't the case before.
P2pool was lossing connection to bitcoin so i added -maxconnections and to keep latency down more -maxuploadtarget at lowest recommended levels by developers(144). Which i think could be lower but would hurt the community by slowing down nodes from syncing from what i read.

Other parameters of interest
-maxmempool=      Keep the transaction memory pool below megabytes (default: 300)
-maxreceivebuffer= Maximum per-connection receive buffer, *1000 bytes (default: 5000)
-maxsendbuffer=      Maximum per-connection send buffer, *1000 bytes (default: 1000)
-bytespersigop      Minimum bytes per sigop in transactions we relay and mine (default: 20)
-datacarrier      Relay and mine data carrier transactions (default: 1)
-datacarriersize      Maximum size of data in data carrier transactions we relay and mine (default: 83)

I'll update my findings once i have some more data. Any info on above parameters would be helpful.

I have successfully ran p2pool with no issues for a day using those settings mentioned above. This was tested with 5 TH. I'm not sure if there is anything in the code preventing use of the whole 1MB but my node was stable with minimal stale rates and minimal orphans. It was pulling shares fine and my income steadily increased and stayed where i expected it to sometimes climbing even higher than what would normally be with default settings. This is on a older machine running 8 gb of ram and Intel® Core™2 Quad CPU Q6700 @ 2.66GHz × 4. I would love to stay on p2pool but the variance at the moment is killing me because I was goxed or crypted by cryptsy im behind on my electric bill I will return when im caught up.