[XPM]unofficial jhPrimeminer thread

[Scott J]

If your mining on Beeeeer.org DONT use Groms miner, as there is an extra payout address coded in he takes 20%+ of all shares you submit!

I can confirm this - bewaaaaare.

[1714214933]

1714214933

[1714214933]

1714214933

[1714214933]

1714214933

[belltown]

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? 

[Scott J]

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.

(i5 2400)

[mhps]

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.

(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.

[Giodark]

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?
I tryed it on centos 6 but I didn't manage to succeed in making it work.

[Aurum]

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.)

[Sy]

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.)

I'm wondering the same plus which miner does work with the wallet itself, thus support GetBlock?

[mhps]

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.

[belltown]

Did you guys notice that recommended miner on ypool is rdebourbon's 4.0 now?

Also ypool doesn't link to this thread anymore.

[rdebourbon]

Did you guys notice that recommended miner on ypool is rdebourbon's 4.0 now?

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

[mhps]

Did you guys notice that recommended miner on ypool is rdebourbon's 4.0 now?

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

[rdebourbon]

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..

[mhps]

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.

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..

Is there documentation to descrie how it is done?

[rdebourbon]

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.

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..

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://bitcointalk.org/index.php?topic=323859.0

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..

[mhps]

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.

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..

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.

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".

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://bitcointalk.org/index.php?topic=323859.0

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?

[rdebourbon]

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?

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.

[mhps]

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.

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.

[rdebourbon]

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..

[mhps]

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://bitcointalk.org/index.php?topic=257623.msg3328322#msg3328322 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.

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.

[ssl303]

Can this run on Linux? Also, can -xpm "" deposit to the default "" address?