Can this run on Linux? Also, can -xpm "" deposit to the default "" address?
Currently there is no linux build of the beta, but the port is close to completion..
The -xpm argument requires an address at the moment.
Topic: [XPM]unofficial jhPrimeminer thread - page 11. (Read 180221 times)
Currently there is no linux build of the beta, but the port is close to completion..
The -xpm argument requires an address at the moment.
Can this run on Linux? Also, can -xpm "" deposit to the default "" address?
I actually did it. What happened was that several hours after I had started the miner I found the 7-chain/h number reported by the last new-block message shown in the console to be 6.8, which was much higher that normal. Then I noticed that only 2 (two) 7-chains have been found. I expected much more. I pressed s and saw there have been 2 hours 43 minutes since the miner had been started. I looked at the block number in the last new-block message and found the block number was more than 100 behind the latest block found on ypool. That definitely proved that the miner had been stuck for a long time. And the 6.8 7c/h with 2 chains found means the miner found the last block at 60/6.8*2 =~ 20min . The log showed two 7 chains. The miner usually find about 40 6-chains and 4 7-chains when everything worked. hope this helps.
Thats utterly bizarre.. I've had no such similar complaints from other users of v3.3 or v4.0.. Could it be something on your network interfering with the socket connections to/from the pool? ie do you have multiple miners behind a single NAT'd firewall that could be losing state?
Surely something has changed. I don't think it is 4.0-speific. I have an old post in this thread https://bitcointalksearch.org/topic/m.3328322 when 3.3 and 3.2 started to have problems. It could be something with my networks but I have no issue at all with any other applications. Beeeeer.org's miner worked well (except it had rejection rate of ~10% that everyone has, which could mask netowrk problems. But that miner never hangs). After my last post I started v3.3. Just now it's 9 hours later and I see it is dead -- the console has the Chains/H lines updating but no new-block message. ypool log shows that my miner stopped finding shares some hours ago.
Quote
JH00 did say that the XPM protocol supported "ping" - I will look to enable this in the next version so we can try isolate the issue you are experiencing.. At this point, I have to be honest but I think its something external to the miner code..
Thanks for trying to track the problem down. I am trying an old version of your miner modified by cabin (installed on Aug 22). It appears to work like before. I will run it for some hours and see the result.
I actually did it. What happened was that several hours after I had started the miner I found the 7-chain/h number reported by the last new-block message shown in the console to be 6.8, which was much higher that normal. Then I noticed that only 2 (two) 7-chains have been found. I expected much more. I pressed s and saw there have been 2 hours 43 minutes since the miner had been started. I looked at the block number in the last new-block message and found the block number was more than 100 behind the latest block found on ypool. That definitely proved that the miner had been stuck for a long time. And the 6.8 7c/h with 2 chains found means the miner found the last block at 60/6.8*2 =~ 20min . The log showed two 7 chains. The miner usually find about 40 6-chains and 4 7-chains when everything worked. hope this helps.
Thats utterly bizarre.. I've had no such similar complaints from other users of v3.3 or v4.0.. Could it be something on your network interfering with the socket connections to/from the pool? ie do you have multiple miners behind a single NAT'd firewall that could be losing state?
JH00 did say that the XPM protocol supported "ping" - I will look to enable this in the next version so we can try isolate the issue you are experiencing.. At this point, I have to be honest but I think its something external to the miner code..
Do you mean v3.2? The message is terse, something like "xpt .... reconnect in 30 seconds".
The error you are describing is definitely a network disconnect.. Something you shouldn't see very often .. As I said in last message, the networking code has not really changed between 3.3 & 4.0, so I would expect the same behaviour between the 2..
I have compared with v4.0E and v3.3 and they had similar problems. The stranged thing was that before mid-October v3.3 was very stable. Now I can't even get v3.3 to work properly. I find much less 7-chains.
Quote
Back to the original ~20mins exit/crash/issue - was the entire display frozen, or was it purely waiting for a block update to display? v4.0 does not include the updates between blocks - so if a long block is encountered it can appear "frozen".. although 20mins is a very long time to not get an update.. Can I ask you to try again, and if it appears frozen to press S to see if the app is still responsive?
I actually did it. What happened was that several hours after I had started the miner I found the 7-chain/h number reported by the last new-block message shown in the console to be 6.8, which was much higher that normal. Then I noticed that only 2 (two) 7-chains have been found. I expected much more. I pressed s and saw there have been 2 hours 43 minutes since the miner had been started. I looked at the block number in the last new-block message and found the block number was more than 100 behind the latest block found on ypool. That definitely proved that the miner had been stuck for a long time. And the 6.8 7c/h with 2 chains found means the miner found the last block at 60/6.8*2 =~ 20min . The log showed two 7 chains. The miner usually find about 40 6-chains and 4 7-chains when everything worked. hope this helps.
Do you mean v3.2? The message is terse, something like "xpt .... reconnect in 30 seconds".
The error you are describing is definitely a network disconnect.. Something you shouldn't see very often .. As I said in last message, the networking code has not really changed between 3.3 & 4.0, so I would expect the same behaviour between the 2..
Back to the original ~20mins exit/crash/issue - was the entire display frozen, or was it purely waiting for a block update to display? v4.0 does not include the updates between blocks - so if a long block is encountered it can appear "frozen".. although 20mins is a very long time to not get an update.. Can I ask you to try again, and if it appears frozen to press S to see if the app is still responsive?
Quote
Is the block sent through the blockchain? Is there a traction fee?
The block is mined into specified XPM wallet address exactly the same as if mined within wallet.. No traction fees incurred.
Thanks for giving it a try - am somewhat surprised that you had a disconnect/crash/exit after ~20mins. Can you clarify what you mean by "over-often reconnect of V3.2"? Is this a case of needing "NOHUP"?
From the console, it appears that v3.2 tries to reconnect when no new blocks had been detected for a while. This is very welcome when the miner hangs there spending 100% CPU and perhaps getting no new work which I am facing. But I guess many people felt the reconnection was too often -- it perhaps happened when there was no real disconnection, too -- especially the reconnection also came with a 30 seconds pause. I remember that the v3.3 release note said one of the improvement was that the over-zealous reconnection feature was removed. So I am hoping the feature is still available.
I have tried to use a script to kill the miner automatically after an hour and restart it. As it turned out somehow the performance of the miner was severely affected. So that route was out.
Quote
Also, if you're interested, v4f can be used to solo off the wallet via GetBlockTemplate 
There may still be a scaling issue when trying to have hundreds of cores mine off a single wallet.. but for smaller setups it seems to work well..
There may still be a scaling issue when trying to have hundreds of cores mine off a single wallet.. but for smaller setups it seems to work well.. Is there documentation to descrie how it is done?
I'll look back over the 3.2/3.3 changes to refresh my memory, but I do not recall any specific reconnection amendments. The primary changes were with the thread watchdog which too often felt a thread had "died" even though it was actively processing..
I think that is what I was talking about.
Quote
If you were seeing loads of network related messages with 30sec messages, it implies you were being disconnected from the pool and very often - something that is also strange in its own right.. The underlying network code has not changed from v3.3 to v4.0, so you should be able to test on v3.3 and see if you get the messages you are refering too.
Do you mean v3.2? The message is terse, something like "xpt .... reconnect in 30 seconds".
Quote
As for the solo mining, you first need to enable the RPC server in the wallet, and setup all the RPC user/password/port/ipallow options to allow network RPC mining requests.. this thread should help with the principles behind doing that: https://bitcointalksearch.org/topic/solo-mining-with-wallet-miner-323859
Once that is working, start the miner with the following syntax (substituting values to match your setup)
jhPrimeMiner.exe -o http://YourServer:rpcport -u rpcusername -p rpcpassword -xpm payoutAddress
You can also add primorial / sieve size / primes arguments as per normal pool mining.. Personally, I'd only add the primorial -m option with your favourite primorial..
Once that is working, start the miner with the following syntax (substituting values to match your setup)
jhPrimeMiner.exe -o http://YourServer:rpcport -u rpcusername -p rpcpassword -xpm payoutAddress
You can also add primorial / sieve size / primes arguments as per normal pool mining.. Personally, I'd only add the primorial -m option with your favourite primorial..
Is the block sent through the blockchain? Is there a traction fee?
Thanks for giving it a try - am somewhat surprised that you had a disconnect/crash/exit after ~20mins. Can you clarify what you mean by "over-often reconnect of V3.2"? Is this a case of needing "NOHUP"?
From the console, it appears that v3.2 tries to reconnect when no new blocks had been detected for a while. This is very welcome when the miner hangs there spending 100% CPU and perhaps getting no new work which I am facing. But I guess many people felt the reconnection was too often -- it perhaps happened when there was no real disconnection, too -- especially the reconnection also came with a 30 seconds pause. I remember that the v3.3 release note said one of the improvement was that the over-zealous reconnection feature was removed. So I am hoping the feature is still available.
I have tried to use a script to kill the miner automatically after an hour and restart it. As it turned out somehow the performance of the miner was severely affected. So that route was out.
Quote
Also, if you're interested, v4f can be used to solo off the wallet via GetBlockTemplate There may still be a scaling issue when trying to have hundreds of cores mine off a single wallet.. but for smaller setups it seems to work well..
There may still be a scaling issue when trying to have hundreds of cores mine off a single wallet.. but for smaller setups it seems to work well.. Is there documentation to descrie how it is done?
I'll look back over the 3.2/3.3 changes to refresh my memory, but I do not recall any specific reconnection amendments. The primary changes were with the thread watchdog which too often felt a thread had "died" even though it was actively processing.. If you were seeing loads of network related messages with 30sec messages, it implies you were being disconnected from the pool and very often - something that is also strange in its own right.. The underlying network code has not changed from v3.3 to v4.0, so you should be able to test on v3.3 and see if you get the messages you are refering too.
As for the solo mining, you first need to enable the RPC server in the wallet, and setup all the RPC user/password/port/ipallow options to allow network RPC mining requests.. this thread should help with the principles behind doing that: https://bitcointalksearch.org/topic/solo-mining-with-wallet-miner-323859
Once that is working, start the miner with the following syntax (substituting values to match your setup)
jhPrimeMiner.exe -o http://YourServer:rpcport -u rpcusername -p rpcpassword -xpm payoutAddress
You can also add primorial / sieve size / primes arguments as per normal pool mining.. Personally, I'd only add the primorial -m option with your favourite primorial..
Thanks for giving it a try - am somewhat surprised that you had a disconnect/crash/exit after ~20mins. Can you clarify what you mean by "over-often reconnect of V3.2"? Is this a case of needing "NOHUP"?
From the console, it appears that v3.2 tries to reconnect when no new blocks had been detected for a while. This is very welcome when the miner hangs there spending 100% CPU and perhaps getting no new work which I am facing. But I guess many people felt the reconnection was too often -- it perhaps happened when there was no real disconnection, too -- especially the reconnection also came with a 30 seconds pause. I remember that the v3.3 release note said one of the improvement was that the over-zealous reconnection feature was removed. So I am hoping the feature is still available.
I have tried to use a script to kill the miner automatically after an hour and restart it. As it turned out somehow the performance of the miner was severely affected. So that route was out.
Quote
Also, if you're interested, v4f can be used to solo off the wallet via GetBlockTemplate There may still be a scaling issue when trying to have hundreds of cores mine off a single wallet.. but for smaller setups it seems to work well..
There may still be a scaling issue when trying to have hundreds of cores mine off a single wallet.. but for smaller setups it seems to work well.. Is there documentation to descrie how it is done?
Started it on my Xeon 5620 box using 7 threads and just find, 2hr40 minutes later, that it had died after running ~20 minutes.
The CPU usage is still the same 90%. It just stopped updating the console.
I miss the "over-often" reconnect of v3.2, with a command line option maybe.
Going back to soloing.
This is the FoundShare.log.
Code:
...snipped for brevity..
Thanks for giving it a try - am somewhat surprised that you had a disconnect/crash/exit after ~20mins. Can you clarify what you mean by "over-often reconnect of V3.2"? Is this a case of needing "NOHUP"?
Also, if you're interested, v4f can be used to solo off the wallet via GetBlockTemplate
There may still be a scaling issue when trying to have hundreds of cores mine off a single wallet.. but for smaller setups it seems to work well.. Did you guys notice that recommended miner on ypool is rdebourbon's 4.0 now?
Also ypool doesn't link to this thread anymore.
Also ypool doesn't link to this thread anymore.
Anyway, I've released v4.0F today,
Started it on my Xeon 5620 box using 7 threads and just find, 2hr40 minutes later, that it had died after running ~20 minutes.
The CPU usage is still the same 90%. It just stopped updating the console.
I miss the "over-often" reconnect of v3.2, with a command line option maybe.
Going back to soloing.
This is the FoundShare.log.
Code:
*=============================================================================================
*MINER STARTED @ 11/05/13-08:27:43 7
*=============================================================================================
I1000000 25000 0
I1000000 27500 31
I1000000 30000 31
Sa10bb95954977f94e88446f63676ba3289d2b00096677ec4259786db516a8ade 38a915a0bcef 682623 6 0 7.53921 1
I1000000 32500 31
I1000000 27500 31
I1000000 25000 31
I1000000 22500 31
I1000000 20000 31
I1000000 17500 31
Sd09a99d79d5094c89301cf71f230ffd5e98453c470569baed0a93eb4afe33a54 38a915a0bcef 9155 28 0 7.37336 2
I1000000 15000 31
I1000000 12500 31
I1000000 10000 31
I1000000 7500 31
I1000000 20000 31
*MINER STARTED @ 11/05/13-08:27:43 7
*=============================================================================================
I1000000 25000 0
I1000000 27500 31
I1000000 30000 31
Sa10bb95954977f94e88446f63676ba3289d2b00096677ec4259786db516a8ade 38a915a0bcef 682623 6 0 7.53921 1
I1000000 32500 31
I1000000 27500 31
I1000000 25000 31
I1000000 22500 31
I1000000 20000 31
I1000000 17500 31
Sd09a99d79d5094c89301cf71f230ffd5e98453c470569baed0a93eb4afe33a54 38a915a0bcef 9155 28 0 7.37336 2
I1000000 15000 31
I1000000 12500 31
I1000000 10000 31
I1000000 7500 31
I1000000 20000 31
Did you guys notice that recommended miner on ypool is rdebourbon's 4.0 now?
Also ypool doesn't link to this thread anymore.
Also ypool doesn't link to this thread anymore.
Thanks for pointing this out! I was unaware the beta had been promoted to default until I saw this the other day!
Anyway, I've released v4.0F today, its got a handy little performance increase in it, as well as a good reduction in memory footprint (almost halved!). It also includes a potential bugfix to the GetBlockTemplate code submitted by JH00..
Usage is same as other v4.0s although you should let the auto tune run again if updating to v4.0F. The only parameter of concern to most users now is -m - which is used to set the primorial. Set it to a value that finds you best number of long chains.. I default to 43, you may want 37/47/53/61/similar. Don't go below 29 IMO.
As with v4.0E, this version creates a plain text Foundshares.log which captures details of any shares you find. If you feel generous and wish to share the file with me I would really appreciate it as it helps develop the miner .. Please feel free to inspect the file yourself to make sure it does not contain any sensitive data..
Happy mining!
EDIT: All my builds are available in the same dropbox as before: https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
Did you guys notice that recommended miner on ypool is rdebourbon's 4.0 now?
Also ypool doesn't link to this thread anymore.
Also ypool doesn't link to this thread anymore.
My miners die after several tens of minutes recently. I have tried rdb 4.0, 3.3, 3.2. The 3.3 and 3.2 used to run days without any problem.
Also the rate of finding 7-chains has seemed to go down by a lot. I can't get good statistics because miners die too often.
Also the rate of finding 7-chains has seemed to go down by a lot. I can't get good statistics because miners die too often.
I've been mining at yPool with jhPrimeminer-T11.8-AVX.exe. Don't recall where or why, maybe just first I found when I wanted to try XPM mining.
Is jhPrimeMiner_RdBBeta3.zip the best XPM miner to use now
(Edit: Is primeminer_v06_rc2_x86_and_x64.zip the XPM miner now? I think this is Xolominer for the beer joint.)
Is jhPrimeMiner_RdBBeta3.zip the best XPM miner to use now
(Edit: Is primeminer_v06_rc2_x86_and_x64.zip the XPM miner now? I think this is Xolominer for the beer joint.)
I'm wondering the same plus which miner does work with the wallet itself, thus support GetBlock?
I've been mining at yPool with jhPrimeminer-T11.8-AVX.exe. Don't recall where or why, maybe just first I found when I wanted to try XPM mining.
Is jhPrimeMiner_RdBBeta3.zip the best XPM miner to use now
(Edit: Is primeminer_v06_rc2_x86_and_x64.zip the XPM miner now? I think this is Xolominer for the beer joint.)
Is jhPrimeMiner_RdBBeta3.zip the best XPM miner to use now
(Edit: Is primeminer_v06_rc2_x86_and_x64.zip the XPM miner now? I think this is Xolominer for the beer joint.)
I've posted v3.3 of my miner today. It can be downloaded from here: https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
This is mainly a bug fix release. Fixes include:
2/100% primorial decrement overflow
Over aggressive thread watchdog
Chain counters now only show chains which could be valid shares. Also changed to Valid/Total instead of Total/Valid as per many requests.
Fixed a memory leak on new block detection.
Removed original primorial multiplier adjuster that kept changing primorial even after a user chose to disable round sieve adjuster.
BiTwin filter was incorrectly checking CC2 length instead of CC1 for odd length BiTwins.
Fixed GetWork mode (currently disabled on yPool though).
Added back a removed setting that actually helped some CPUs with cache / memory performance.
Sorry guys, but does this miner work with wine?This is mainly a bug fix release. Fixes include:
2/100% primorial decrement overflow
Over aggressive thread watchdog
Chain counters now only show chains which could be valid shares. Also changed to Valid/Total instead of Total/Valid as per many requests.
Fixed a memory leak on new block detection.
Removed original primorial multiplier adjuster that kept changing primorial even after a user chose to disable round sieve adjuster.
BiTwin filter was incorrectly checking CC2 length instead of CC1 for odd length BiTwins.
Fixed GetWork mode (currently disabled on yPool though).
Added back a removed setting that actually helped some CPUs with cache / memory performance.
I tryed it on centos 6 but I didn't manage to succeed in making it work.
The other interesting question in the topic of ypool vs beeeeer vs rpool.
Are beeeeer or rpool miners any good? I know many people put a lot of work into what turned out to be rdebourbon's v3.3 miner. It has many optimizations and fine tuning so we mine more coins with the same CPU resources. How do other miners compare? Are they even in the same league?
I was using jhPrimeMiner (I think this is rdebourbon's) on ypool and was definitely getting less shares. Are beeeeer or rpool miners any good? I know many people put a lot of work into what turned out to be rdebourbon's v3.3 miner. It has many optimizations and fine tuning so we mine more coins with the same CPU resources. How do other miners compare? Are they even in the same league?
(i5 2400)
You have to get more than several 9-chains before you draw conclusion because ypool put much higher weights on 9-chains to calculate share values. Theoretically after a long time all pools should all give return dimilar to soloing minus pool fees. Many people only mine one day or two with one machine and find they don't get paid much on ypool because they haven't got any 9-chains. Actually when they eventually find some 9-chains the numbers aren't that bad.
That said, however after almost two month's mining on ypool I got about 75% reward for the blocks I had found for the pool. That ratio is less than I expected. I am going to mine on beeeeer.com for a month and compare results.
The other interesting question in the topic of ypool vs beeeeer vs rpool.
Are beeeeer or rpool miners any good? I know many people put a lot of work into what turned out to be rdebourbon's v3.3 miner. It has many optimizations and fine tuning so we mine more coins with the same CPU resources. How do other miners compare? Are they even in the same league?
I was using jhPrimeMiner (I think this is rdebourbon's) on ypool and was definitely getting less shares. Are beeeeer or rpool miners any good? I know many people put a lot of work into what turned out to be rdebourbon's v3.3 miner. It has many optimizations and fine tuning so we mine more coins with the same CPU resources. How do other miners compare? Are they even in the same league?
(i5 2400)
The other interesting question in the topic of ypool vs beeeeer vs rpool.
Are beeeeer or rpool miners any good? I know many people put a lot of work into what turned out to be rdebourbon's v3.3 miner. It has many optimizations and fine tuning so we mine more coins with the same CPU resources. How do other miners compare? Are they even in the same league?
Are beeeeer or rpool miners any good? I know many people put a lot of work into what turned out to be rdebourbon's v3.3 miner. It has many optimizations and fine tuning so we mine more coins with the same CPU resources. How do other miners compare? Are they even in the same league?
Jump to: