Pages:
Author

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

member
Activity: 350
Merit: 22
Hello all,

Sorry i've very little time to do the support here, i'm polishing the GPU version g
I'll skip some new features for now to save dev and test time, and just focus on the Warmup fix and CN-Heavy perf boost.

No problem to add a new coin, and as it has been said, it can already be mined with parameters
-- variation 5 --any

any allow to mine anything, 5 is CN-Heavy fork in JCE, complete list is:
Code:

 1 = Original Cryptonight
 2 = Original Cryptolight
 3 = Cryptonight V7 fork of April-2018
 4 = Cryptolight V7 fork of April-2018
 5 = Cryptonight-Heavy
 6 = Cryptolight-IPBC
 7 = Cryptonight-XTL fork of May-2018
 8 = Cryptonight-Alloy
 9 = Cryptonight-MKT
10 = Cryptonight-Arto
11 = Cryptonight-Fast MSR fork of June-2018
12 = Cryptonight-Haven fork of June-2018
13 = Cryptonight-BitTube v2 of July-2018

Online is the
0.32g CPU Linux 32/64

with netcode fixes, no other change

edit:
My new warm-up sequence gives very good result on my Pitcairn rig, the one where the bug was the most obvious.
I think it fixes, at the cost of a very instable hashrate during the first 5 min (on purpose)
newbie
Activity: 54
Merit: 0
You can use the option --any to mine any coin without wallet address syntax checking.
copper member
Activity: 42
Merit: 0
Quote


    Monero (XMR)
    Monero-V (XMV)
    Electroneum (ETN)
    Karbowanec (KRB)
    Bytecoin (BCN)
    Sumokoin (SUMO)
    Bitcoal (COAL)
    Bitcedi (BXC)
    Dinastycoin (DCY)
    Leviarcoin (XLC)
    Fonero (FNO)
    Turtlecoin (TRTL)
    Graft (GRFT)
    Dero (DERO)
    Stellite (XTL)
    UltraNote (XUN)
    Intense (INTS)
    Crepcoin (CREP)
    Pluracoin (PLURA)
    Haven (XHV)
    FreelaBit (FBF)
    BlueberriesCoin (BBC)
    B2BCoin (B2B)
    Bitsum (BSM)
    Masari (MSR)
    SuperiorCoin (SUP)
    EDollar (EDL)
    Interplanetary Broadcast (IPBC)
    Alloy (XAO)
    BBSCoin (BBS)
    BitcoiNote (BTCN)
    Elya (ELYA)
    Iridium (IRD)
    Italo (ITA)
    Lines (LNS)
    Niobio (NBR)
    Ombre (OMB)
    Solace (SOL)
    Triton (TRIT)
    Truckcoin (TRKC)
    Qwertycoin (QWC)
    Loki (LOK)
    Gadcoin (GAD)
    MarketCash (MKT)
    ArtoCash (RTO)
    Bloc (BLOC)
    Wownero (WOW)
    PrivatePay (XPP)
    Nicehash Cryptonight
    Minergate Cryptonight
    MiningPoolHub Cryptonight
    MiningRigRentals Cryptonight
    Suprnova Cryptonight



Hi there,

Could you add, zBucks to your list?

https://zbucks.org
member
Activity: 80
Merit: 13
good afternoon.
On the first versions when I first started using this miner, I could install on the cards Sapphire RX552 "multi_hash": 464 and the cards were given out at 520 h/s, but now I can not install more "multi_hash": 432 everything above the card is not keep the memory frequency and reset again and as a result the speed is from 0 to 60 h/s. The system did not change anything, tried to reduce the frequency to indecent 1800 MHz, the result was not given. Tell me what it can depend on, because it's on the forum guys use 464 on similar cards and I like everything hangs on the line

     { "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : ..., "multi_hash":432 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : ..., "multi_hash":432 },



{ "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : ..., "multi_hash":448 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : ..., "multi_hash":416 },
try worksize, 16, alpha 64 as well.
newbie
Activity: 14
Merit: 0
good afternoon.
On the first versions when I first started using this miner, I could install on the cards Sapphire RX552 "multi_hash": 464 and the cards were given out at 520 h/s, but now I can not install more "multi_hash": 432 everything above the card is not keep the memory frequency and reset again and as a result the speed is from 0 to 60 h/s. The system did not change anything, tried to reduce the frequency to indecent 1800 MHz, the result was not given. Tell me what it can depend on, because it's on the forum guys use 464 on similar cards and I like everything hangs on the line

     { "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : ..., "multi_hash":432 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : ..., "multi_hash":432 },


newbie
Activity: 54
Merit: 0
The too long line can be easyly shortened:

18:02:16 | GPU 6: 55°C 86%  Shares: 1 | 0   Avg 1030 h/s  Max 1083 h/s

"Temperature" and "Fan speed" are obvious because a temperature and a percentage can only come from them.

The hashrate per thread is not as useful as the total one per device (GPU or CPU) so the global hashrate per device would be enough in the automatically displayed values, while the detailed hashrates would be still available through the key H.

The hashrate is not a direct measure from hardware, but its value depends directly on the hardware state: If a hashrate drops significantly, the GPU has some issue or is already crashed.
That's why I believe it could be included to the violet line about each CPU, and those lines could have one about the CPU too.
member
Activity: 350
Merit: 22
All on the same line is too long, I already tried it.

Also the purple log is special for GPU, that's the very physical status. Fan, Temp and shares that were physically good or bad.
Not related to pool side results.

The blue hashrate is the instant physical hashrate for all devices
Not related to pool side results neither.

Yellow is about the pool-side info: coin, wallet, difficulty, effective net hashrate...

I want to avoid to mix those notions. However the yellow part is incomplete, i admit, i must add the triplet of shares found/accepted/rejected

The memory model of 0.32+ is very different of 0.31 and yes, it tends to be faster with more vram (which is not that good, but i tested on my low-mem card HD7790 1G and i still get the peak of 268h/s, on par with claymore.
So i can expect the 0.32 to be as fast as the 0.31, with a few more mem, but starting a lot faster.

Quote
highest difficulty share your miner found.
For what? For fun? it's a useless info since mining is all about random values and only the pool difficulty counts, a 1G diff hash with pool difficulty of 10000 worths 10000.
member
Activity: 190
Merit: 59
I am totally cool with devfee. In fact, when I switched to JCE i thought i am paying 1.5% and later JCE told me it is actually 0.9% for gpu mining :*

JCE, since you are so cool, i have 2 more suggestions:

1. Do not have separate blue and violet colors for GPUs. Just insert the hashrates into violet text and add one extra line with total rig statistics.

18:02:16 | GPU 6: Temp: 55C - Fan: 86% -- Shares: Good: 1 Bad: 0 - Thread 02 1050h/s Thread 03 1030h/s Total 2080h/s

Unless you are limited by line length or something but you can always remove unnecessary letters

2. If you press R, it would be cool to see highest difficulty share your miner found.

PS. I was always thinking that 0.32x versions with fast compile have somewhat lower hashrate in vega cn7, than 0.31 versions. (14280 vs 14400) But now i just randomly entered multihash 2000 instead of 1936 and bam! 14400h/s.  Grin
newbie
Activity: 25
Merit: 0
Grin Your miner is simply awesome Grin.All I need is auto reboot feature that auto reboot the rig if any gpu crashes
jr. member
Activity: 176
Merit: 2
what happens to SRB is crazy, people who cheated his fees complain they cannot cheat any longer. i never had any complain about fee on jce and i won't start just because another miner dev has some. the fee netcode of jce is the exact same since very first version, and is the same as Claymore, except there's no revenge mode in case a fee fails.
an important note is that jce use the same algo for fees as the user, to ensure no power consumption change.

imagine: if your card is fine tuned for v7, it mines, then the devfee of miner X switch to cn-heavy, your card eats 5W more and crashes. i don't like this way, again i use Claymore principle: devfee mined in the same algo than the user.


estimate for 0.32g cpu linux : one day
0.32g GPU : a few days

can't wait for GPU release.
My understanding for Claymore Ethash, dev fee mining currently only have option eth or etc, so if you mine musicoin or other ethash coin it will switch dag even though power consumption same sometimes it cause crash. Phoenix Miner solve this problem by introduce a lot coin dev fee mining in order to avoid switching dag.
maybe my understanding also wrong, since I just used it.
jr. member
Activity: 176
Merit: 2
CN-Red is for MOX coin

Quote
Some miners dont show you even this.
I think Doktor talks about JCE here, but that's pointless, since i've control over my netcode, i can mine devfee for 10mn and report on screen i mine fee for 1mn. A close source miner internal report worth nothing. Like the Claymore -nofee hashrates that were tweaked. Only one info is trustfull : your pool report. Period.

I understand that all miner start dev fee at first few minutes to avoid people cheating by close miner right before dev fee kick in and start miner again.
The problem when doktor83 change the way dev fee work from 2 hours at first kick in to 15 minutes at first kick in, he didn't state in 1.6.3 release  https://bitcointalksearch.org/topic/m.41828317 even though at first page I saw he wrote that changes, but not sure when he wrote it.

so for me the problem not because of dev fee 15 minutes start kick in, but because of he didn't inform boldly in his thread like when he asked miner to download new version because of his cn-heavy dev fee mining in sumo coin while sumo back to CN ASIC friendly.

If you use program properly, you dont  need to worry is fee at 1 min or 100min, if You get on pool the hashrate you shuld.
JCE is smarter dont show when fee is mining, so the restart process killing users dont know how much fee they mine Cheesy

but will probably the same users who use both miners be now mad on JCE too if they using it improperly and killing process 50 time a day  Grin

I used program properly, that's why I said I understand all miner start dev fee at first few minutes. I used claymore and phoenix miner a lot, their dev fee is same with srb. cast xmr and jce also I think the same mechanism. I just pointing why people angry, people angry because they know it changed by finding it not because of doktor show them.

sorry for my bad English if you can't understand for what I want to say.
member
Activity: 350
Merit: 22
what happens to SRB is crazy, people who cheated his fees complain they cannot cheat any longer. i never had any complain about fee on jce and i won't start just because another miner dev has some. the fee netcode of jce is the exact same since very first version, and is the same as Claymore, except there's no revenge mode in case a fee fails.
an important note is that jce use the same algo for fees as the user, to ensure no power consumption change.

imagine: if your card is fine tuned for v7, it mines, then the devfee of miner X switch to cn-heavy, your card eats 5W more and crashes. i don't like this way, again i use Claymore principle: devfee mined in the same algo than the user.


estimate for 0.32g cpu linux : one day
0.32g GPU : a few days
newbie
Activity: 156
Merit: 0
CN-Red is for MOX coin

Quote
Some miners dont show you even this.
I think Doktor talks about JCE here, but that's pointless, since i've control over my netcode, i can mine devfee for 10mn and report on screen i mine fee for 1mn. A close source miner internal report worth nothing. Like the Claymore -nofee hashrates that were tweaked. Only one info is trustfull : your pool report. Period.

I understand that all miner start dev fee at first few minutes to avoid people cheating by close miner right before dev fee kick in and start miner again.
The problem when doktor83 change the way dev fee work from 2 hours at first kick in to 15 minutes at first kick in, he didn't state in 1.6.3 release  https://bitcointalksearch.org/topic/m.41828317 even though at first page I saw he wrote that changes, but not sure when he wrote it.

so for me the problem not because of dev fee 15 minutes start kick in, but because of he didn't inform boldly in his thread like when he asked miner to download new version because of his cn-heavy dev fee mining in sumo coin while sumo back to CN ASIC friendly.

If you use program properly, you dont  need to worry is fee at 1 min or 100min, if You get on pool the hashrate you shuld.
JCE is smarter dont show when fee is mining, so the restart process killing users dont know how much fee they mine Cheesy

but will probably the same users who use both miners be now mad on JCE too if they using it improperly and killing process 50 time a day  Grin
jr. member
Activity: 176
Merit: 2
Hello all,

I do have an experimental version that fixes the warm-up phase stuck @80% forever, but I want to test it well, no more disasters like the 0.32 c-d-t... that produced bad shares. No more rushed release, i really need time to test.

If i can achieve it in time, i will release a CPU version with backports of the GPU netcode fixes. It's mostly targetted to the Linux miners since that's the version I update the less.

Next planned GPU version will have :

* Warm-up phase fixed
* CN-Heavy optim (i expect to come closer to SRB, but probably not above yet)
* Shares sent to the void bug on exotic pools (Nicehash, MoneroOcean...) fixed
* Auto blue hashrate back
* Correct display of very low GPU hashrates (for HD5000...)
* Auto yellow report (period: about 10mn)
* Cryptonight-Red fork if i've time enough to do it. It's a mix of XTL and CN-Light

can't wait for this release, especially point 1 and 2. any estimation when it will be release?
jr. member
Activity: 176
Merit: 2
CN-Red is for MOX coin

Quote
Some miners dont show you even this.
I think Doktor talks about JCE here, but that's pointless, since i've control over my netcode, i can mine devfee for 10mn and report on screen i mine fee for 1mn. A close source miner internal report worth nothing. Like the Claymore -nofee hashrates that were tweaked. Only one info is trustfull : your pool report. Period.

I understand that all miner start dev fee at first few minutes to avoid people cheating by close miner right before dev fee kick in and start miner again.
The problem when doktor83 change the way dev fee work from 2 hours at first kick in to 15 minutes at first kick in, he didn't state in 1.6.3 release  https://bitcointalksearch.org/topic/m.41828317 even though at first page I saw he wrote that changes, but not sure when he wrote it.

so for me the problem not because of dev fee 15 minutes start kick in, but because of he didn't inform boldly in his thread like when he asked miner to download new version because of his cn-heavy dev fee mining in sumo coin while sumo back to CN ASIC friendly.
jr. member
Activity: 176
Merit: 2
When I get back home, I will give a 7 day test to srb miner again to count the hashes.

I can tell you this, that the hashes reported by JCE-miner are spot on with what the pool reports. That is why I stick with JCE from the very moment first GPU version was out.

Anyway, how many of you guys are mining using Vegas? What version you use and what you mine? Did anybody tinker with settings to pull out some extra hashes?

when srb introduce option --sendallstales and you use it in .bat file you should get close to what miner reported.
actually I also notice that maybe since 1.5.x or 1.6.x CN-V7 is far away from miner reported. because when I tried 1.4.1 pool hashrate close to miner reported, in that version the miner also counted stale shares. but somehow that information lost in 1.5.x or 1.6.x.
I didn't report because I know their respond sometimes is bad or simply ignored it. so I try to stop posting on their thread and find another miner.

the best dev attitude so far at least in my opinion is Phoenix Miner. even if someone said bad to them, they will answer politely.
member
Activity: 112
Merit: 13
From the JSON that's returned via the API, how do you differentiate between the hash rate from CPU mining vs the hash rate from GPU mining?

I'm newer to this miner.  The thread rates for _gpu seem to be the thread_all rates, but paired (_all[0] + _all[1] = _gpu[0], _all[2] + _all[3] = _gpu[1], etc).  Which of these is the cpu rate if you're mining with both, assuming that's possible.
member
Activity: 350
Merit: 22
online is the
0.32g CPU - Windows

Linux version will come next.
Code:
Netcode fixes
newbie
Activity: 39
Merit: 0

Anyway, how many of you guys are mining using Vegas? What version you use and what you mine? Did anybody tinker with settings to pull out some extra hashes?

Here are my 2 Vega 64 mining V7:

Code:
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":2000 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 1, "multi_hash":2000 },

2000 is under testing as i get a few more H

Code:
| Hashrate GPU Thread 1: 1139.96 h/s
| Hashrate GPU Thread 2: 1139.90 h/s - Total GPU 1: 2279.86 h/s ( Sapphire ) ~ 1500GPU - 1170MEM @960mv
| Hashrate GPU Thread 3: 1044.88 h/s
| Hashrate GPU Thread 4: 1045.47 h/s - Total GPU 2: 2090.34 h/s ( Asus ) ~1400GPU - 1080MEM @960mv


The sapphire is a beast and can take more but with few errors.
The Asus is kinda crap in thermals so i keep it a bit lower.



member
Activity: 190
Merit: 59
When I get back home, I will give a 7 day test to srb miner again to count the hashes.

I can tell you this, that the hashes reported by JCE-miner are spot on with what the pool reports. That is why I stick with JCE from the very moment first GPU version was out.

Anyway, how many of you guys are mining using Vegas? What version you use and what you mine? Did anybody tinker with settings to pull out some extra hashes?
Pages:
Jump to: