Thanks for the quick reply.
Looking forward to seeing how to GPU miner turns out also.
Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 98. (Read 90842 times)
Not yet, i'm focusing at polishing the GPU version, but yeah i'll release a last CPU version with than new fork. Will be variation 11.
To answer your question: No you cannot yet, it's just not implemented yet.
edit : i looked at code, and it seems to be just like Monero v7, let me check more. In such case, nothing to change (except my documentation)
re-edit: Electronero is a slightly modified variation compared to CN-v7 so i still need an update, but it will be an esay one, and backward compatible. Said differently, the Electronero algo will be compatible with Monero, but the opposite is false.
Teaser of GPU version, I'll keep the same principles as for the CPU version:
* at least as fast as Stak/XMrig in worst case, often better[1]
* a lot of exclusive tuning option
* detailled info about what the miner does (allocations of GPU memory, kernel compile...)
* complete cleanup of OpenCL resource at close (like for the Large pages for CPU)
* Instant hashrate, not the max of last few seconds like Claymore (cough.. cheater... cough...)
* So the pool-side hashrate will be displayed hashrate, minus fees, not 10% lower like claymore 10+ [2]
* Targetting at correctness and reliability, no memory access hacks that produce bad hashes
* As a consequence, no CPU re-check[3], if you find a bad share, it will still be sent to your pool
* of course it will be an hybrid miner, able to mine CPU + GPU (or just CPU, or just GPU) on the same pool connection.
[1] It comes at the cost of huge optimizations on the fly, so JCE GPU will take ages to start, and then mine faster. You're warned.
[2] : I loved Claymore 9.7, a masterpiece, then came 10 and 11 that, on all my rigs, produce tons of bad shares and has a 10% lower effective hashrate that what it displays. That's what motivated me to start JCE GPU at the beginning.
Stak and XMRig are decent, both are copies of Wolf0, like Zawawa btw, but both the code and OpenCL contains goofs that made me laugh, so i just rewrote everything, and kept it close source, i won't do the same error than Wolf0 to open source just to see the fees go to copy-paste morons.
[3] That's what Claymore 9.7 did and i go this way : make a miner that just works, and doesn't need re-hash, instead of a broken one + fallback security.
edit : i looked at code, and it seems to be just like Monero v7, let me check more. In such case, nothing to change (except my documentation)
re-edit: Electronero is a slightly modified variation compared to CN-v7 so i still need an update, but it will be an esay one, and backward compatible. Said differently, the Electronero algo will be compatible with Monero, but the opposite is false.
Teaser of GPU version, I'll keep the same principles as for the CPU version:
* at least as fast as Stak/XMrig in worst case, often better[1]
* a lot of exclusive tuning option
* detailled info about what the miner does (allocations of GPU memory, kernel compile...)
* complete cleanup of OpenCL resource at close (like for the Large pages for CPU)
* Instant hashrate, not the max of last few seconds like Claymore (cough.. cheater... cough...)
* So the pool-side hashrate will be displayed hashrate, minus fees, not 10% lower like claymore 10+ [2]
* Targetting at correctness and reliability, no memory access hacks that produce bad hashes
* As a consequence, no CPU re-check[3], if you find a bad share, it will still be sent to your pool
* of course it will be an hybrid miner, able to mine CPU + GPU (or just CPU, or just GPU) on the same pool connection.
[1] It comes at the cost of huge optimizations on the fly, so JCE GPU will take ages to start, and then mine faster. You're warned.
[2] : I loved Claymore 9.7, a masterpiece, then came 10 and 11 that, on all my rigs, produce tons of bad shares and has a 10% lower effective hashrate that what it displays. That's what motivated me to start JCE GPU at the beginning.
Stak and XMRig are decent, both are copies of Wolf0, like Zawawa btw, but both the code and OpenCL contains goofs that made me laugh, so i just rewrote everything, and kept it close source, i won't do the same error than Wolf0 to open source just to see the fees go to copy-paste morons.
[3] That's what Claymore 9.7 did and i go this way : make a miner that just works, and doesn't need re-hash, instead of a broken one + fallback security.
Is it possible to get this to work for the Electroneum May 30th fork? I tried using --variation 3 but it's getting rejected by the pool.
because on CPU cryptonight is latency limited.
it means the performance key is all in the cache. since CN Heavy requires twice the cache, you can compute twice less. the compute itself is also slightly slower, but not that much. it makes a Division, which is a bit slow, nothing more. its round does two memory access instead of one, but it makes half of them.
on gpu latency is bad because we do a lot of random access to glogal vram. a gpu can take a whole second to make a cryptonight round. so cache is negligible, and Heavy impact is very low too
you can see that with the no-cache mode of JCE which is slow as hell (often 3 h/s) but not really slower on Heavy than v7.
about gpu, i'm now working on releasing the gpu version of jce. maybe i'll release a last cpu-only then next will be gpu+cpu.
i'll still provide a cpu-only for those who don't have any opencl gpu.
it means the performance key is all in the cache. since CN Heavy requires twice the cache, you can compute twice less. the compute itself is also slightly slower, but not that much. it makes a Division, which is a bit slow, nothing more. its round does two memory access instead of one, but it makes half of them.
on gpu latency is bad because we do a lot of random access to glogal vram. a gpu can take a whole second to make a cryptonight round. so cache is negligible, and Heavy impact is very low too
you can see that with the no-cache mode of JCE which is slow as hell (often 3 h/s) but not really slower on Heavy than v7.
about gpu, i'm now working on releasing the gpu version of jce. maybe i'll release a last cpu-only then next will be gpu+cpu.
i'll still provide a cpu-only for those who don't have any opencl gpu.
great news!
because on CPU cryptonight is latency limited.
it means the performance key is all in the cache. since CN Heavy requires twice the cache, you can compute twice less. the compute itself is also slightly slower, but not that much. it makes a Division, which is a bit slow, nothing more. its round does two memory access instead of one, but it makes half of them.
on gpu latency is bad because we do a lot of random access to glogal vram. a gpu can take a whole second to make a cryptonight round. so cache is negligible, and Heavy impact is very low too
you can see that with the no-cache mode of JCE which is slow as hell (often 3 h/s) but not really slower on Heavy than v7.
about gpu, i'm now working on releasing the gpu version of jce. maybe i'll release a last cpu-only then next will be gpu+cpu.
i'll still provide a cpu-only for those who don't have any opencl gpu.
It's good news about gpu-version. I'll wait them. Claymore drops dev of CN miner. GGS is in development. SRB-miner is not stable still. Hope your miner will be good! it means the performance key is all in the cache. since CN Heavy requires twice the cache, you can compute twice less. the compute itself is also slightly slower, but not that much. it makes a Division, which is a bit slow, nothing more. its round does two memory access instead of one, but it makes half of them.
on gpu latency is bad because we do a lot of random access to glogal vram. a gpu can take a whole second to make a cryptonight round. so cache is negligible, and Heavy impact is very low too
you can see that with the no-cache mode of JCE which is slow as hell (often 3 h/s) but not really slower on Heavy than v7.
about gpu, i'm now working on releasing the gpu version of jce. maybe i'll release a last cpu-only then next will be gpu+cpu.
i'll still provide a cpu-only for those who don't have any opencl gpu.
because on CPU cryptonight is latency limited.
it means the performance key is all in the cache. since CN Heavy requires twice the cache, you can compute twice less. the compute itself is also slightly slower, but not that much. it makes a Division, which is a bit slow, nothing more. its round does two memory access instead of one, but it makes half of them.
on gpu latency is bad because we do a lot of random access to glogal vram. a gpu can take a whole second to make a cryptonight round. so cache is negligible, and Heavy impact is very low too
you can see that with the no-cache mode of JCE which is slow as hell (often 3 h/s) but not really slower on Heavy than v7.
about gpu, i'm now working on releasing the gpu version of jce. maybe i'll release a last cpu-only then next will be gpu+cpu.
i'll still provide a cpu-only for those who don't have any opencl gpu.
it means the performance key is all in the cache. since CN Heavy requires twice the cache, you can compute twice less. the compute itself is also slightly slower, but not that much. it makes a Division, which is a bit slow, nothing more. its round does two memory access instead of one, but it makes half of them.
on gpu latency is bad because we do a lot of random access to glogal vram. a gpu can take a whole second to make a cryptonight round. so cache is negligible, and Heavy impact is very low too
you can see that with the no-cache mode of JCE which is slow as hell (often 3 h/s) but not really slower on Heavy than v7.
about gpu, i'm now working on releasing the gpu version of jce. maybe i'll release a last cpu-only then next will be gpu+cpu.
i'll still provide a cpu-only for those who don't have any opencl gpu.
Why on CPU heavy algo is twice lower than V7? On GPU's it's use more vmem but speed is the same or higher...
May be it uses twice the cache.
Why on CPU heavy algo is twice lower than V7? On GPU's it's use more vmem but speed is the same or higher...
did you try to add parameter --forever and remove -q if present ?
the principle of the loop in .bat is to close at fixed intervals or at pool error but replacing -q by --forever will not close at pool (or connection) error.
the principle of the loop in .bat is to close at fixed intervals or at pool error but replacing -q by --forever will not close at pool (or connection) error.
Hi man!
I'm trying to mine with multipools.bat now. It's good to especulating
But I'm having the same issues I had in the past (and solved with your help): The miner closes after internet connection's drop. But is a lot more complicated to do the loop inside the multipools.bat to restart mining. What can I do? My DOS abilities are null ;p
I'm trying to mine with multipools.bat now. It's good to especulating
But I'm having the same issues I had in the past (and solved with your help): The miner closes after internet connection's drop. But is a lot more complicated to do the loop inside the multipools.bat to restart mining. What can I do? My DOS abilities are null ;p
JCE displays the total amount of shares it found so far when you press r
the JSON monitoring also gives that info
the JSON monitoring also gives that info
im running monero for few days on MPH i normally see lot more his or credits but know is only showing
53068034 2018-05-27 23:01:43 (UTC) Credit Unconfirmed 1582219 0.00003461
53062347 2018-05-27 22:37:18 (UTC) Credit Unconfirmed 1582207 0.00002205
53057133 2018-05-27 22:31:33 (UTC) Credit Unconfirmed 1582206 0.00002534
53051292 2018-05-27 21:43:42 (UTC) Credit Unconfirmed 1582185 0.00002769
53045492 2018-05-27 21:02:40 (UTC) Credit Confirmed 1582164 0.00003331
53039797 2018-05-27 20:30:19 (UTC) Credit Confirmed 1582149 0.00004278
not sure its a MPH i wish your software would show how many it finds
53068034 2018-05-27 23:01:43 (UTC) Credit Unconfirmed 1582219 0.00003461
53062347 2018-05-27 22:37:18 (UTC) Credit Unconfirmed 1582207 0.00002205
53057133 2018-05-27 22:31:33 (UTC) Credit Unconfirmed 1582206 0.00002534
53051292 2018-05-27 21:43:42 (UTC) Credit Unconfirmed 1582185 0.00002769
53045492 2018-05-27 21:02:40 (UTC) Credit Confirmed 1582164 0.00003331
53039797 2018-05-27 20:30:19 (UTC) Credit Confirmed 1582149 0.00004278
not sure its a MPH i wish your software would show how many it finds
Version 0.29a online - minor revision
About Pause:
It's fair regarding the fees: if you pause the miner K% of the time, the devfee will self lower by K%. Reciprocally, if you pause during a devfee mining, devfee will resume after the pause. In all case, the fee ration is correct.
When you pause, all threads stops, hashrate is zero, but the connection to the Pool remains.
However is you keep paused for too long, the Pool will probably kick you.
Quote
pool address prefix ssl:// supported, and enables SSL in such case
new feature: Pause (key p)
tip about --variation N disaplyed when first share is rejected
more doc in the .zip
fixed and improved auto-config
fixed some integrated wallet detection
new feature: Pause (key p)
tip about --variation N disaplyed when first share is rejected
more doc in the .zip
fixed and improved auto-config
fixed some integrated wallet detection
About Pause:
It's fair regarding the fees: if you pause the miner K% of the time, the devfee will self lower by K%. Reciprocally, if you pause during a devfee mining, devfee will resume after the pause. In all case, the fee ration is correct.
When you pause, all threads stops, hashrate is zero, but the connection to the Pool remains.
However is you keep paused for too long, the Pool will probably kick you.
Thanks, it works
Sure, from the doc:
Here with N=3 it works fine, and i don't think it ever worked with --variation 7 yet, since the fork obviously did not happen yet. Again, that's in the doc
JCE will display this help when the 1st share is rejected, in next version
Quote
Q. I get only bad shares, what happens?
Your coin has probably forked. Add --variation N parameter, with N as listed below, until you find the one that works.
Your coin has probably forked. Add --variation N parameter, with N as listed below, until you find the one that works.
Here with N=3 it works fine, and i don't think it ever worked with --variation 7 yet, since the fork obviously did not happen yet. Again, that's in the doc
Quote
Fork status:
XTL fork code ready but not enabled by default yet, to mine XTL after they fork, add --variation 7
MKT fork enabled in advance, to mine MKT before the fork, add --variation 1
XTL fork code ready but not enabled by default yet, to mine XTL after they fork, add --variation 7
MKT fork enabled in advance, to mine MKT before the fork, add --variation 1
JCE will display this help when the 1st share is rejected, in next version
Using variation 7 to mine XTL, I now have 100% incorrect shares, although I'm using the same mining pools I used to. I don't get why.
No issue with V7 or heavy.
bat file: @echo on
jce_cn_cpu_miner%BITS%.exe --low --auto --variation 7 -o stellite.miner.rocks:5555 -p T****t:t******.com -u Se2******Z62jBLTQ3mg.7000
%SSL% %*
Any idea ?
No issue with V7 or heavy.
bat file: @echo on
jce_cn_cpu_miner%BITS%.exe --low --auto --variation 7 -o stellite.miner.rocks:5555 -p T****t:t******.com -u Se2******Z62jBLTQ3mg.7000
%SSL% %*
Any idea ?
So MPH uses hybrid ports, pretty smart.
the doc you quote is for Claymore, jce behaves the same with or without ssl, it's clearly said in my doc
but disconnect trick is good to know
i'll auto-enable SSL when the pool starts by "ssl://" in next version 0.29a
the doc you quote is for Claymore, jce behaves the same with or without ssl, it's clearly said in my doc
Quote
Q. Do I get a discount on fees if I use SSL?
I'm not Claymore.
I'm not Claymore.
but disconnect trick is good to know
i'll auto-enable SSL when the pool starts by "ssl://" in next version 0.29a
NsGpuCNMiner.exe -pow7 1 -xpool ssl://us-east.cryptonight-hub.miningpoolhub.com:20580 -xwal username.workername -xpsw x
Add "-pow7 1" option to support Monero hardfork(hardfork activation height: 1546000).
FYI, "ssl://" is specified for secure network connection.
You can mine without this option but it is recommended to use because Claymore miner's devfee gets lower with this.
Also, it would help some outer firewall disconnection issues time to time.
Add "-pow7 1" option to support Monero hardfork(hardfork activation height: 1546000).
FYI, "ssl://" is specified for secure network connection.
You can mine without this option but it is recommended to use because Claymore miner's devfee gets lower with this.
Also, it would help some outer firewall disconnection issues time to time.
You forgot --ssl
??In my example on MPH above, no need for SSL, the port 20580 is not a SSL port.
Now preparing minor revision 0.29a
Code:
New command: p for Pause (will stop mining but not disconnect from pool)
Fixed and improved autoconfig
Fixed and improved autoconfig
You forgot --ssl
Jump to: