I'm using the new one.
Mainly because I didn't like the error displayed by the old one, but I'm pretty sure they both work fine.
Topic: [ANN][YAC][POOL]p2pool for yacoin!! - page 6. (Read 28197 times)
Well i don't really know how to do a diff, but basically....
yacoin=math.Object(
PARENT=networks.nets['yacoin'],
SHARE_PERIOD=15, # seconds
CHAIN_LENGTH=24*60*60//15, # shares ****Changed this***
REAL_CHAIN_LENGTH=24*60*60//15, # shares ****And this****
TARGET_LOOKBEHIND=200, # shares
SPREAD=3, # blocks
IDENTIFIER='c138e5b9e7923514'.decode('hex'),
PREFIX='d206c3a24ee749b4'.decode('hex'),
P2P_PORT=12589, *****And this*****
MIN_TARGET=0,
MAX_TARGET=2**256//2**20 - 1,
PERSIST=False,
WORKER_PORT=8336,
BOOTSTRAP_ADDRS='bitvolcano.com'.split(' '),
ANNOUNCE_CHANNEL='#p2pool-alt',
And that was it!
yacoin=math.Object(
PARENT=networks.nets['yacoin'],
SHARE_PERIOD=15, # seconds
CHAIN_LENGTH=24*60*60//15, # shares ****Changed this***
REAL_CHAIN_LENGTH=24*60*60//15, # shares ****And this****
TARGET_LOOKBEHIND=200, # shares
SPREAD=3, # blocks
IDENTIFIER='c138e5b9e7923514'.decode('hex'),
PREFIX='d206c3a24ee749b4'.decode('hex'),
P2P_PORT=12589, *****And this*****
MIN_TARGET=0,
MAX_TARGET=2**256//2**20 - 1,
PERSIST=False,
WORKER_PORT=8336,
BOOTSTRAP_ADDRS='bitvolcano.com'.split(' '),
ANNOUNCE_CHANNEL='#p2pool-alt',
And that was it!
i just rebooted my pool with your new network.py code. seems better it's been up for about 20 mins so far i'll let you know in a few hours.
p2pool.dsync.net:21111
which yacoind are you using? orginal or the alternate one. does it matter?
Well, this change really improves memory usage and pool efficiency.
So everybody please make the change as described above and join.
BRING ALL THE HASHES !
So everybody please make the change as described above and join.
BRING ALL THE HASHES !
Well i don't really know how to do a diff, but basically....
yacoin=math.Object(
PARENT=networks.nets['yacoin'],
SHARE_PERIOD=15, # seconds
CHAIN_LENGTH=24*60*60//15, # shares ****Changed this***
REAL_CHAIN_LENGTH=24*60*60//15, # shares ****And this****
TARGET_LOOKBEHIND=200, # shares
SPREAD=3, # blocks
IDENTIFIER='c138e5b9e7923514'.decode('hex'),
PREFIX='d206c3a24ee749b4'.decode('hex'),
P2P_PORT=12589, *****And this*****
MIN_TARGET=0,
MAX_TARGET=2**256//2**20 - 1,
PERSIST=False,
WORKER_PORT=8336,
BOOTSTRAP_ADDRS='bitvolcano.com'.split(' '), *****And this*****
ANNOUNCE_CHANNEL='#p2pool-alt',
And that was it!
yacoin=math.Object(
PARENT=networks.nets['yacoin'],
SHARE_PERIOD=15, # seconds
CHAIN_LENGTH=24*60*60//15, # shares ****Changed this***
REAL_CHAIN_LENGTH=24*60*60//15, # shares ****And this****
TARGET_LOOKBEHIND=200, # shares
SPREAD=3, # blocks
IDENTIFIER='c138e5b9e7923514'.decode('hex'),
PREFIX='d206c3a24ee749b4'.decode('hex'),
P2P_PORT=12589, *****And this*****
MIN_TARGET=0,
MAX_TARGET=2**256//2**20 - 1,
PERSIST=False,
WORKER_PORT=8336,
BOOTSTRAP_ADDRS='bitvolcano.com'.split(' '), *****And this*****
ANNOUNCE_CHANNEL='#p2pool-alt',
And that was it!
Great news, can you provide a diff from the github version ?
It would be much easier to review and deploy.
It would be much easier to review and deploy.
OK since nobody else did, I've changed my yacoin p2pool from 3 second shares to 15 second shares.
So far I'm seeing much reduced memory usage and far lower DOA.
Thanks for the suggestion rav3n.
For anyone who'd like to join me there is a copy of the modified code at http://ubuntuone.com/7lPJXOr1bUk8cxSTRbmNWh
Open port 12589 to the server running p2pool.
Mining is to port 8336 as before.
Or just join me by pointing hashes to http://bitvolcano.com:8336 with a YAC address as username.
So far I'm seeing much reduced memory usage and far lower DOA.
Thanks for the suggestion rav3n.
For anyone who'd like to join me there is a copy of the modified code at http://ubuntuone.com/7lPJXOr1bUk8cxSTRbmNWh
Open port 12589 to the server running p2pool.
Mining is to port 8336 as before.
Or just join me by pointing hashes to http://bitvolcano.com:8336 with a YAC address as username.
24*60*60/3=28`800 shares in 24hr chain.
Lots of data to process.
In BTC there is 8`640 shares in 24h chain (10s longpool). In TRC only 2`880 (30s longpool).
Thats why YAC node eats lots of ram and CPU.
What would appropriate settings be?Lots of data to process.
In BTC there is 8`640 shares in 24h chain (10s longpool). In TRC only 2`880 (30s longpool).
Thats why YAC node eats lots of ram and CPU.
I want to fix this but really don't know where to start.
24*60*60/3=28`800 shares in 24hr chain.
Lots of data to process.
In BTC there is 8`640 shares in 24h chain (10s longpool). In TRC only 2`880 (30s longpool).
Thats why YAC node eats lots of ram and CPU.
Lots of data to process.
In BTC there is 8`640 shares in 24h chain (10s longpool). In TRC only 2`880 (30s longpool).
Thats why YAC node eats lots of ram and CPU.
I've restarted the server and wiped the data folder again, shouldn't have done the latter as its just resulted in 12 hours of 100% CPU use and dead shares
12h of dead shares and 100% usage ? What's your setup ?Its a 2GB VPS with a top line host. If I just restart the pool, it's fine after a minute or two, but if I wipe the data folder it spends a lot of time doing the 100% CPU load thing while it figures out wtf is going on. Presume its just catching up on all of the share history I just binned..
I've restarted the server and wiped the data folder again, shouldn't have done the latter as its just resulted in 12 hours of 100% CPU use and dead shares
12h of dead shares and 100% usage ? What's your setup ?Since I am on low RAM and the python process gets killed randomly after some hours of usage I have a script that restarts it after wiping the data dir (I have to do it since otherwise the pool hangs loading shares). The result is some dead shares and orphans but it recovers in less than an hour and also CPU usage is not 100% when the python process restarts.
Also people should take into account that latency is important in p2pool mining so you should choose a node near you.
Apologies to everyone who has been using my node. I've been away for a few days with less access than usual to my desktop and remote machines.
I've restarted the server and wiped the data folder again, shouldn't have done the latter as its just resulted in 12 hours of 100% CPU use and dead shares
Hopefully we're past that now and the efficiency will climb back up over the next 12-24 hours.
I've restarted the server and wiped the data folder again, shouldn't have done the latter as its just resulted in 12 hours of 100% CPU use and dead shares
Hopefully we're past that now and the efficiency will climb back up over the next 12-24 hours. 
It need change in entire pool, becuse it will change payout strategy.
i just want to say thanks for your implimentation of p2pool to YAC
i made a node @ http://84.200.240.198:8336 no fee
ive been using ur nodes for about 20 days now and i like it but they seem to suffer when one gets crowded
so im interested in your ideas on how you will edit it and will be willing to test it with you
i can't run windows binary on win2008(64bit) server... it shows me some error..
I guess the "some" part is important here ....
Lol. Isn't "some" error fixed with the "any" key?
i can't run windows binary on win2008(64bit) server... it shows me some error..
I guess the "some" part is important here ....
i can't run windows binary on win2008(64bit) server... it shows me some error..
It need change in entire pool, becuse it will change payout strategy.
Yeah I know, I was kinda hoping the other pool owners would chime in too!
It need change in entire pool, becuse it will change payout strategy.
On 3 seconds longpool 24h chain is HUGE. Blocks are popping every hour or even less, we should consider shorten the chain to 10 or even 8hrs.
This will make pool memory consumption much lower.
If you know how to make this happen I'd be glad to modify my node. This will make pool memory consumption much lower.
On 3 seconds longpool 24h chain is HUGE. Blocks are popping every hour or even less, we should consider shorten the chain to 10 or even 8hrs.
This will make pool memory consumption much lower.
This will make pool memory consumption much lower.
Looks that way. Probably ran into the dreaded memory leak again.
Jump to: