Author

Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 112. (Read 90841 times)

jr. member
Activity: 37
Merit: 5
IPBC good auto fork (0.24 badly chose v7, while IPBC is CN-classic)
IPBC still not working. The forked coin is not CN-classic! The hashrate of the official ipbc-miner indicates, that it is Cryptonight-lite, but it is neither CN-lite-AEON, nor CN-lite-V7. It must be something else  Cry

And AMD FX-8350 is detected as Kuma instead of Vishera. Besides, the code the miner uses with auto is generic_sse3. When I set the CPU to vishera manually, it uses generic_aes.
With SumoCoin (Cryptonight-Heavy) the miner chooses 2 threads for AMD FX-8350, reaching ~115 H/s. But since FX has exclusive cache architecture with 4x 2 MB L2 + 1x 8 MB L3, it is better so use 4 threads to fill both cache levels. Then the FX-8350 reaches 216 H/s with CN-heavy.
member
Activity: 350
Merit: 22
Correct, you're not the first to point out that issue, my argument is that the coin detection allows to choose the fork automatically and format good log, and provide a good error in case of bad wallet, because forwarding the check to the pool may pass for a jce netcode bug, and i want to avoid getting reported such wrong bugs.

If the pool doesn't report the bad wallet, it may occur, and the miner guy never gets his coins, i don't want to be accused to have stolen them.

Also the cryptonote coin list is not infinite and i add them quickly on demand. If your coin is not listed yet, just ask Wink

I'm thinking about adding the "unknown coin" to handle them all, but i'd rather prefer making a complete list and keep the mandatory checking.

btw i've let jce 0.24a mine all day, on nicehash and normal pool, both zero bad shares so far.
full member
Activity: 1179
Merit: 131
that parameter already exists: --variation
please read first post or github page

Correct but the parameter is pointless if you want to mine one of the supported algos but the coin doesn't show up in the list of supported currencies.  A wallet format that the miner doesn't recognize shouldn't prevent the use of miner.  Most pools won't even let a miner connect if they are using an invalid address.

member
Activity: 350
Merit: 22
I'm preparing version 0.24a, a hotfix of the 0.2x

Code:
Fixed bad shares (finally, i hope...)
IPBC good auto fork (0.24 badly chose v7, while IPBC is CN-classic)
Better autoconfig for CPU with 3M cache (defaults to 2 threads, which is better)

Virus, trojan, backdoor... nope, absolutly nothing malicious in JCE, it's a miner, period. I don't even try to know how many people use my miner, to mine what, where, or anything. Not a single byte is written to your disk (except log (default=disabled) of course, and Large Page autoconfig when needed) nor sent to anybody, except to mine coins on pools.

But that's fair: all miners are detected as virus/trojan : stak, claymore... jce is no exception.
Note the attrib trick to be stealthier, on purpose. That's a documented feature, in case you wonder. See bottom of first post.

edit 0.24a online
I found a huge bug in Cryptonight Heavy SSE2/3 x64 (but was ok on SSE4 and AES, and 32bits)
I reverted the netcode changes since 0.20, except the 64-threads max limit, still 64
member
Activity: 350
Merit: 22
--variation 3 works fine but just 3% fast than xmrig
--variation 4 has a problems
Rejected by the pool.
Message from the pool: Low difficulty share
--variation 4 280% fast than xmrig
I want use --variation 4

Seems we misunderstood : variation is not the xmrig term, where it means "dualhash" or not.
on JCE the variation is the algo fork.
Code:
    N=1 Original Cryptonight
    N=2 Original Cryptolight (for AEON)
    N=3 Cryptonight V7 fork of April-2018
    N=4 Cryptolight V7 fork of April-2018
    N=5 Cryptonight-Heavy

4 is super fast because it's cryptolight, twice less computation to do.
the best you can do is --variation 3 with AES 64-bits, with +3% perfs. Even fees deduced, that's still the most efficient miner for CPU so far.

And it still need to fix it Cry
newbie
Activity: 3
Merit: 0
--variation 3 works fine but just 3% fast than xmrig
--variation 4 has a problems
Rejected by the pool.
Message from the pool: Low difficulty share
--variation 4 280% fast than xmrig
I want use --variation 4
newbie
Activity: 3
Merit: 0
2nodes 4 x 6267
member
Activity: 350
Merit: 22
that parameter already exists: --variation
please read first post or github page

currently investigating the regression

edit:
My miners  4xOpteron 6276 128 cores
Very Fast
BUT Allmost
Rejected by the pool.
Message from the pool: Low difficulty share
Sometimes Accepted
So same as not work.

Seems that's the increase from 32 to 64 max threads that broke everything, the bug being more or less bad if you have a lot of threads. 128 threads (probably 2x64) is certainly the worst case. Still investigating more.
full member
Activity: 1179
Merit: 131
Seems like this miner has the same issue that the Claymore miner used to have (or maybe still has it, not sure):  It maps the algo based on the wallet address you are using.  I think there should be an option to manually specify the algo you want to use.  I am trying to mine a coin based on cryptonight v7 but it is failing to even start because the miner doesn't recognize the address.
sr. member
Activity: 826
Merit: 302
And I think you have to look at the IPBC code, as well. Shares get rejected immediately.

because IPBC don`t use "IPBC support (v7)" it is ultra heavy algo, but hash like cryptonight lite and only ipbc now have that cryptonight algo  Cheesy
jr. member
Activity: 37
Merit: 5
And I think you have to look at the IPBC code, as well. Shares get rejected immediately.
member
Activity: 350
Merit: 22
Mmh... so i really broke Something, can you copy me the first lines of log so i see what assembly is broken ?
and whether you use Nicehash or not.

i add a warning on first page. thanks for reporting

double threads on the way but need to fix the bad hashes first

edit : i revert release to 0.20 until i fix the regression, please retry with 0.20, it should be fine, just don't use dualthread mode (which is pretty useless, btw)
newbie
Activity: 3
Merit: 0
My miners  4xOpteron 6276 128 cores
Very Fast
BUT Allmost
Rejected by the pool.
Message from the pool: Low difficulty share
Sometimes Accepted
So same as not work.
sr. member
Activity: 1484
Merit: 253
Please make low power mode - double threads.
member
Activity: 350
Merit: 22
Nice !
I note to autoswitch miningrigrentals to v7 in next release.
I've been reported broken hashes when using Nicehash on 0.21+, now testing... Cry

edit : done 0.24 online

Code:
IPBC support (v7)
MiningRigRentals autoswitch to v7
Blind fix for Nicehash, better update if you use 0.21+
newbie
Activity: 35
Merit: 0

About miningrigrentals, try force v7 with --variation 3
Thanks, it works.
coin - xmr, x64
member
Activity: 350
Merit: 22
IPBC Coin to be added, noted

About miningrigrentals, try force v7 with --variation 3

Invalid shares : What mode ? What coin ? Aes or not, 32 or 64 bits ? The first few lines of the log would help Smiley
Assembly code is fragile, no compiler to check syntax, very possible I broke something Sad
newbie
Activity: 35
Merit: 0

If your coin is missing, just ask and I add it.
Now compiling 0.22 with exactly the same request : to add CrepCoin and PluraCoin. And MiningRigRentals.

Edit : done, 0.22 online

MiningRigRentals support
Now NtgthMiningRigRentals is connected without error messages, but the share does not accept, there is a re-link with the pool.

Quote
16:16:04 | Connected to pool. Now logging in...
16:16:05 | Successfuly logged as Dmitr69.545657
16:16:05 | Pool changes Difficulty to 25000.
16:16:11 | Hashrate Thread 0: 34.57 h/s
16:16:11 | Hashrate Thread 1: 35.88 h/s
16:16:11 | Hashrate Thread 2: 36.49 h/s
16:16:11 | Total: 106.94 h/s
16:17:02 | Pool changes Difficulty to 17241.
16:17:05 | Pool sends a new Job.
16:17:33 | Pool sends a new Job.
16:20:02 | Pool changes Difficulty to 5109.
16:20:29 | Thread 2 finds a Share, value 5109
16:20:29 | Connection failed: Socked receive error: socket explicitly closed by the pool
16:20:29 | Connection interrupted, waiting 5s then retry.
16:20:34 | Connecting to mining pool eu-ru01.miningrigrentals.com:3333 ...
16:20:34 | Connected to pool. Now logging in...
16:20:35 | Successfuly logged as Dmitrii.83858
16:20:35 | Pool changes Difficulty to 25000.
jr. member
Activity: 196
Merit: 1
Lynfield detect should be fixed in 0.21+, but I couldn't test since I don't own one. Same for the avx detection. My cpu detect really need fixes, even if it's not blocking, and your can override manually with --archi parameter.

B2BCoin to be added ok. I'll add freelabit too.

The hashrate is very sensitive to pc activity. On a rig, it tends to be stable, but on a real life pc It will drop even when you scroll your files. Jce never runs at high priority, even without --low. if you run it on a pc with no other software running, windows update, Superfetch, and Al. disabled, hashrates should be max and stable.

May launch it without --low with
Code:
start /HIGH jce....

To give it high priority

Edit: Jce GPU exists as a prototype, I mine with it on my rx500, but absolutely not ready for diffusion yet. In opposition to other miners, I did not reused Wolf0 opencl, but wrote a brand new one (but still in opencl, not CGN assembly). Wolf0 code contains goofs so blatant that it's funny... I beat it on every gpu, but not always Claymore, which is faster, just Claymore 10+ tends to generate a lot of bad shares while 9.7 was a masterpiece of quality. What happened to Claymore ? And 11.3 is the giveup version, it's free but no longer maintained.

Tell me if you're interested into a jce amd, I may finish it and release. Wink

Thanks alot mate Smiley Nice job to be honest! Btw I do get invalid shares with 0.21 and 0.23 as well today. It does not happen previously. Do I need to make few changes?
Jump to: