jwinterm
Legendary
Offline
Activity: 3024
Merit: 1106
|
|
July 19, 2016, 09:04:33 PM |
|
OK, this isn't good.
CPU = 20-25% RAM = 1GB+ Merge mining broken.
I think I'll revert back to the older v9 client in order to get everything working again, as I'm seeing quite a few v9 clients still in use. Can someone tell me if I'll have to redownload the entire blockchain again - or can I use the one I'm using with v11?
Thanks.
I'm not sure merge mining is broken, see: http://insight-myr.cryptap.us/block/1bc76704452bae595989f60527519abcd9a718af6627a29aebe913844c4535a3This is a sha256d block, appears to be aux-pow, and a version 4 block. That should be on 0.11.3.1 The fork will be done via consensus, 75% v4 blocks after block 1764000. But v 0.9.x can be forked before that block, if 75% v4 consensus is met. edit: I'm keeping some status here: https://cryptap.us/myr/myrstat0.11.3.1 miners are v4 miners I think he was saying that merge mining using myriad as the parent coin on p2pool was broken, not the auxpow algos are broken. Could be wrong tho...
|
|
|
|
|
|
The forum strives to allow free discussion of any ideas. All policies are built around this principle. This doesn't mean you can post garbage, though: posts should actually contain ideas, and these ideas should be argued reasonably.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
IconFirm
|
|
July 19, 2016, 09:10:57 PM Last edit: July 20, 2016, 12:21:10 AM by IconFirm |
|
I use a few coins as the main chain: ZET, NEOS, TRC & XJO. Never had a problem up until v11. I'm compiling v9 again now... Edit: OK, I can confirm that when using the v9 client with p2pool merge mining I am once again seeing: 2016-07-20 00:03:21 ProcessBlock: ACCEPTED 2016-07-20 00:03:22 CreateNewBlock(): total size 1000 in my debug log, meaning everything is working fine again. Also, CPU usage is minimal & RAM usage is ~700mb, so everything is as it was again. Whatever changes were made to XMY between v9 & v11 seem to have broken merge mining & increased resourse usage dramatically. At the risk of losing many miners & network hash rate/security - I would respectfully urge the devs to cancel the fork until the problem is resolved. I can supply any logs needed. Merge mining is one of the many things that make XMY a great coin - to suddenly & needlessly discard it would be potentially devastating.
|
|
|
|
miningpoolhub
Legendary
Offline
Activity: 1456
Merit: 1006
Mining Pool Hub
|
|
July 20, 2016, 06:48:50 AM Last edit: July 20, 2016, 04:04:59 PM by miningpoolhub |
|
Is there any way to reduce the CPU, memory usage from new version?
It consumes too much CPU at startup and eating more than 1GB of memory during running. Do I have to tweak some numbers?
We have observed that CPU usage will be high until at least 8 nodes are connected. Once enough peers are found it seems to settle down. Memory use is high though, and I suspect that will be difficult to limit. You could try to set a ulimit on your daemon user and experiment though... Undoubtedly more work needs to be done on this front. CPU usage is still high even I ran new myriadcoin daemon for more than 10 hours. Surprisingly, connection count is 5 still. This daemon's algo is set for "groestl". Interest thing is, I have another daemon which runs for qubit algo. I started few minutes ago, and it's connection is 4, CPU usage is quite small. Around 0.5% I think it's normal. I don't know the difference between two daemon, but seems like one is doing something wrong. Here's some log from groestl algo daemon. ......erased log since it includes ip addresses...... Actually both daemon's log is similar except kepool reserve, return number. Anyway, it's hard to maintain this kind of daemon on 24/7 server. It harms much.
|
|
|
|
IconFirm
|
|
July 20, 2016, 10:12:14 AM |
|
I use a few coins as the main chain: ZET, NEOS, TRC & XJO. Never had a problem up until v11. I'm compiling v9 again now... Edit: OK, I can confirm that when using the v9 client with p2pool merge mining I am once again seeing: 2016-07-20 00:03:21 ProcessBlock: ACCEPTED 2016-07-20 00:03:22 CreateNewBlock(): total size 1000 in my debug log, meaning everything is working fine again. Also, CPU usage is minimal & RAM usage is ~700mb, so everything is as it was again. Whatever changes were made to XMY between v9 & v11 seem to have broken merge mining & increased resourse usage dramatically. At the risk of losing many miners & network hash rate/security - I would respectfully urge the devs to cancel the fork until the problem is resolved. I can supply any logs needed. Merge mining is one of the many things that make XMY a great coin - to suddenly & needlessly discard it would be potentially devastating. Update: After running v9 over night, I can once again see payments from merge mining XMY flowing into my wallet I would urge anyone who is merge mining XMY NOT to upgrade, especially if you are using p2pool. @ jwinterm: Is UNITUS using the same code base as XMY? If so, try reverting back to the v9 client also?
|
|
|
|
cryptapus
|
|
July 20, 2016, 11:35:42 AM |
|
Is there any way to reduce the CPU, memory usage from new version?
It consumes too much CPU at startup and eating more than 1GB of memory during running. Do I have to tweak some numbers?
We have observed that CPU usage will be high until at least 8 nodes are connected. Once enough peers are found it seems to settle down. Memory use is high though, and I suspect that will be difficult to limit. You could try to set a ulimit on your daemon user and experiment though... Undoubtedly more work needs to be done on this front. CPU usage is still high even I ran new myriadcoin daemon for more than 10 hours. Surprisingly, connection count is 5 still. This daemon's algo is set for "groestl". Interest thing is, I have another daemon which runs for qubit algo. I started few minutes ago, and it's connection is 4, CPU usage is quite small. Around 0.5% I think it's normal. ... Anyway, it's hard to maintain this kind of daemon on 24/7 server. It harms much. The CPU usage should calm down once 8 or more peers are found, please addnode some from http://myriad.nutty.one/homeInteresting though, to clarify you're saying that the Myriad 0.11.3.1 daemon using qubit is not using high cpu with only 4 peers?
|
website | PGP fingerprint: 692C 0756 E57D 2FA1 7601 3729 010B 717F 231C E7AA | BTC Address: 1CrYPTB1o7QWc8hXqBMP2LtAJh1VMtTFBh
|
|
|
miningpoolhub
Legendary
Offline
Activity: 1456
Merit: 1006
Mining Pool Hub
|
|
July 20, 2016, 12:22:19 PM |
|
The CPU usage should calm down once 8 or more peers are found, please addnode some from http://myriad.nutty.one/homeInteresting though, to clarify you're saying that the Myriad 0.11.3.1 daemon using qubit is not using high cpu with only 4 peers? I checked again and found that qubit's connection is now over 8. (I have modified net.cpp MAX_OUTBOUND to higher number) Don't know why it consumed so low cpu at that time. I added several nodes to groestl algo daemon manually and now it consumes low cpu. Connection count was only 5 but increased. Maybe that daemon did have some trouble finding peers. Seems like memory usage is the last problem. myriad daemons are consuming more memory than even bitcoin. Is it related to multi algo structure?
|
|
|
|
cryptapus
|
|
July 20, 2016, 12:29:49 PM |
|
The CPU usage should calm down once 8 or more peers are found, please addnode some from http://myriad.nutty.one/homeInteresting though, to clarify you're saying that the Myriad 0.11.3.1 daemon using qubit is not using high cpu with only 4 peers? I checked again and found that qubit's connection is now over 8. (I have modified net.cpp MAX_OUTBOUND to higher number) Don't know why it consumed so low cpu at that time. I added several nodes to groestl algo daemon manually and now it consumes low cpu. Connection count was only 5 but increased. Maybe that daemon did have some trouble finding peers. Seems like memory usage is the last problem. myriad daemons are consuming more memory than even bitcoin. Is it related to multi algo structure? That's my assumption, yes. A Myriad node has to confirm blocks for all algorithms, not just sha256d.
|
website | PGP fingerprint: 692C 0756 E57D 2FA1 7601 3729 010B 717F 231C E7AA | BTC Address: 1CrYPTB1o7QWc8hXqBMP2LtAJh1VMtTFBh
|
|
|
miningpoolhub
Legendary
Offline
Activity: 1456
Merit: 1006
Mining Pool Hub
|
|
July 20, 2016, 03:25:26 PM |
|
The CPU usage should calm down once 8 or more peers are found, please addnode some from http://myriad.nutty.one/homeInteresting though, to clarify you're saying that the Myriad 0.11.3.1 daemon using qubit is not using high cpu with only 4 peers? I checked again and found that qubit's connection is now over 8. (I have modified net.cpp MAX_OUTBOUND to higher number) Don't know why it consumed so low cpu at that time. I added several nodes to groestl algo daemon manually and now it consumes low cpu. Connection count was only 5 but increased. Maybe that daemon did have some trouble finding peers. Seems like memory usage is the last problem. myriad daemons are consuming more memory than even bitcoin. Is it related to multi algo structure? That's my assumption, yes. A Myriad node has to confirm blocks for all algorithms, not just sha256d. I restarted qubit, skein, myriad algo for each coin and found that only myriad algo daemon consumes much cpu before connection count reaches 8. Almost 100%, but qubit, skein doesn't run like that. Maybe it's not related to algo, but only that daemon. It is really weird that only one daemon is working differently. One more different thing is that myriad algo daemon is built from empty data directory, while other coins used previous data directory with "-reindex" parameter. Maybe skein, qubit is using old peers.dat Any idea about it? I understand about memory usage but it worked with smaller memory before this latest version. Maybe transaction memory pool allocated per algo? Seems like some memory space is wasted, duplicated which can be shared.
|
|
|
|
IconFirm
|
|
July 20, 2016, 04:17:11 PM |
|
8bitcoder asked me to send him some comparison logs via PM. I'm posting a copy of them here in the hope that someone can shed some light on how to fix the issue: OK, I've taken logs of 2 p2pool nodes - one is using the v9 client & one is using the v11 client. Both are running on the same OS (Xubuntu 14.04 64bit), both are merge mining using ZET as the primary chain & both have similar hash rate pointed at them. First log is from the V9 client: 2016-07-20 13:16:15 ProcessBlock: ACCEPTED 2016-07-20 13:16:15 CreateNewBlock(): total size 1000 2016-07-20 13:16:15 nActualTimespan = 5638 before bounds 1469019930 1469014338 2016-07-20 13:16:15 nActualTimespan = 3120 after bounds 2880 3120 2016-07-20 13:16:15 GetNextWorkRequired RETARGET 2016-07-20 13:16:15 nTargetTimespan = 3000 nActualTimespan = 3120 2016-07-20 13:16:15 Before: 1b1080fa 000000000000006c890c00000000000000000000000000000000000000000000 2016-07-20 13:16:15 After: 1970e072 0000000000000070e072e147ae147ae147ae147ae147ae147ae147ae147ae147 2016-07-20 13:16:46 received block ba54823f8b7ca20d364614ce29c4352936f401cfd660d6fa3f0da957f23ab098 2016-07-20 13:16:46 AcceptBlock: BlockTime=1469020581 2016-07-20 13:16:46 nActualTimespan = 896 before bounds 1469020458 1469019805 2016-07-20 13:16:46 nActualTimespan = 2880 after bounds 2880 3120 2016-07-20 13:16:46 GetNextWorkRequired RETARGET 2016-07-20 13:16:46 nTargetTimespan = 3000 nActualTimespan = 2880 2016-07-20 13:16:46 Before: 1b1080fa 0000000004630100000000000000000000000000000000000000000000000000 2016-07-20 13:16:46 After: 1c043615 0000000004361570a3d70a3d70a3d70a3d70a3d70a3d70a3d70a3d70a3d70a3d 2016-07-20 13:16:47 UpdateTip: new best=ba54823f8b7ca20d364614ce29c4352936f401cfd660d6fa3f0da957f23ab098 height=1731905 log2_work=251.68825 tx=4476323 algo=4 date=2016-07-20 13:16:21 progress=0.999999 2016-07-20 13:16:47 ProcessBlock: ACCEPTED 2016-07-20 13:16:47 CreateNewBlock(): total size 1000 2016-07-20 13:16:47 nActualTimespan = 5638 before bounds 1469019930 1469014338 2016-07-20 13:16:47 nActualTimespan = 3120 after bounds 2880 3120 2016-07-20 13:16:47 GetNextWorkRequired RETARGET 2016-07-20 13:16:47 nTargetTimespan = 3000 nActualTimespan = 3120 2016-07-20 13:16:47 Before: 1c043615 000000000000006c890c00000000000000000000000000000000000000000000 2016-07-20 13:16:47 After: 1970e072 0000000000000070e072e147ae147ae147ae147ae147ae147ae147ae147ae147
Everything fine there, accepted blocks, retarget, etc - and payments incoming. Here is the log from the v11 client over the same time period: 2016-07-20 13:10:12 keypool return 22 2016-07-20 13:12:32 UpdateTip: new best=f698f4f53bacdaed69a7a968a3db76303acc4318ea3492f16ccf93c044378e2f height=1731897 algo=1 (scrypt) log2_work=251.68825 tx=4476315 date=2016-07-20 13:10:12 progress=0.999995 cache=0.3MiB(1613tx) 2016-07-20 13:12:32 keypool reserve 22 2016-07-20 13:12:32 CreateNewBlock(): total size 1000 2016-07-20 13:12:32 keypool return 22 2016-07-20 13:12:51 UpdateTip: new best=3fa49ac3e011a739548e26dd3606e515bba4a94ce838a12d86c554cb9c2b959b height=1731898 algo=4 (qubit) log2_work=251.68825 tx=4476316 date=2016-07-20 13:12:33 progress=0.999999 cache=0.3MiB(1614tx) 2016-07-20 13:12:51 keypool reserve 22 2016-07-20 13:12:51 CreateNewBlock(): total size 1000 2016-07-20 13:12:51 keypool return 22 2016-07-20 13:13:33 UpdateTip: new best=ca2488f473c929806ab7504ddacf8a9766f73e2c791a135c1fa32988afc6627e height=1731899 algo=4 (qubit) log2_work=251.68825 tx=4476317 date=2016-07-20 13:12:52 progress=0.999999 cache=0.3MiB(1615tx) 2016-07-20 13:13:34 keypool reserve 22 2016-07-20 13:13:34 CreateNewBlock(): total size 1000 2016-07-20 13:13:34 keypool return 22 2016-07-20 13:14:10 UpdateTip: new best=cddca649d6cdea6136047efbe928d014ae44f1ffa1fea2f5df0c55eeaaeaf7ea height=1731900 algo=2 (groestl) log2_work=251.68825 tx=4476318 date=2016-07-20 13:13:33 progress=0.999999 cache=0.3MiB(1616tx) 2016-07-20 13:14:10 keypool reserve 22 2016-07-20 13:14:10 CreateNewBlock(): total size 1000 2016-07-20 13:14:10 keypool return 22 2016-07-20 13:14:24 UpdateTip: new best=ed956fa518d2b590cc16d13c8c65b8dcb6097961da05c74dc366728f603b7ecf height=1731901 algo=4 (qubit) log2_work=251.68825 tx=4476319 date=2016-07-20 13:14:18 progress=1.000000 cache=0.3MiB(1617tx) 2016-07-20 13:14:24 keypool reserve 22 2016-07-20 13:14:24 CreateNewBlock(): total size 1000 2016-07-20 13:14:24 keypool return 22 2016-07-20 13:15:29 UpdateTip: new best=c5b70c9faef30faf2e892b0ffa8b608c62158a4662c35f0bfe87c05f0e97ffd1 height=1731902 algo=2 (groestl) log2_work=251.68825 tx=4476320 date=2016-07-20 13:14:24 progress=0.999998 cache=0.3MiB(1618tx) 2016-07-20 13:15:30 keypool reserve 22 2016-07-20 13:15:30 CreateNewBlock(): total size 1000 2016-07-20 13:15:30 keypool return 22 2016-07-20 13:16:07 UpdateTip: new best=fe18dcd06d5fa134c0a9ba24c91efc3092bcf4117e6bee5920762b06bc8535f2 height=1731903 algo=1 (scrypt) log2_work=251.68825 tx=4476321 date=2016-07-20 13:15:29 progress=0.999999 cache=0.3MiB(1619tx) 2016-07-20 13:16:07 keypool reserve 22 2016-07-20 13:16:07 CreateNewBlock(): total size 1000 2016-07-20 13:16:07 keypool return 22 2016-07-20 13:16:19 UpdateTip: new best=72206c8ed556f3f710341b14f871c0a2ced637113b1e280f7c1665fc83ccadf4 height=1731904 algo=1 (scrypt) log2_work=251.68825 tx=4476322 date=2016-07-20 13:16:07 progress=1.000000 cache=0.3MiB(1620tx) 2016-07-20 13:16:19 keypool reserve 22 2016-07-20 13:16:19 CreateNewBlock(): total size 1000 2016-07-20 13:16:19 keypool return 22 No accepted blocks, no retarget, etc - and no payments incoming. I'm not a dev or a coder, but it is clear that when comparing these two logs that something is definately amiss with the v11 client - what do you think? Any & all suggestions/ideas are welcome.
|
|
|
|
pekacoin
|
|
July 22, 2016, 04:12:29 PM |
|
Developers will you update your site?
|
|
|
|
pekacoin
|
|
July 23, 2016, 05:36:17 PM |
|
Please do not be silent, now you're close to a rise of its currency The authority of the air falls, the Russians do not believe in the Ethereum, and DAO Tell me what will you create, what are your plans, maybe there is a document You just need to poach whales and you can continue stunning project
|
|
|
|
URSAY
Legendary
Offline
Activity: 1946
Merit: 1000
|
|
July 23, 2016, 07:24:57 PM |
|
the Russians do not believe in the Ethereum, and DAO
Not that I am a supporter of Ethereum or the DAO but how did you gain the authority to speak for all russians? You must be very powerful.
|
|
|
|
jwinterm
Legendary
Offline
Activity: 3024
Merit: 1106
|
|
July 23, 2016, 07:28:31 PM |
|
Most people don't know this, but pekacoin is actually Vova Putin.
On another note, if the fancier website is open source and published, I think it wouldn't hurt to use it and spiff up website a bit.
|
|
|
|
pekacoin
|
|
July 23, 2016, 07:30:25 PM |
|
the Russians do not believe in the Ethereum, and DAO
Not that I am a supporter of Ethereum or the DAO but how did you gain the authority to speak for all russians? You must be very powerful. I just read 90% of the comments
|
|
|
|
URSAY
Legendary
Offline
Activity: 1946
Merit: 1000
|
|
July 23, 2016, 07:46:42 PM |
|
Why not create a secondary myriad website so there are multiple versions and something to fall back on ? Isn't that the general idea of decentralization?
|
|
|
|
|
IconFirm
|
|
July 24, 2016, 02:18:21 PM |
|
I've had to revert to using the v9 client on all my nodes now - the resource usage on the v11 client is just too high. I hope the devs reconsider forking v9 clients off the network....
|
|
|
|
myriadcoin
|
|
July 25, 2016, 02:04:55 AM |
|
I've had to revert to using the v9 client on all my nodes now - the resource usage on the v11 client is just too high. I hope the devs reconsider forking v9 clients off the network....
Oh no.... Myriad Classic?
|
Myriad: the ORIGINAL and fairest distribution 5 algo coin, which I did not develop. http://myriadcoin.orgNOT the Myriad developer. Just a fan.
|
|
|
jwinterm
Legendary
Offline
Activity: 3024
Merit: 1106
|
|
July 25, 2016, 03:09:41 AM |
|
I've had to revert to using the v9 client on all my nodes now - the resource usage on the v11 client is just too high. I hope the devs reconsider forking v9 clients off the network....
Oh no.... Myriad Classic? Lol please no Seriously tho, any ideas what is causing this issue?
|
|
|
|
pekacoin
|
|
July 25, 2016, 08:09:05 AM |
|
I've had to revert to using the v9 client on all my nodes now - the resource usage on the v11 client is just too high. I hope the devs reconsider forking v9 clients off the network....
Oh no.... Myriad Classic? Lol please no Seriously tho, any ideas what is causing this issue? Myriad Classic awesome idea
|
|
|
|
|