Memory usage looks promising
It is at 75MB atm. After previous restarts ppcoind quickly reached 300-400MB. 
Topic: CryptoCoin Explorer - Coin Block Explorers. - page 21. (Read 30817 times)
I restarted ppcoind 5 hours ago with maxconnections=8.
Memory usage looks promising It is at 75MB atm. After previous restarts ppcoind quickly reached 300-400MB.
Memory usage looks promising
It is at 75MB atm. After previous restarts ppcoind quickly reached 300-400MB.
Just an update, as of now the ppcoin daemon has only crept up to 3.9% of the memory whereas normally at this point it would be around 7% and most likely shutdown.
So the max connections set at 8, at the very least, appears to solve the issue with my particular use of the daemon.
So the max connections set at 8, at the very least, appears to solve the issue with my particular use of the daemon.
Good to know. I will try it on next PPC restart.
ATM my workaround is to increase share difficulty. This decreases number of RPC getwork calls. It helped me to extend time span between restarts to 3 days.
ATM my workaround is to increase share difficulty. This decreases number of RPC getwork calls. It helped me to extend time span between restarts to 3 days.
Thank you for your support Coinotron.
Just a quick observation for Sunny and the pool operators:
I set maxconnections to 8 and I have noticed a significant drop in the memory usage creep. The PPC daemon has only increased to 3.8% since I made the max Connections change and rebooted the daemon.
Normally I would have went from about 3.4% at reboot, to around 5% memory usage in that same period of time.
Hopefully this observation will help the pool operators and get Sunny one step closer to squashing this bug.
Just a quick observation for Sunny and the pool operators:
I set maxconnections to 8 and I have noticed a significant drop in the memory usage creep. The PPC daemon has only increased to 3.8% since I made the max Connections change and rebooted the daemon.
Normally I would have went from about 3.4% at reboot, to around 5% memory usage in that same period of time.
Hopefully this observation will help the pool operators and get Sunny one step closer to squashing this bug.
I've added links from Coinotron's Statistics page, Solved TRC blocks to CRYPTOCOINEXPLORER.COM.
PS
Thanks for running this site.
200 TRC donation sent to your account
PS
Thanks for running this site.
200 TRC donation sent to your account
If genesis block generated 50 TRC than value for "Outstanding" is 20 TRC less than total amount of coins generated.
http://www.cryptocoinexplorer.com:3750/chain/Terracoin?hi=19&count=20
Extra work = rename "Outstanding" to something more appropriate, like "Total coins"?
http://www.cryptocoinexplorer.com:3750/chain/Terracoin?hi=19&count=20
Extra work = rename "Outstanding" to something more appropriate, like "Total coins"?
Fixed. The amount discrepancy was a small last minute change that slipped placement in the live server code on the last code update.
After reviewing the blockexplorer.com, I see they changed the default label to "Total BTC", so I have changed the label to "Total TRC" on the TRC explorer.
I will fix the label on the PPC Explorer as well.
Thank you for bringing it up.
I will look into the search feature of the PPCoin explorer, it is based on a older version of ABE that had to be altered significantly to accommodate PPC. As of now this issue is second in line for examination, top of the list is the strange shutdowns of the PPCoin daemon that seem to be occurring. I am not seeing a huge memory leak yet, but it appears to be shutting down at random with no core dump files. Possibly still a memory issue, but I am monitoring process CPU/memory usage to try and catch the issue.
Get-work may be part of it, but be aware that PPC explorer is also experiencing creeping memory leakage.
For example after restart and catch up last night ,ppcoind was using about 3.4% of the memory. Overnight it has creeped up to around 6% of the memory.
Just letting you know to keep that in mind.
For example after restart and catch up last night ,ppcoind was using about 3.4% of the memory. Overnight it has creeped up to around 6% of the memory.
Just letting you know to keep that in mind.
Please try keep an eye on the memory utilization and the pattern of its growth. I did sporadically experience swap errors and os shutdowns on the seed nodes as well which are running on some type of hosted virtual machines. Although I cannot confirm whether it's caused by memory exhaustion of ppcoin.
Other nodes I have seem to be running quite stable though.
Before I rebooted the server tonight, the usage was up to 7%.
My guess is that an object that both Get work and the routine the daemon uses to stay current may be the culprit.
I will look at the PPC code to add an extra pair of eyes searching for it.
I have spent about 30-40 hours on the I0coin code trying to figure out its similar issue and have really just come out with more questions than answers.
How much, if any, does PPC daemon memory cache in terms of TX or even blocks?
The Bitcoin Daemon also used a large amount of memory until the latest releases, I believe there was a change in the database among a couple of other things that drastically lowered its memory footprint. Perhaps looking at the latest code might spark some ideas.
The PPC Explorer has been upgraded
I have applied the previous modifications and some new modifications to the current version ABE to bring PPC explorer up to date.
Integrating and changing the newest version of ABE with the PPC modifications made more sense then patching the explorer based on an old version of ABE.
The above mentioned issue with the server error has been fixed, and I have cleaned up some of the display formats. For example, limiting difficulty display to 2 decimal places.
I will look into the search feature of the PPCoin explorer, it is based on a older version of ABE that had to be altered significantly to accommodate PPC. As of now this issue is second in line for examination, top of the list is the strange shutdowns of the PPCoin daemon that seem to be occurring. I am not seeing a huge memory leak yet, but it appears to be shutting down at random with no core dump files. Possibly still a memory issue, but I am monitoring process CPU/memory usage to try and catch the issue.
Get-work may be part of it, but be aware that PPC explorer is also experiencing creeping memory leakage.
For example after restart and catch up last night ,ppcoind was using about 3.4% of the memory. Overnight it has creeped up to around 6% of the memory.
Just letting you know to keep that in mind.
For example after restart and catch up last night ,ppcoind was using about 3.4% of the memory. Overnight it has creeped up to around 6% of the memory.
Just letting you know to keep that in mind.
Please try keep an eye on the memory utilization and the pattern of its growth. I did sporadically experience swap errors and os shutdowns on the seed nodes as well which are running on some type of hosted virtual machines. Although I cannot confirm whether it's caused by memory exhaustion of ppcoin.
Other nodes I have seem to be running quite stable though.
Please keep giving me feedback, and thank you for pointing out the issues.
I might be wrong, but block numbers go from 0 to X and height goes from 1 to X+1. In other words, genesis block height is 1, not 0.
Attempting to check first 20 blocks for PPC results in server error:
http://www.cryptocoinexplorer.com:2750/chain/PPcoin?hi=19&count=20
Off topic, sort of - Any clue why LTC explorer frequently shows no address for newly generated coins?
http://explorer.litecoin.net/block/1e616de547a7624f818f53f575fa90b1a9d5d1048108b7fcfd81b7bd13af4b83
Genesis block height being 0 or 1 could be debated. Blockchain.info lists the height of the Genesis block as 0. Blockexplorer.com, which arguably is the largest implementation of ABE, does not list height.
ABE (which the block explorers on my site are based on) count it as 0. I never saw a big reason to change it, but if enough people feel it should be 1 I can look into changing it.
I will look into the search feature of the PPCoin explorer, it is based on a older version of ABE that had to be altered significantly to accommodate PPC. As of now this issue is second in line for examination, top of the list is the strange shutdowns of the PPCoin daemon that seem to be occurring. I am not seeing a huge memory leak yet, but it appears to be shutting down at random with no core dump files. Possibly still a memory issue, but I am monitoring process CPU/memory usage to try and catch the issue.
As for LTC, that is a different beast altogether, I am glad somebody got the LTC explorer up again before I did.
OK,
Some quick patches to the Terracoin explorer have been applied. Hopefully this will solve the above mentioned issues.
Please keep giving me feedback, and thank you for pointing out the issues.
Some quick patches to the Terracoin explorer have been applied. Hopefully this will solve the above mentioned issues.
Please keep giving me feedback, and thank you for pointing out the issues.
thanks!
OK,
Some quick patches to the Terracoin explorer have been applied. Hopefully this will solve the above mentioned issues.
Please keep giving me feedback, and thank you for pointing out the issues.
Some quick patches to the Terracoin explorer have been applied. Hopefully this will solve the above mentioned issues.
Please keep giving me feedback, and thank you for pointing out the issues.
I still find it odd in the sense that it is different from the normal generation, as I would think that a coin base transaction would be uniform with a system that has constant value as a mining reward.
I guess the question is academic as the blocks are being accepted and the transaction does equal the 20 TRC reward.
I just had a quick look at official bitcoin wiki, and couldn't find an exact limit to the number of output addresses, only the total amount is written there.
Not sure if it must be strictly equal to the current awaited value, or if it could also be smaller (i guess not, that would break the whole economy magic i guess)
I am curious if this would be due to a modified client, or something inherit to the official client itself?
I think the poolmining software is probably responsible for the block construction, never heard about that kind of client modification, long ago, when i gave a try to eligius pool (as miners only interact with the pool's software ?).
There are probably mining pools that submit generated blocks to multiple remote nodes to ensure it's correctly spread, quickly. (p2pool maybe? just a wild guess, not sure)
The .99999 issue could be a rounding error or possibly due to odd blocks like:
http://www.cryptocoinexplorer.com:3750/block/0000000000050aa4ee9529721b046fb247df6b9ec4fada81d7a93c17d9186992
The raw transaction shows two generation transactions of 19.8 and .2 ??
http://www.cryptocoinexplorer.com:3750/block/0000000000050aa4ee9529721b046fb247df6b9ec4fada81d7a93c17d9186992
The raw transaction shows two generation transactions of 19.8 and .2 ??
This is one transaction, with 2 outputs, nothing wrong here i'd say.
(and ... i guess where those are coming from, that 19.8 number appears frequently at a given trc pool)
some pools even use the "generation" transaction to "pay" miners, if i remember right, eligius did (still do?) that earlier to distribute rewards to miners.
You are correct, I misspoke(typed?).
I still find it odd in the sense that it is different from the normal generation, as I would think that a coin base transaction would be uniform with a system that has constant value as a mining reward.
I am curious if this would be due to a modified client, or something inherit to the official client itself?
I guess the question is academic as the blocks are being accepted and the transaction does equal the 20 TRC reward.
The .99999 issue could be a rounding error or possibly due to odd blocks like:
http://www.cryptocoinexplorer.com:3750/block/0000000000050aa4ee9529721b046fb247df6b9ec4fada81d7a93c17d9186992
The raw transaction shows two generation transactions of 19.8 and .2 ??
http://www.cryptocoinexplorer.com:3750/block/0000000000050aa4ee9529721b046fb247df6b9ec4fada81d7a93c17d9186992
The raw transaction shows two generation transactions of 19.8 and .2 ??
This is one transaction, with 2 outputs, nothing wrong here i'd say.
(and ... i'd bet i know where those are coming from, that 19.8 number appears frequently at a given trc pool)
some pools even use the "generation" transaction to "pay" miners, if i remember right, eligius did (still do?) that earlier to distribute rewards to miners.
Code:
// Genesis block
const char* pszTimestamp = "June 4th 1978 - March 6th 2009 ; Rest In Peace, Stephanie.";
Is that in the Bitcoin Genesis block? That seems like a pretty good hint to start working on in figuring out who Satoshi was.
You mean Terracoin founder? Satoshi left different message in Bitcoin genesis block.
Anyway, coin explorer does not label orphaned blocks as such, it just lists them below next valid block, as can be seen here:
http://www.cryptocoinexplorer.com:3750/block/00000000002adf857a2e75a22345e72f1c97e08ada5da7426e25b5b3d0adcbc0
Block listed below "Next block" is it's orphan, e.g. both blocks are on height 18689. "Next block (Orphan)" label would be nice.
Another thing with coin explorer and Terracoins is "Coins created" cell = how come value for it does not ends with 0.0000 ?
I mean, genesis block added 50 TRC and all subsequent blocks added 20 TRC, so there is no way sum can have 9.999 at end.
I will look into the code to identify orphan blocks and fix the issue.
The .99999 issue could be a rounding error or possibly due to odd blocks like:
http://www.cryptocoinexplorer.com:3750/block/0000000000050aa4ee9529721b046fb247df6b9ec4fada81d7a93c17d9186992
The raw transaction shows two generation transactions of 19.8 and .2 ??
I will also look into and fix the code for that also.
Thank you for bringing these issues to my attention.
"he bitcoins in Genesis block are not spendable (but this did not prevent some well meaning halfbrains from sending additional coins to that address). But the private key for that genesis block exists (or at least existed) so Satoshi could prove his identity at any chosen moment if he wishes and if the key is not lost. I wonder if this is a bug or Satoshi was so bright to include this intentionally?"
Regarding the genesis block 'timestamp' sentence, i had a look earlier (while joining the network .. i'm curious
), it's a tribute ("RIP") message to a close (i guess).Edit: hop .. here it is, directly from the source
Code:
// Genesis block
const char* pszTimestamp = "June 4th 1978 - March 6th 2009 ; Rest In Peace, Stephanie.";
Is that in the Bitcoin Genesis block? That seems like a pretty good hint to start working on in figuring out who Satoshi was.
Thank you for all who have donated so far.
I have seen a growing number of thread/questions about various compiled versions of PPC and other Alt coins.
Would there be in interest in having the cryptocoinexplorer site host some of these files?
I would compile these myself, and I can compile just about anything. Although some programmers insistence on using libraries and headers that are Linux only can get a bit frustrating..
(I am looking at you resource.h header.. IF anybody knows how to get around this header during a Linux/Windows cross compile, let me know. It is probably something simple that would require a smack to my forehead)
I have seen a growing number of thread/questions about various compiled versions of PPC and other Alt coins.
Would there be in interest in having the cryptocoinexplorer site host some of these files?
I would compile these myself, and I can compile just about anything. Although some programmers insistence on using libraries and headers that are Linux only can get a bit frustrating..
(I am looking at you resource.h header.. IF anybody knows how to get around this header during a Linux/Windows cross compile, let me know. It is probably something simple that would require a smack to my forehead
)
Switchover is now complete.
Please see the OP for details.
Sent you 10 TRC thanks mate
Switchover is now complete.
Please see the OP for details.
Jump to: