now focusing on: Linux version
Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 103. (Read 90842 times)
now focusing on: Linux version
Updated.
Thanks, now intense coin mines without problems. Quote
Done, parameter --stakjson
Great , that's all right, that's all right.
Sure, already did, and i confirm:
* INTS has forked to Monero-V7
* 0.27c will autofork to this
* You can already use older JCE by adding param: --variation 3
Note the documentation covered this case:
* INTS has forked to Monero-V7
* 0.27c will autofork to this
* You can already use older JCE by adding param: --variation 3
Note the documentation covered this case:
Can you add MarketCash coin to JCE Miner?
Done.i am trying to mine alloy but i cannot set it up to work, i get low value shares reject, whatever variation i used it didnt work. alloy forked few days ago
Alloy fork added, automatic when mining Alloy, manual override if you want: --variation 8Quote
Please, don't forget to check intense coin.
Updated. hi all !
json stak : yeah nice idea, a stak mode for json filled with dummy values when not exists, ok i'll go that way
Intense: maybe they forked, parameter --variation N should allow to force new fork. i'll try.
Alloy: as said in my previous post, adding Alloy fork is next planned feature. should be ready very soon
MarketCash: ok, but you can already mine it with parameter --any --variation N with N in 1-7 (find the N that works, there's a list in the Github page doc)
reconnect : parameter --forever is exactly what you need
edit: Well, i'm not happy with that, but that's a pragmatic choice, I add a JSON mode which emulates 99% of data like Stak, including the shitty indentation and the useless data of biggest shares and ping. It was pretty easy to add to JCE netcode. However the 3 levels of hashrate will be the same, and the highest will be the instant hashrate. Except that, it should be compatible with stak.
next version on the way
* Marketcash coin: done
* Stak compatibility: done, will be parameter --stakjson
* Alloy fork: to do, will be parameter --variation 8
Please, don't forget to check intense coin. json stak : yeah nice idea, a stak mode for json filled with dummy values when not exists, ok i'll go that way
Intense: maybe they forked, parameter --variation N should allow to force new fork. i'll try.
Alloy: as said in my previous post, adding Alloy fork is next planned feature. should be ready very soon
MarketCash: ok, but you can already mine it with parameter --any --variation N with N in 1-7 (find the N that works, there's a list in the Github page doc)
reconnect : parameter --forever is exactly what you need
edit: Well, i'm not happy with that, but that's a pragmatic choice, I add a JSON mode which emulates 99% of data like Stak, including the shitty indentation and the useless data of biggest shares and ping. It was pretty easy to add to JCE netcode. However the 3 levels of hashrate will be the same, and the highest will be the instant hashrate. Except that, it should be compatible with stak.
next version on the way
* Marketcash coin: done
* Stak compatibility: done, will be parameter --stakjson
* Alloy fork: to do, will be parameter --variation 8
hi all !
json stak : yeah nice idea, a stak mode for json filled with dummy values when not exists, ok i'll go that way
Intense: maybe they forked, parameter --variation N should allow to force new fork. i'll try.
Alloy: as said in my previous post, adding Alloy fork is next planned feature. should be ready very soon
MarketCash: ok, but you can already mine it with parameter --any --variation N with N in 1-7 (find the N that works, there's a list in the Github page doc)
reconnect : parameter --forever is exactly what you need
edit: Well, i'm not happy with that, but that's a pragmatic choice, I add a JSON mode which emulates 99% of data like Stak, including the shitty indentation and the useless data of biggest shares and ping. It was pretty easy to add to JCE netcode. However the 3 levels of hashrate will be the same, and the highest will be the instant hashrate. Except that, it should be compatible with stak.
next version on the way
* Marketcash coin: done
* Stak compatibility: done, will be parameter --stakjson
* Alloy fork: to do, will be parameter --variation 8
json stak : yeah nice idea, a stak mode for json filled with dummy values when not exists, ok i'll go that way
Intense: maybe they forked, parameter --variation N should allow to force new fork. i'll try.
Alloy: as said in my previous post, adding Alloy fork is next planned feature. should be ready very soon
MarketCash: ok, but you can already mine it with parameter --any --variation N with N in 1-7 (find the N that works, there's a list in the Github page doc)
reconnect : parameter --forever is exactly what you need
edit: Well, i'm not happy with that, but that's a pragmatic choice, I add a JSON mode which emulates 99% of data like Stak, including the shitty indentation and the useless data of biggest shares and ping. It was pretty easy to add to JCE netcode. However the 3 levels of hashrate will be the same, and the highest will be the instant hashrate. Except that, it should be compatible with stak.
next version on the way
* Marketcash coin: done
* Stak compatibility: done, will be parameter --stakjson
* Alloy fork: to do, will be parameter --variation 8
hi admin,hi everyone, i am trying to mine alloy but i cannot set it up to work, i get low value shares reject, whatever variation i used it didnt work. alloy forked few days ago so i think that might be a problem. i tried to set up 0.25 and 0.27 miner but on both of them i get rejected shares.for example when i set it up for mining trtl it works fine. help pls
Hi,
Can you add MarketCash coin to JCE Miner?
Thank you!
https://github.com/MarketCashME/marketcash
https://www.marketcash.io
Can you add MarketCash coin to JCE Miner?
Thank you!
https://github.com/MarketCashME/marketcash
https://www.marketcash.io
Pool intense.hashvault.pro tried ports 80 and 443 (ssl). Coins Intense (ITNS). Allways poool rejects shares - low difficaulty share.
Maybe Intense have forked?
Maybe Intense have forked?
Quote
next things planned:
* json closer (but not same) to stak
* json closer (but not same) to stak
It is good even if it looks like json xmr-stak, not necessarily exactly
hi all !
json : lots of values from xmrstak just don't exist in jce, i don't measure ping for example, that's a miner, not a Quake server. i could make something closer but not the same.
I claim continuously that jce is not a fork of xmrstak, on purpose, so i'd prefer avoid disguising jce into stak.
the clean way would be to have mining tools adapted to jce json, like Forager did.
i however note some good ideas from stak json, like telling the fee level, aes, version or wallet.
i'll add that, but not things like best share values, that's cosmetical and useless i don't want jce spend compute power managing that.
no fork autoswitch, i know xmrig does it, that's very smart, but it's a lot of code for a feature that's useful once per year. and technically in jce that's the --variation switch that's the Master fork switch, nothing dynamic. the fork is chosen before connection to the pool, i guess xmrig does the opposite.
effective is the net Hashrate, the same that's reported by your pool. from the physical Hashrate (total) it deduces/add fees, bad/good luck and outdated shares. mathematically it converges to the physical Hashrate on the long term, since mining is a random game.
if you mine 90000 worth of shares in 600s, so effective is 90000/600 = 150 H/s
kicked : try new parameter --forever to retry to connect forever (5s between each attempt)
next things planned:
* json closer (but not same) to stak
* Alloy fork (will be --variation 8 )
* linux version, to answer Moonman
json : lots of values from xmrstak just don't exist in jce, i don't measure ping for example, that's a miner, not a Quake server. i could make something closer but not the same.
I claim continuously that jce is not a fork of xmrstak, on purpose, so i'd prefer avoid disguising jce into stak.
the clean way would be to have mining tools adapted to jce json, like Forager did.
i however note some good ideas from stak json, like telling the fee level, aes, version or wallet.
i'll add that, but not things like best share values, that's cosmetical and useless i don't want jce spend compute power managing that.
no fork autoswitch, i know xmrig does it, that's very smart, but it's a lot of code for a feature that's useful once per year. and technically in jce that's the --variation switch that's the Master fork switch, nothing dynamic. the fork is chosen before connection to the pool, i guess xmrig does the opposite.
effective is the net Hashrate, the same that's reported by your pool. from the physical Hashrate (total) it deduces/add fees, bad/good luck and outdated shares. mathematically it converges to the physical Hashrate on the long term, since mining is a random game.
if you mine 90000 worth of shares in 600s, so effective is 90000/600 = 150 H/s
kicked : try new parameter --forever to retry to connect forever (5s between each attempt)
next things planned:
* json closer (but not same) to stak
* Alloy fork (will be --variation 8 )
* linux version, to answer Moonman
An xmrstak compatible JSON output can be useful for using existing remote monitoring applications. You may use a static value for unused variables.
Hi!
At some PC I see like thise in log:
after thise miner is closed
In one network 4 PC continued to work and 2 is closed JCE, can you recommend what to do and how not to close the miner in such situations
THNX!
At some PC I see like thise in log:
Quote
01:02:13 | Accepted by the pool.
01:02:33 | Pool changes Difficulty to 5000.
01:03:07 | Thread 3 finds a Share, value 5000
01:03:11 | Thread 4 finds a Share, value 5000
01:03:11 | Thread 4 finds a Share, value 5000
01:03:19 | Connection failed: Pool response timeout.
01:03:19 | Connection interrupted, waiting 5s then retry.
01:03:21 | Hashrate Thread 0: 2.98 h/s
01:03:21 | Hashrate Thread 1: 2.98 h/s
01:03:21 | Hashrate Thread 2: 51.92 h/s
01:03:21 | Hashrate Thread 3: 52.09 h/s
01:03:21 | Hashrate Thread 4: 52.12 h/s
01:03:21 | Hashrate Thread 5: 52.11 h/s
01:03:21 | Hashrate Thread 6: 51.79 h/s
01:03:21 | Hashrate Thread 7: 2.99 h/s
01:03:21 | Hashrate Thread 8: 2.99 h/s
01:03:21 | Hashrate Thread 9: 2.99 h/s
01:03:21 | Hashrate Thread 10: 2.96 h/s
01:03:21 | Hashrate Thread 11: 2.92 h/s
01:03:21 | Total: 280.78 h/s
01:03:23 | Connecting to mining pool loki.miner.rocks:5555 ...
01:03:31 | Connection failed: Socked connect error: DNS resolve failed.
01:03:31 | Connection interrupted, waiting 5s then retry.
01:03:36 | Connecting to mining pool loki.miner.rocks:5555 ...
01:03:42 | Connection failed: Socked connect error: DNS resolve failed.
01:03:42 | Connection interrupted, waiting 5s then retry.
01:03:47 | Connecting to mining pool loki.miner.rocks:5555 ...
01:03:57 | Connection failed: Socked connect error: DNS resolve failed.
01:03:57 | Connection interrupted, waiting 5s then retry.
01:04:02 | Connecting to mining pool loki.miner.rocks:5555 ...
01:04:11 | Connection failed: Socked connect error: DNS resolve failed.
01:04:11 | Maximum pool connection attempts reached, give up and quit.
01:04:11 | Large Page Scratchpad 4MB Buffer 000001cfc7e00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8600000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc7600000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc7a00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8200000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc9200000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc7200000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8a00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8e00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc9a00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc6e00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc9600000 released.
01:04:12 | Pool connection socket closed.
01:04:12 | Mining thread 0 stopped.
01:04:12 | Mining thread 1 stopped.
01:04:12 | Mining thread 2 stopped.
01:04:12 | Mining thread 3 stopped.
01:04:12 | Mining thread 4 stopped.
01:04:12 | Mining thread 5 stopped.
01:04:12 | Mining thread 6 stopped.
01:04:12 | Mining thread 7 stopped.
01:04:12 | Mining thread 8 stopped.
01:04:12 | Mining thread 9 stopped.
01:04:12 | Mining thread 10 stopped.
01:04:12 | Mining thread 11 stopped.
01:04:12 | Shared Large Page 000001cfc6c00000 released.
01:02:33 | Pool changes Difficulty to 5000.
01:03:07 | Thread 3 finds a Share, value 5000
01:03:11 | Thread 4 finds a Share, value 5000
01:03:11 | Thread 4 finds a Share, value 5000
01:03:19 | Connection failed: Pool response timeout.
01:03:19 | Connection interrupted, waiting 5s then retry.
01:03:21 | Hashrate Thread 0: 2.98 h/s
01:03:21 | Hashrate Thread 1: 2.98 h/s
01:03:21 | Hashrate Thread 2: 51.92 h/s
01:03:21 | Hashrate Thread 3: 52.09 h/s
01:03:21 | Hashrate Thread 4: 52.12 h/s
01:03:21 | Hashrate Thread 5: 52.11 h/s
01:03:21 | Hashrate Thread 6: 51.79 h/s
01:03:21 | Hashrate Thread 7: 2.99 h/s
01:03:21 | Hashrate Thread 8: 2.99 h/s
01:03:21 | Hashrate Thread 9: 2.99 h/s
01:03:21 | Hashrate Thread 10: 2.96 h/s
01:03:21 | Hashrate Thread 11: 2.92 h/s
01:03:21 | Total: 280.78 h/s
01:03:23 | Connecting to mining pool loki.miner.rocks:5555 ...
01:03:31 | Connection failed: Socked connect error: DNS resolve failed.
01:03:31 | Connection interrupted, waiting 5s then retry.
01:03:36 | Connecting to mining pool loki.miner.rocks:5555 ...
01:03:42 | Connection failed: Socked connect error: DNS resolve failed.
01:03:42 | Connection interrupted, waiting 5s then retry.
01:03:47 | Connecting to mining pool loki.miner.rocks:5555 ...
01:03:57 | Connection failed: Socked connect error: DNS resolve failed.
01:03:57 | Connection interrupted, waiting 5s then retry.
01:04:02 | Connecting to mining pool loki.miner.rocks:5555 ...
01:04:11 | Connection failed: Socked connect error: DNS resolve failed.
01:04:11 | Maximum pool connection attempts reached, give up and quit.
01:04:11 | Large Page Scratchpad 4MB Buffer 000001cfc7e00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8600000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc7600000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc7a00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8200000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc9200000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc7200000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8a00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc8e00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc9a00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc6e00000 released.
01:04:12 | Large Page Scratchpad 4MB Buffer 000001cfc9600000 released.
01:04:12 | Pool connection socket closed.
01:04:12 | Mining thread 0 stopped.
01:04:12 | Mining thread 1 stopped.
01:04:12 | Mining thread 2 stopped.
01:04:12 | Mining thread 3 stopped.
01:04:12 | Mining thread 4 stopped.
01:04:12 | Mining thread 5 stopped.
01:04:12 | Mining thread 6 stopped.
01:04:12 | Mining thread 7 stopped.
01:04:12 | Mining thread 8 stopped.
01:04:12 | Mining thread 9 stopped.
01:04:12 | Mining thread 10 stopped.
01:04:12 | Mining thread 11 stopped.
01:04:12 | Shared Large Page 000001cfc6c00000 released.
after thise miner is closed
In one network 4 PC continued to work and 2 is closed JCE, can you recommend what to do and how not to close the miner in such situations
THNX!
hi all !
json : lots of values from xmrstak just don't exist in jce, i don't measure ping for example, that's a miner, not a Quake server. i could make something closer but not the same.
I claim continuously that jce is not a fork of xmrstak, on purpose, so i'd prefer avoid disguising jce into stak.
the clean way would be to have mining tools adapted to jce json, like Forager did.
i however note some good ideas from stak json, like telling the fee level, aes, version or wallet.
i'll add that, but not things like best share values, that's cosmetical and useless i don't want jce spend compute power managing that.
no fork autoswitch, i know xmrig does it, that's very smart, but it's a lot of code for a feature that's useful once per year. and technically in jce that's the --variation switch that's the Master fork switch, nothing dynamic. the fork is chosen before connection to the pool, i guess xmrig does the opposite.
effective is the net Hashrate, the same that's reported by your pool. from the physical Hashrate (total) it deduces/add fees, bad/good luck and outdated shares. mathematically it converges to the physical Hashrate on the long term, since mining is a random game.
if you mine 90000 worth of shares in 600s, so effective is 90000/600 = 150 H/s
kicked : try new parameter --forever to retry to connect forever (5s between each attempt)
next things planned:
* json closer (but not same) to stak
* Alloy fork (will be --variation 8 )
* linux version, to answer Moonman
json : lots of values from xmrstak just don't exist in jce, i don't measure ping for example, that's a miner, not a Quake server. i could make something closer but not the same.
I claim continuously that jce is not a fork of xmrstak, on purpose, so i'd prefer avoid disguising jce into stak.
the clean way would be to have mining tools adapted to jce json, like Forager did.
i however note some good ideas from stak json, like telling the fee level, aes, version or wallet.
i'll add that, but not things like best share values, that's cosmetical and useless i don't want jce spend compute power managing that.
no fork autoswitch, i know xmrig does it, that's very smart, but it's a lot of code for a feature that's useful once per year. and technically in jce that's the --variation switch that's the Master fork switch, nothing dynamic. the fork is chosen before connection to the pool, i guess xmrig does the opposite.
effective is the net Hashrate, the same that's reported by your pool. from the physical Hashrate (total) it deduces/add fees, bad/good luck and outdated shares. mathematically it converges to the physical Hashrate on the long term, since mining is a random game.
if you mine 90000 worth of shares in 600s, so effective is 90000/600 = 150 H/s
kicked : try new parameter --forever to retry to connect forever (5s between each attempt)
next things planned:
* json closer (but not same) to stak
* Alloy fork (will be --variation 8 )
* linux version, to answer Moonman
Any update on a Linux version?
Will be fixed soon, this bug occurs in a pretty rare case, the AVX2 instruction is enabled by autoconfig only for CN-Heavy.
edit: next features
* http server to ease integration into 3rd party tools
edit: 0.27a online - minor revision
fix AVX2 and add --forever parameter
also merge the Monero forks, and stepback XTL to CN-v7, will be XTL-fork later
Will the miner have to be restarted for XTL fork ?
I tried Loki, due to my current weak CPU, i've been kicked out of the community pool after 30mn or so. I'll get my Ryzen 2400G monday, at long last....
Version 0.27b done, entering test phase.
New feature : HTTP Local Server
new parameter: --mport P (P in [1:65535])
default: disabled
simple JSON output, somehow human readable
New feature : HTTP Local Server
new parameter: --mport P (P in [1:65535])
default: disabled
simple JSON output, somehow human readable
And it was possible to make json compatible with xmr-stak or xmrig cpu?
Code:
{"version":"xmr-stak/2.4.3/26a5d65f/master/win/nvidia-amd-cpu/aeon-cryptonight-monero/20","hashrate":{"threads":[[21.0,22.4,null],[22.7,22.8,null]],"total":[43.7,45.1,null],"highest":46.9},"results":{"diff_current":606,"shares_good":2,"shares_total":2,"avg_time":31.5,"hashes_total":2126,"best":[6258,1362,0,0,0,0,0,0,0,0],"error_log":[]},"connection":{"pool": "xmr.pool.minergate.com:45700","uptime":63,"ping":64,"error_log":[]}}
Code:
{
"id": "6104bea31afab1dc",
"worker_id": "Home",
"version": "2.5.3",
"kind": "cpu",
"ua": "XMRig/2.5.3 (Windows NT 6.1; Win64; x64) libuv/1.19.0 gcc/7.3.0",
"cpu": {
"brand": "Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz",
"aes": false,
"x64": true,
"sockets": 1
},
"algo": "cryptonight",
"hugepages": true,
"donate_level": 5,
"hashrate": {
"total": [
37.34,
0.0,
0.0
],
"highest": 0.0,
"threads": [
[
16.95,
0.0,
0.0
],
[
20.38,
0.0,
0.0
]
]
},
"results": {
"diff_current": 1063,
"shares_good": 0,
"shares_total": 0,
"avg_time": 0,
"hashes_total": 0,
"best": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"error_log": []
},
"connection": {
"pool": "xmr.pool.minergate.com:45700",
"uptime": 3,
"ping": 0,
"failures": 0,
"error_log": []
}
}for example , you do not have ping, miner version, donate level, shares_good, shares_total, avg_time, hashes_total.
Can you add that? and what is effective ?
Version 0.27b done, entering test phase.
New feature : HTTP Local Server
new parameter: --mport P (P in [1:65535])
default: disabled
simple JSON output, somehow human readable
example:
edit:
0.27b online - minor revision
change: HTTP server to get monitoring json.
Updated documentation.
No other change.
New feature : HTTP Local Server
new parameter: --mport P (P in [1:65535])
default: disabled
simple JSON output, somehow human readable
example:
Code:
{
"hashrate":
{
"thread_0": 13.75,
"thread_1": 18.29,
"thread_2": 21.19,
"thread_3": 18.85,
"total": 72.06
},
"result":
{
"pool": "pool.minexmr.com:4444",
"ssl": false,
"currency": "Monero (XMR/XMV/XMC/XMO)",
"difficulty": 23684,
"shares": 5,
"hashes": 84473,
"uptime": "0:08:28",
"effective": 166.29
}
}edit:
0.27b online - minor revision
change: HTTP server to get monitoring json.
Updated documentation.
No other change.
Will be fixed soon, this bug occurs in a pretty rare case, the AVX2 instruction is enabled by autoconfig only for CN-Heavy.
edit: next features
* http server to ease integration into 3rd party tools
edit: 0.27a online - minor revision
fix AVX2 and add --forever parameter
also merge the Monero forks, and stepback XTL to CN-v7, will be XTL-fork later
Will be fixed soon, this bug occurs in a pretty rare case, the AVX2 instruction is enabled by autoconfig only for CN-Heavy.
edit: next features
* http server to ease integration into 3rd party tools
edit: 0.27a online - minor revision
fix AVX2 and add --forever parameter
also merge the Monero forks, and stepback XTL to CN-v7, will be XTL-fork later
Unclewish: ok got it, but that's a special case, autoconfig aims to give max perf in a rig condition.
Stellite: that's a planned fork, today XTL still use CN-v7, but jce 0.27 already flag it as forked. keep 0.25 or use 0.27 with --variation 3 until XTL really forks.
Stellite: that's a planned fork, today XTL still use CN-v7, but jce 0.27 already flag it as forked. keep 0.25 or use 0.27 with --variation 3 until XTL really forks.
Jump to: