|
Trillium
|
 |
December 24, 2013, 04:51:24 AM |
|
if I have a chains/day value of 2.7 with N-chain value of 9 what should I expect with N-chain=10?
Almost 0.1 |
BTC:1AaaAAAAaAAE2L1PXM1x9VDNqvcrfa9He6 |
|
|
|
|
|
|
|
|
|
|
|
I HATE TABLES I HATE TABLES I HA(╯°□°）╯︵ ┻━┻ TABLES I HATE TABLES I HATE TABLES
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
primer-
Legendary
 Offline
Activity: 1092
Merit: 1000
|
|
December 24, 2013, 07:33:40 PM |
|
We have not found a single block in the last 48 hours on a server cluster that used to find 7-10 blocks a day. Could it be due to bad default settings ? How to optimize settings for 10 difficulty, what should be used as sieveextensions, sievepercentage and sievesize ?
|
|
|
|
|
|
mhps
|
|
December 25, 2013, 12:16:19 AM |
|
We have not found a single block in the last 48 hours on a server cluster that used to find 7-10 blocks a day. Could it be due to bad default settings ? How to optimize settings for 10 difficulty, what should be used as sieveextensions, sievepercentage and sievesize ?
That is down by a factor of ~20. You didn't say when you found 10 blocks a day. Current difficulty is 0.35%*(1-0.17)*CPD_of_9ch, which is about 20 times more difficult when diff=9.94 (end of October and around Nov 24). |
|
|
|
primer-
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
December 25, 2013, 12:54:33 AM |
|
We have not found a single block in the last 48 hours on a server cluster that used to find 7-10 blocks a day. Could it be due to bad default settings ? How to optimize settings for 10 difficulty, what should be used as sieveextensions, sievepercentage and sievesize ?
That is down by a factor of ~20. You didn't say when you found 10 blocks a day. Current difficulty is 0.35%*(1-0.17)*CPD_of_9ch, which is about 20 times more difficult when diff=9.94 (end of October and around Nov 24). 18. Dec - 8 blocks, 19. Dec 9 blocks, 20. Dec. 6 blocks, 21 Dec. 8 blocks, 22. Dec - 2 blocks, 23 Dec - 0 blocks, 24. Dec. 0 blocks, 25. Dec - 0 blocks ... Must be due to sieveextensions, sievepercentage and sievesize values or hp11 client itself ? |
|
|
|
|
|
mhps
|
|
December 25, 2013, 04:06:06 AM |
|
Check out debug.log . Maybe something other than the parameters is wrong.
|
|
|
|
|
Trillium
|
|
December 25, 2013, 08:47:22 AM |
|
Unfortunately optimizing the parameters seems to require either a lot of time or a lot of machines (or more likely, both). I would say that you are in a good position to do some hands on testing for us.
|
BTC:1AaaAAAAaAAE2L1PXM1x9VDNqvcrfa9He6 |
|
|
|
mikaelh (OP)
|
|
December 25, 2013, 10:10:03 AM |
|
18. Dec - 8 blocks, 19. Dec 9 blocks, 20. Dec. 6 blocks, 21 Dec. 8 blocks, 22. Dec - 2 blocks, 23 Dec - 0 blocks, 24. Dec. 0 blocks, 25. Dec - 0 blocks ...
Must be due to sieveextensions, sievepercentage and sievesize values or hp11 client itself ?
Difficulty 10 started on the 15th of December. Your data shows that your mining results dropped to zero about one week after that. I don't really see why that would happen like that. It's probably a good idea to also check that your miners and machines haven't crashed for some other reason. |
|
|
|
|
|
Trillium
|
|
December 25, 2013, 10:18:49 AM |
|
18. Dec - 8 blocks,
19. Dec 9 blocks,
20. Dec. 6 blocks,
21 Dec. 8 blocks,
22. Dec - 2 blocks,
23 Dec - 0 blocks,
24. Dec. 0 blocks,
25. Dec - 0 blocks ...
Must be due to sieveextensions, sievepercentage and sievesize values or hp11 client itself ?
Out of curiosity, are you running the same wallet.dat file on all of these machines? |
BTC:1AaaAAAAaAAE2L1PXM1x9VDNqvcrfa9He6 |
|
|
primer-
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
December 25, 2013, 11:16:35 AM |
|
18. Dec - 8 blocks, 19. Dec 9 blocks, 20. Dec. 6 blocks, 21 Dec. 8 blocks, 22. Dec - 2 blocks, 23 Dec - 0 blocks, 24. Dec. 0 blocks, 25. Dec - 0 blocks ...
Must be due to sieveextensions, sievepercentage and sievesize values or hp11 client itself ?
Difficulty 10 started on the 15th of December. Your data shows that your mining results dropped to zero about one week after that. I don't really see why that would happen like that. It's probably a good idea to also check that your miners and machines haven't crashed for some other reason. Hello mikaelh, i have checked debug.log on all servers, no errors. They are not using the same wallet.dat file. Haveged package is installed on all instances to ensure entropy/no duplicate work. They are all synced with the network. If sieve options are not causing the issue the only thing i have not done is recreate peers.dat file to get a fresh list of nodes on every server. Would it be better to point all mining servers to one under my control, with a -connect= flag in the config or leave node selection default ? I have switched them all to mining litecoin since my last post but will soon switch them back. Let me know If there is anything else you'd like me to test. |
|
|
|
|
|
mikaelh (OP)
|
|
December 25, 2013, 03:37:16 PM |
|
Hello mikaelh, i have checked debug.log on all servers, no errors. They are not using the same wallet.dat file. Haveged package is installed on all instances to ensure entropy/no duplicate work. They are all synced with the network. If sieve options are not causing the issue the only thing i have not done is recreate peers.dat file to get a fresh list of nodes on every server. Would it be better to point all mining servers to one under my control, with a -connect= flag in the config or leave node selection default ?
I have switched them all to mining litecoin since my last post but will soon switch them back. Let me know If there is anything else you'd like me to test.
If every miner is using a separate wallet, then you shouldn't have issues with running out of pre-generated keys. If your wallets are encrypted, then you may run out of keys because the wallet needs to be unlocked before new keys can be generated. Connectivity is also important because mining will stop if the wallet loses all connections. Using the -connect parameter is probably a bad idea because it introduces a single point of failure. If your central node crashes, then all the slave nodes lose connectivity. You should use -addnode if you want to have a central node. I looked at the code a bit and I spotted a potential issue with shared wallet mining. The issue is that N mining threads are probably using the first N keys available in the wallet. If multiple machines are using the same wallet, they may be trying to solve the same block if the timestamp and the extra nonce are the same. I can write a fix for that but it's unlikely to help you since you're using separate wallets. That's all the ideas I have currently. |
|
|
|
|
primer-
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
December 25, 2013, 03:57:41 PM |
|
Hello mikaelh, i have checked debug.log on all servers, no errors. They are not using the same wallet.dat file. Haveged package is installed on all instances to ensure entropy/no duplicate work. They are all synced with the network. If sieve options are not causing the issue the only thing i have not done is recreate peers.dat file to get a fresh list of nodes on every server. Would it be better to point all mining servers to one under my control, with a -connect= flag in the config or leave node selection default ?
I have switched them all to mining litecoin since my last post but will soon switch them back. Let me know If there is anything else you'd like me to test.
If every miner is using a separate wallet, then you shouldn't have issues with running out of pre-generated keys. If your wallets are encrypted, then you may run out of keys because the wallet needs to be unlocked before new keys can be generated. Connectivity is also important because mining will stop if the wallet loses all connections. Using the -connect parameter is probably a bad idea because it introduces a single point of failure. If your central node crashes, then all the slave nodes lose connectivity. You should use -addnode if you want to have a central node. I looked at the code a bit and I spotted a potential issue with shared wallet mining. The issue is that N mining threads are probably using the first N keys available in the wallet. If multiple machines are using the same wallet, they may be trying to solve the same block if the timestamp and the extra nonce are the same. I can write a fix for that but it's unlikely to help you since you're using separate wallets. That's all the ideas I have currently. We use separate wallets + they were all generated using -keypool=5000 , so each can hold up to 5000 transactions. Now the important part : Just before i switched back to XMP mining i came accross a post about haveged!: https://bitcointalk.org/index.php?topic=255782.msg2899987#msg2899987I killed it on all servers, started mining, and in less than one hour 1 block found. Now how does that explain found blocks before 22. Dec - well i do recall killing haveged manually on all servers on several occasions so it most probably was not running on all servers. What i do know for sure is that all servers were rebooted on 22. Dec and several times after, chkconfig shows haveged as on so it started automatically. I will post an update tomorrow. Regarding conectivity, if wallet loses all connections, wouldnt it be trying to reconnect indefinitely, using peers.dat file ? I've had machines lose conectivity for hours and reconnect just fine. |
|
|
|
|
primer-
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
December 25, 2013, 04:13:59 PM |
|
I looked at the code a bit and I spotted a potential issue with shared wallet mining. The issue is that N mining threads are probably using the first N keys available in the wallet. If multiple machines are using the same wallet, they may be trying to solve the same block if the timestamp and the extra nonce are the same. I can write a fix for that but it's unlikely to help you since you're using separate wallets.
Please fix this issue in the next version or provide a patch, i know of many miners using the same wallet+hp11. As a quick fix, would it help if time is changed on servers mining with the same wallet - eg one set at UTC +1 and the other at UTC+2 ? |
|
|
|
|
GigaCoin
Sr. Member
Offline
Activity: 308
Merit: 251
Giga
|
|
December 25, 2013, 04:15:13 PM |
|
any plans for osx and android wallet?
website is also in serious need of an update
|
|
|
|
|
mikaelh (OP)
|
|
December 25, 2013, 05:00:51 PM |
|
We use separate wallets + they were all generated using -keypool=5000 , so each can hold up to 5000 transactions. Now the important part : Just before i switched back to XMP mining i came accross a post about haveged!: https://bitcointalk.org/index.php?topic=255782.msg2899987#msg2899987I killed it on all servers, started mining, and in less than one hour 1 block found. Now how does that explain found blocks before 22. Dec - well i do recall killing haveged manually on all servers on several occasions so it most probably was not running on all servers. What i do know for sure is that all servers were rebooted on 22. Dec and several times after, chkconfig shows haveged as on so it started automatically. I think the positive/negative experiences with haveged are merely coincidences. Haveged should only be generating some additional entropy, which isn't used by the mining process. Entropy is only used by the OpenSSL library for specific tasks (e.g. generating new keypairs). Regarding conectivity, if wallet loses all connections, wouldnt it be trying to reconnect indefinitely, using peers.dat file ? I've had machines lose conectivity for hours and reconnect just fine.
Yes, the wallet will keep trying to reconnect to nodes stored in peers.dat. There should normally be at least hundreds of addresses in that file. |
|
|
|
|
|
mikaelh (OP)
|
|
December 25, 2013, 05:10:13 PM |
|
any plans for osx and android wallet?
website is also in serious need of an update
I don't have a Mac computer, so there will be no OS X builds in the near future. There are some other OS X builds in the wild: http://www.peercointalk.org/index.php?topic=343.0No plans for an Android wallet currently. |
|
|
|
|
Hix
Legendary
Offline
Activity: 1971
Merit: 1036
|
|
December 25, 2013, 05:31:37 PM |
|
mikaelh
Have any plans to build standalone miner for Solo(getwork or getblocktemplate)? Xolo promise make it, but... only promise...
|
|
|
|
|
|
mikaelh (OP)
|
|
December 25, 2013, 05:48:46 PM |
|
I looked at the code a bit and I spotted a potential issue with shared wallet mining. The issue is that N mining threads are probably using the first N keys available in the wallet. If multiple machines are using the same wallet, they may be trying to solve the same block if the timestamp and the extra nonce are the same. I can write a fix for that but it's unlikely to help you since you're using separate wallets.
Please fix this issue in the next version or provide a patch, i know of many miners using the same wallet+hp11. As a quick fix, would it help if time is changed on servers mining with the same wallet - eg one set at UTC +1 and the other at UTC+2 ? Playing around with the system time will likely cause more problems. There's even a warning message if it seems to be off by too much. So you actually should check that all your servers have the correct time. |
|
|
|
|
|
mikaelh (OP)
|
|
December 25, 2013, 05:51:21 PM |
|
mikaelh
Have any plans to build standalone miner for Solo(getwork or getblocktemplate)? Xolo promise make it, but... only promise...
I'm not sure if I'm going to have the time to develop a standalone miner. Right now I have no plans for it. Hopefully someone will step up and make one. |
|
|
|
|
Hix
Legendary
Offline
Activity: 1971
Merit: 1036
|
|
December 25, 2013, 06:49:22 PM |
|
mikaelh
Have any plans to build standalone miner for Solo(getwork or getblocktemplate)? Xolo promise make it, but... only promise...
I'm not sure if I'm going to have the time to develop a standalone miner. Right now I have no plans for it. Hopefully someone will step up and make one. Anyway thank you for your work. |
|
|
|
|
|
mumus
|
|
December 25, 2013, 07:16:42 PM |
|
mikaelh
Have any plans to build standalone miner for Solo(getwork or getblocktemplate)? Xolo promise make it, but... only promise...
I'm not sure if I'm going to have the time to develop a standalone miner. Right now I have no plans for it. Hopefully someone will step up and make one. Anyway thank you for your work. Hi, Regarding to standalone miner check out my Github repository at https://github.com/hg5fm/jhPrimeminerThis one originally was written for ypool.org but now supports both getwork and getblocktemplate for solo mining. Rdebourbon's 4.0F2 from https://mega.co.nz/#F!SMdjBZjA!ft7TBVIedEg820_3GFzEAQ is a more optimized version especially for solo mining supports getblocktemplate. For linux there is Tandyuk's port from https://github.com/tandyuk/jhPrimeminer/tree/mumu-v8 . This one only works with getwork protocol so the latest (original, non HP) primecoind is required to work with it. |
|
|
|
|
|
