I think latest rde's Beta miner has some serious issues. I see shares not submitting to the pool all the time. It looks like it's working ok, but shares don't submit way too often then reasonable. Especially 7ch and 8ch. I used both Windows x64 and Windows AVX builds
I think we should go back to mumus or maybe Cabin's build.
Topic: [XPM]unofficial jhPrimeminer thread - page 21. (Read 180178 times)
I need mumus v7.1 for 32bit windows (that can be run under linux wine).
Anyone can provide me that version?
Anyone can provide me that version?
newly compiled 32bit linux version from https://github.com/tandyuk/jhprimeminer
his addresses to donate to/thank him are
XPM: AYwmNUt6tjZJ1nPPUxNiLCgy1D591RoFn4
BTC: 1P6YrvFkwYGcw9sEFVQt32Cn7JJKx4pFG2
https://dl.dropboxusercontent.com/u/105316582/jhprimeminerRDEBeta3-32.gz
Here's a 64bit version, too
https://dl.dropboxusercontent.com/u/105316582/jhprimeminer-RDEbeta3.gz
Seems to be a lot better than running under wine, at least the 64bit version. I only have access to a 32bit virtual machine atm that i compiled it on, and it didn't seem to perform very well, but try it out and let us know how it does. It's still rough. Keyboard input is weird. Have to type a letter and hit enter, and some don't map the same as the wine version. he'll be working on it tomorrow i think.
Thanks,
I'm working to compile tandyuk version on my BAMT machine.
BTW, your 32bit version could not be run under wine.
I need mumus v7.1 for 32bit windows (that can be run under linux wine).
Anyone can provide me that version?
Anyone can provide me that version?
newly compiled 32bit linux version from https://github.com/tandyuk/jhprimeminer
his addresses to donate to/thank him are
XPM: AYwmNUt6tjZJ1nPPUxNiLCgy1D591RoFn4
BTC: 1P6YrvFkwYGcw9sEFVQt32Cn7JJKx4pFG2
https://dl.dropboxusercontent.com/u/105316582/jhprimeminerRDEBeta3-32.gz
Here's a 64bit version, too
https://dl.dropboxusercontent.com/u/105316582/jhprimeminer-RDEbeta3.gz
Seems to be a lot better than running under wine, at least the 64bit version. I only have access to a 32bit virtual machine atm that i compiled it on, and it didn't seem to perform very well, but try it out and let us know how it does. It's still rough. Keyboard input is weird. Have to type a letter and hit enter, and some don't map the same as the wine version. he'll be working on it tomorrow i think.
Thanks,
I'm working to compile tandyuk version on my BAMT machine.
BTW, your 32bit version could not be run under wine.
I have seen twice that my newly found 8-chains share not showing in "share value" display on the upper right of the ypool's page. Both times the display responded to 6-chains and 7-chains like clockwork. So it was not a problem with network or pool's down time. The XPM column in the personal stat page didn't have any change more than 0.001 after the above 8-chains were found. Not all 8-chains are missing. Often they do get counted. (Because my 8-chain/h is less than 1, most times it is the 6-chain/7-chains that contribute to the XPM column. So once an 8-chain is found you can see the result in the XPM column, if it gets counted.)
I am wondering what was happening. I am using one of the unofficial miners. Is it possible that the miner is secretly sending some of the more valuabe shares to another account?
I am wondering what was happening. I am using one of the unofficial miners. Is it possible that the miner is secretly sending some of the more valuabe shares to another account?
More than likely what is happening (and you can verify this by keeping an eye on your miner's output) is that those shares end up invalid for some reason. Most often (for me) the cause of this is finding a share right as a block is solved, causing the share to become outdated.
anyone else get -worse- performance on 64bit linux by compiling the sources yourself for linux? If i compile the source and run the linux ELF binary i get about 4500 pps, if I run version 7.1 (need to update so i get the right share value shown though) through 64-bit wine I get about 7200 pps.... although with the linux version it actually takes about 5 minutes to "auto-configure" the sieving while the windows version doesn't say anything about this to me, that is the configuring part, it does say that auto-config is on.
Just curious...
The auto configure I think is messed up, and if you are using a version that fits it on start up, you might want to do a git pull in the directory and compile it again. He got rid of it auto tuning and it still accept your -c to manually set the L1CacheSize. I suggest checking what your cpu l1 data cache size per cpu is and use that for -c and see if it's better. Was much better for me. Just curious...
I have seen twice that my newly found 8-chains share not showing in "share value" display on the upper right of the ypool's page. Both times the display responded to 6-chains and 7-chains like clockwork. So it was not a problem with network or pool's down time. The XPM column in the personal stat page didn't have any change more than 0.001 after the above 8-chains were found. Not all 8-chains are missing. Often they do get counted. (Because my 8-chain/h is less than 1, most times it is the 6-chain/7-chains that contribute to the XPM column. So once an 8-chain is found you can see the result in the XPM column, if it gets counted.)
I am wondering what was happening. I am using one of the unofficial miners. Is it possible that the miner is secretly sending some of the more valuabe shares to another account?
I am wondering what was happening. I am using one of the unofficial miners. Is it possible that the miner is secretly sending some of the more valuabe shares to another account?
More than likely what is happening (and you can verify this by keeping an eye on your miner's output) is that those shares end up invalid for some reason. Most often (for me) the cause of this is finding a share right as a block is solved, causing the share to become outdated.
I have seen twice that my newly found 8-chains share not showing in "share value" display on the upper right of the ypool's page. Both times the display responded to 6-chains and 7-chains like clockwork. So it was not a problem with network or pool's down time. The XPM column in the personal stat page didn't have any change more than 0.001 after the above 8-chains were found. Not all 8-chains are missing. Often they do get counted. (Because my 8-chain/h is less than 1, most times it is the 6-chain/7-chains that contribute to the XPM column. So once an 8-chain is found you can see the result in the XPM column, if it gets counted.)
I am wondering what was happening. I am using one of the unofficial miners. Is it possible that the miner is secretly sending some of the more valuabe shares to another account?
I am wondering what was happening. I am using one of the unofficial miners. Is it possible that the miner is secretly sending some of the more valuabe shares to another account?
anyone else get -worse- performance on 64bit linux by compiling the sources yourself for linux? If i compile the source and run the linux ELF binary i get about 4500 pps, if I run version 7.1 (need to update so i get the right share value shown though) through 64-bit wine I get about 7200 pps.... although with the linux version it actually takes about 5 minutes to "auto-configure" the sieving while the windows version doesn't say anything about this to me, that is the configuring part, it does say that auto-config is on.
Just curious...
Just curious...
You should probably check 6, preferably 7+ chains per hour over a couple of hours for a descent comparison. Primes per second has been proven to be an inaccurate performance index numerous times
You can also use 4 and 5 chains per hour to determine possibilities for higher chains.
For instance, one of my machines with an AMD Phenom II X4 910 pulls about 5195.19 4ch/h and 499.58 5ch/h.
Using the following maths, you can get a decent idea of higher chains:
Code:
5195.19 / 499.58 = 10.399 (truncated for ease)
6ch.h: 499.58 / 10.399 = 48.04 (41.90 is my real measurement)
7ch: 48.04 / 10.399 = 4.62 (3.95 is real number)
8ch: 4.62 / 10.399 = 0.44 (0.62 is real number)
and so on
6ch.h: 499.58 / 10.399 = 48.04 (41.90 is my real measurement)
7ch: 48.04 / 10.399 = 4.62 (3.95 is real number)
8ch: 4.62 / 10.399 = 0.44 (0.62 is real number)
and so on
upf... the pool was totaly fucked... it's time for any good working solo miner !!!
The pool had a small maintenance outage - no big deal.
upf... the pool was totaly fucked... it's time for any good working solo miner !!!
anyone else get -worse- performance on 64bit linux by compiling the sources yourself for linux? If i compile the source and run the linux ELF binary i get about 4500 pps, if I run version 7.1 (need to update so i get the right share value shown though) through 64-bit wine I get about 7200 pps.... although with the linux version it actually takes about 5 minutes to "auto-configure" the sieving while the windows version doesn't say anything about this to me, that is the configuring part, it does say that auto-config is on.
Just curious...
Just curious...
You should probably check 6, preferably 7+ chains per hour over a couple of hours for a descent comparison. Primes per second has been proven to be an inaccurate performance index numerous times
anyone else get -worse- performance on 64bit linux by compiling the sources yourself for linux? If i compile the source and run the linux ELF binary i get about 4500 pps, if I run version 7.1 (need to update so i get the right share value shown though) through 64-bit wine I get about 7200 pps.... although with the linux version it actually takes about 5 minutes to "auto-configure" the sieving while the windows version doesn't say anything about this to me, that is the configuring part, it does say that auto-config is on.
Just curious...
Just curious...
Difficulty doesn't seem to have numerically changed that much in a coupe of weeks, but two weeks ago I mined 20 coins in a weekend solo. Last week zero. Yesterday switched to pool mining and so far got not even 0.5 XPM mined in 1.5 days!
Seems like tiny numerical changes in difficulty mean big big changes in computational effort required.
Seems like tiny numerical changes in difficulty mean big big changes in computational effort required.
When people talk about reduced performance under Wine, are they running the 64-bit version under Wine64?
I think the big difference is when running 32bit wine. Mine seemed to perform pretty well using wine64. Probably not as well as the linux version, but close.
When people talk about reduced performance under Wine, are they running the 64-bit version under Wine64?
I think I've figured out what is going on - the miner is constantly doing a readline() from the console for accepting user commands, if you detach the process this causes the CPU to spike massively. For increased performance and ease of use, I recommend ditching the readline() at runtime, just have the options settable only via command line args 
+1
Anyone know why this takes more CPU time when you nohup it?
I've got it running on two threads - when running normally, it uses 200% CPU, but when I nohup it with the exact same parameters it uses 300%.
Can't figure it out...
I've got it running on two threads - when running normally, it uses 200% CPU, but when I nohup it with the exact same parameters it uses 300%.
Can't figure it out...
I think I've figured out what is going on - the miner is constantly doing a readline() from the console for accepting user commands, if you detach the process this causes the CPU to spike massively. For increased performance and ease of use, I recommend ditching the readline() at runtime, just have the options settable only via command line args
I've posted a new beta v3.1 that removes the hard coded share values. Share value now only reported on block summary.
I've also created a single dropbox folder for all my releases now - so only a single link to check:
https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
No performance difference to beta v3 only the display update.
I've also created a single dropbox folder for all my releases now - so only a single link to check:
https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
No performance difference to beta v3 only the display update.
Due to many requests I've done AVX and XP-x64 builds of 3.1.. These are both available in the same dropbox folder as before. https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
I can't test the AVX build directly so do not know if its working properly.. XP-x64 should be good though.
Let me know if there's any issues..
Its built for Windows XP x64 /2003 which uses a different platform toolset..
I've posted a new beta v3.1 that removes the hard coded share values. Share value now only reported on block summary.
I've also created a single dropbox folder for all my releases now - so only a single link to check:
https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
No performance difference to beta v3 only the display update.
I've also created a single dropbox folder for all my releases now - so only a single link to check:
https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
No performance difference to beta v3 only the display update.
Due to many requests I've done AVX and XP-x64 builds of 3.1.. These are both available in the same dropbox folder as before. https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
I can't test the AVX build directly so do not know if its working properly.. XP-x64 should be good though.
Let me know if there's any issues..
Anyone know why this takes more CPU time when you nohup it?
I've got it running on two threads - when running normally, it uses 200% CPU, but when I nohup it with the exact same parameters it uses 300%.
Can't figure it out...
I've got it running on two threads - when running normally, it uses 200% CPU, but when I nohup it with the exact same parameters it uses 300%.
Can't figure it out...
Jump to: