How frequently are blocks being checkpointed currently?
Can we leave some space to allow for reorganizations to occur, say one checkpoint every 10 blocks maximum?
Topic: [ANN] [PPC] PPCoin Released! - First Long-Term Energy-Efficient Crypto-Currency - page 116. (Read 684864 times)
October 27, 2012, 09:01:15 AM
October 27, 2012, 08:20:04 AM
Sorry for the slight tangent. I was wondering how one actually generates a PoS block? Is the requirement just to leave your client running all the time? It is an interesting concept, good luck.
October 26, 2012, 06:44:55 PM
im pretty sure, that it's to do with getwork call, when a new block is found.
Does it show up if you hack the client to not check the hash on blocks and to assume every submission is correct (running on a private testnet of course). This should help find it faster. 
October 26, 2012, 07:05:23 AM
It's defo not sendtoaddress or getmemorypool.
getblockcount is normally used to decide if to throw out a LP, or if cached "getworks" are valid (in some pool software)
im pretty sure, that it's to do with getwork call, when a new block is found.
getblockcount is normally used to decide if to throw out a LP, or if cached "getworks" are valid (in some pool software)
im pretty sure, that it's to do with getwork call, when a new block is found.
October 26, 2012, 05:59:39 AM
I prepared list of rpc methods pool calls:
getwork
getblockcount
gettransaction
getdifficulty
I use getwork, getdifficulty, sendtoaddress and getmemorypool. getwork
getblockcount
gettransaction
getdifficulty
October 26, 2012, 04:23:05 AM
Andy I seem to remember you were testing with some pool software earlier and also observed memory leak issue. Is there a simple way for me to set up a pool software and reproduce this situation? Can you all (Chris, coinotron, Andy) confirm my observations? How fast is ppcoind leaking memory in your production system? Is the leak speed roughly proportional to the number of getwork requests?
It does seem proportional to the getwork requests. When my pool hashrate was greater than 100Ghash it was losing 1GB of memory a day. Now that it's low I only need to restart the ppcoind once a week or so when it reaches 4-5GB of memory.I confirm. Relation to the total pool speed seems to be proportional.
I prepared list of rpc methods pool calls:
getwork
getblockcount
gettransaction
getdifficulty
October 25, 2012, 05:51:48 PM
Andy I seem to remember you were testing with some pool software earlier and also observed memory leak issue. Is there a simple way for me to set up a pool software and reproduce this situation? Can you all (Chris, coinotron, Andy) confirm my observations? How fast is ppcoind leaking memory in your production system? Is the leak speed roughly proportional to the number of getwork requests?
It does seem proportional to the getwork requests. When my pool hashrate was greater than 100Ghash it was losing 1GB of memory a day. Now that it's low I only need to restart the ppcoind once a week or so when it reaches 4-5GB of memory. October 25, 2012, 05:05:00 PM
Didnt check if it was proportional to generate or getwork, as, hard to tell which - could even be to "mature", but I observed it as per below, prior to "mature" being reached.
I was running a private pool for a while yes, I could set it up again, but the pool software wasnt the problem - I replicated the leaks with valgrind with just ppcoind on testnet, with a single GPU.
If I pull out the valgrind logs / dumps for testnet on mining say 5 blocks, and again on 50 blocks, will it be of any use?
I was running a private pool for a while yes, I could set it up again, but the pool software wasnt the problem - I replicated the leaks with valgrind with just ppcoind on testnet, with a single GPU.
If I pull out the valgrind logs / dumps for testnet on mining say 5 blocks, and again on 50 blocks, will it be of any use?
Dunno I feel there is quite a bit noise in the valgrind report. After generating ~100 blocks on my testnet node I got 3KB definitely lost, 6KB indirectly lost and 1KB possibly lost. And the stacks don't look plausible at causing GB range leak problems. It would most definitely help to have a reproducible setup where large amount of memory is known to have leaked.
OK I'll leave it mining on testnet tomorrow for a good few hours. I have a good hashrate I can throw at it.
October 25, 2012, 04:52:34 PM
Didnt check if it was proportional to generate or getwork, as, hard to tell which - could even be to "mature", but I observed it as per below, prior to "mature" being reached.
I was running a private pool for a while yes, I could set it up again, but the pool software wasnt the problem - I replicated the leaks with valgrind with just ppcoind on testnet, with a single GPU.
If I pull out the valgrind logs / dumps for testnet on mining say 5 blocks, and again on 50 blocks, will it be of any use?
I was running a private pool for a while yes, I could set it up again, but the pool software wasnt the problem - I replicated the leaks with valgrind with just ppcoind on testnet, with a single GPU.
If I pull out the valgrind logs / dumps for testnet on mining say 5 blocks, and again on 50 blocks, will it be of any use?
Dunno I feel there is quite a bit noise in the valgrind report. After generating ~100 blocks on my testnet node I got 3KB definitely lost, 6KB indirectly lost and 1KB possibly lost. And the stacks don't look plausible at causing GB range leak problems. It would most definitely help to have a reproducible setup where large amount of memory is known to have leaked.
October 25, 2012, 04:09:46 PM
I tried valgrind on a testnet node with cgminer, but so far no luck finding useful clues.
Based on what I have heard so far, it seems this is related to getwork. Since a pool at most generate ~100 blocks a day, coinotron said he had to restart ppcoind once a day, I assume that ppcoind was eating >1gb a day, so this excludes the possibility the leak is related to valid blocks (each block taking about 10KB~100KB).
Now getwork does maintain a list of block candidates and a leak there could account for the rapid memory increase. I didn't change things related to allocation and delete of these block candidates and a code review there didn't reveal obvious problem either. I believe cs_main is also used to serialize getwork access so there shouldn't be concurrency issues with the block candidates.
Andy I seem to remember you were testing with some pool software earlier and also observed memory leak issue. Is there a simple way for me to set up a pool software and reproduce this situation? Can you all (Chris, coinotron, Andy) confirm my observations? How fast is ppcoind leaking memory in your production system? Is the leak speed roughly proportional to the number of getwork requests?
Thanks,
Based on what I have heard so far, it seems this is related to getwork. Since a pool at most generate ~100 blocks a day, coinotron said he had to restart ppcoind once a day, I assume that ppcoind was eating >1gb a day, so this excludes the possibility the leak is related to valid blocks (each block taking about 10KB~100KB).
Now getwork does maintain a list of block candidates and a leak there could account for the rapid memory increase. I didn't change things related to allocation and delete of these block candidates and a code review there didn't reveal obvious problem either. I believe cs_main is also used to serialize getwork access so there shouldn't be concurrency issues with the block candidates.
Andy I seem to remember you were testing with some pool software earlier and also observed memory leak issue. Is there a simple way for me to set up a pool software and reproduce this situation? Can you all (Chris, coinotron, Andy) confirm my observations? How fast is ppcoind leaking memory in your production system? Is the leak speed roughly proportional to the number of getwork requests?
Thanks,
Didnt check if it was proportional to generate or getwork, as, hard to tell which - could even be to "mature", but I observed it as per below, prior to "mature" being reached.
I was running a private pool for a while yes, I could set it up again, but the pool software wasnt the problem - I replicated the leaks with valgrind with just ppcoind on testnet, with a single GPU.
If I pull out the valgrind logs / dumps for testnet on mining say 5 blocks, and again on 50 blocks, will it be of any use?
October 25, 2012, 10:13:41 AM
I tried valgrind on a testnet node with cgminer, but so far no luck finding useful clues.
Based on what I have heard so far, it seems this is related to getwork. Since a pool at most generate ~100 blocks a day, coinotron said he had to restart ppcoind once a day, I assume that ppcoind was eating >1gb a day, so this excludes the possibility the leak is related to valid blocks (each block taking about 10KB~100KB).
Now getwork does maintain a list of block candidates and a leak there could account for the rapid memory increase. I didn't change things related to allocation and delete of these block candidates and a code review there didn't reveal obvious problem either. I believe cs_main is also used to serialize getwork access so there shouldn't be concurrency issues with the block candidates.
Andy I seem to remember you were testing with some pool software earlier and also observed memory leak issue. Is there a simple way for me to set up a pool software and reproduce this situation? Can you all (Chris, coinotron, Andy) confirm my observations? How fast is ppcoind leaking memory in your production system? Is the leak speed roughly proportional to the number of getwork requests?
Thanks,
Based on what I have heard so far, it seems this is related to getwork. Since a pool at most generate ~100 blocks a day, coinotron said he had to restart ppcoind once a day, I assume that ppcoind was eating >1gb a day, so this excludes the possibility the leak is related to valid blocks (each block taking about 10KB~100KB).
Now getwork does maintain a list of block candidates and a leak there could account for the rapid memory increase. I didn't change things related to allocation and delete of these block candidates and a code review there didn't reveal obvious problem either. I believe cs_main is also used to serialize getwork access so there shouldn't be concurrency issues with the block candidates.
Andy I seem to remember you were testing with some pool software earlier and also observed memory leak issue. Is there a simple way for me to set up a pool software and reproduce this situation? Can you all (Chris, coinotron, Andy) confirm my observations? How fast is ppcoind leaking memory in your production system? Is the leak speed roughly proportional to the number of getwork requests?
Thanks,
October 24, 2012, 03:54:54 PM
Wait...
... so if you get lucky and generate a POS block you lose control over those coins for 520 blocks?
What if I need those coins to pay somebody in the meantime? How fast are PPCoin blocks-- how long would I have to possibly wait?
... so if you get lucky and generate a POS block you lose control over those coins for 520 blocks?
What if I need those coins to pay somebody in the meantime? How fast are PPCoin blocks-- how long would I have to possibly wait?
From the FAQ:
Quote
Because stake is withheld from spending for 520 blocks, if you do need to keep your balance around to be spent soon we provided a configuration option 'reservebalance' to help you keep your balance from being used by stake. You can add a line 'reservebalance=10000' to ppcoin.conf and restart your ppcoind. This way ppcoind would try to keep your balance above 10000 coins when generating stakes.
October 24, 2012, 03:51:07 PM
Wait...
... so if you get lucky and generate a POS block you lose control over those coins for 520 blocks?
What if I need those coins to pay somebody in the meantime? How fast are PPCoin blocks-- how long would I have to possibly wait?
... so if you get lucky and generate a POS block you lose control over those coins for 520 blocks?
What if I need those coins to pay somebody in the meantime? How fast are PPCoin blocks-- how long would I have to possibly wait?
If you assume a PPC block takes 10 minutes then you would need to wait 5200 minutes or about 3 days.
October 24, 2012, 03:49:34 PM
Wait...
... so if you get lucky and generate a POS block you lose control over those coins for 520 blocks?
What if I need those coins to pay somebody in the meantime? How fast are PPCoin blocks-- how long would I have to possibly wait?
... so if you get lucky and generate a POS block you lose control over those coins for 520 blocks?
What if I need those coins to pay somebody in the meantime? How fast are PPCoin blocks-- how long would I have to possibly wait?
October 24, 2012, 10:48:04 AM
Hi Volksholk,
Yeah I can confirm what dreamwatcher said. I'll see if I can add some quick fix in the next release (no plan on full support of gui still). But mostly looking forward to dreamwatcher's improved gui with explorer functionality.
Yeah I can confirm what dreamwatcher said. I'll see if I can add some quick fix in the next release (no plan on full support of gui still). But mostly looking forward to dreamwatcher's improved gui with explorer functionality.
October 24, 2012, 10:41:14 AM
Vorksholk,
It appears you have have mined (Generated) a POS block.
This is natural behavior that unfortunately the converted QT client does not recognize.
If you use a command line "getinfo" you should those coins under "Stake". After 520 confirms the coins will be returned to balance.
I am currently working on a PPC GUI client that will be fully setup for PPC. The client will know what a POS generation is and report it appropriately.
It may be a little bit before it is ready as I am writing from the ground up, recycling some code from other clients.
See my thread at:
https://bitcointalksearch.org/topic/locked-ppc-block-explorer-please-use-the-new-cryptocoinexplorer-thread-112972
for more info and to put some suggestions in, I am really in need of feedback on what users want from the new client.
It appears you have have mined (Generated) a POS block.
This is natural behavior that unfortunately the converted QT client does not recognize.
If you use a command line "getinfo" you should those coins under "Stake". After 520 confirms the coins will be returned to balance.
I am currently working on a PPC GUI client that will be fully setup for PPC. The client will know what a POS generation is and report it appropriately.
It may be a little bit before it is ready as I am writing from the ground up, recycling some code from other clients.
See my thread at:
https://bitcointalksearch.org/topic/locked-ppc-block-explorer-please-use-the-new-cryptocoinexplorer-thread-112972
for more info and to put some suggestions in, I am really in need of feedback on what users want from the new client.
Awesome, thanks for the response!
October 24, 2012, 10:38:52 AM
Vorksholk,
It appears you have have mined (Generated) a POS block.
This is natural behavior that unfortunately the converted QT client does not recognize.
If you use a command line "getinfo" you should see those coins under "Stake". After 520 confirms the coins will be returned to balance.
I am currently working on a PPC GUI client that will be fully setup for PPC. The client will know what a POS generation is and report it appropriately.
It may be a little bit before it is ready as I am writing from the ground up, recycling some code from other clients.
See my thread at:
https://bitcointalksearch.org/topic/locked-ppc-block-explorer-please-use-the-new-cryptocoinexplorer-thread-112972
for more info and to put some suggestions in, I am really in need of feedback on what users want from the new client.
It appears you have have mined (Generated) a POS block.
This is natural behavior that unfortunately the converted QT client does not recognize.
If you use a command line "getinfo" you should see those coins under "Stake". After 520 confirms the coins will be returned to balance.
I am currently working on a PPC GUI client that will be fully setup for PPC. The client will know what a POS generation is and report it appropriately.
It may be a little bit before it is ready as I am writing from the ground up, recycling some code from other clients.
See my thread at:
https://bitcointalksearch.org/topic/locked-ppc-block-explorer-please-use-the-new-cryptocoinexplorer-thread-112972
for more info and to put some suggestions in, I am really in need of feedback on what users want from the new client.
October 24, 2012, 10:15:55 AM
Hey, I'm having a small glitch with my PPC Wallet...
shows an odd transaction, and when I look up the TxID...:
Apparently wallet sent itself over 5000 coins and didn't realize?
Anyone else have this issue, or does anyone have ideas for a solution? I tried restarting wallet, but to no avail.
shows an odd transaction, and when I look up the TxID...:Apparently wallet sent itself over 5000 coins and didn't realize?
Anyone else have this issue, or does anyone have ideas for a solution? I tried restarting wallet, but to no avail.
October 24, 2012, 02:55:55 AM
Can you run a miner? Steps that might reproduce:
* Set up a difficulty 1 ppcoind 'testnet in a box'
* Run the ppcoind instances under valgrind
* Mine a few blocks
* Check valgrind reports
* Set up a difficulty 1 ppcoind 'testnet in a box'
* Run the ppcoind instances under valgrind
* Mine a few blocks
* Check valgrind reports
Yeah that's what I plan to do first to see if I find anything. Thanks,
I think it's to do with something holding a ref to the newly minted block after signing it.
October 23, 2012, 08:32:57 PM
Can you run a miner? Steps that might reproduce:
* Set up a difficulty 1 ppcoind 'testnet in a box'
* Run the ppcoind instances under valgrind
* Mine a few blocks
* Check valgrind reports
* Set up a difficulty 1 ppcoind 'testnet in a box'
* Run the ppcoind instances under valgrind
* Mine a few blocks
* Check valgrind reports
Yeah that's what I plan to do first to see if I find anything. Thanks,
Jump to: