[JCE]Fast & stable CN/v8/Heavy/Tube/XHV miner, CPU+GPU, Vega56 1800+ RX580 1200+

[Uaciuganadu]

Hello Jce,

Hope you are having a good day.

I`m a big fan of your miner as it is the first one that works good with Vega and i love the way you keep making it better.

I have a small question/request that involves automatic algo switching.

I know this seems not so useful but in my case it is.

I mine on MoneroOcean, and this pool currently mines best performing V7 alt coins and pays in Monero so the profit is better. I have heard from the developer on Discord that they are planing to also add Heavy and Light coins in the mix, but only miners that support it will work. From what i can understand the miner will need to change algo on the fly from V7 to heavy for example to mine the most profitable coin. He said and i quote "Yes, working on xmrig patch now for that" so i do think that the devs of XMRig have or will have a miner that can auto switch but i do not know how they implement it.

I know that your miner compiles the code at start but would it be able to compile it for more algorithms and keep it in memory until it needs to be used?


I really think this will be the next go to miner in the future so wanted to see if this is possible.

Thank you!

In relation to the above:

Code:

MoneroOceanLast Sunday at 10:59 AM
I activated multi algo mining support on fr.moneroocean.stream pool node (currently RYO is supported for cn-heavy algo and Masari is supported for cn-fast algo). Any miners that want to test how it works can build (no prebuilt versions now, sorry) xmrig and xmrig-amd from my repositories (https://github.com/MoneroOcean/xmrig, https://github.com/MoneroOcean/xmrig-amd). Both miners now have new -calibrate-algo option to perform short hashrate benchmarks for each algo before run and store results in "algo-perf" config.json parameter (so you can do it only once).
In config.json "threads" param now can now separate profile for each algo (see more details in https://github.com/xmrig/xmrig/issues/618)

Do you plan on adding this or a form of this to the JCE miner?

[JCE-Miner]

Hello,

i plan to add per-gpu coin config, to allow different gpu mine different coins, since some are faster on Heavy or on V7. but not a super autoswitch, that goes too far for now.

recent jce have a bug on the warm-up phase and get stuck at 80% speed, never reaching 100% even after 5mn, even after a hour. i can reproduce the bug and i'm experimenting fixes.

rinzlerus: that's what you're experiencing. try the 0.31c it shouldn't have this regression. same for you synchro2017

i must also focus on a bug reported where jce stops sending shares after having been paused, either manually or by a devfee session. it looks a rare bug but it's a critical one. seems to depend on the pool, Unclwsh reported it on nicehash.

[lebuawu2]

Hi JCE,

any reason why multi_hash must be multiple by 16? why is it not 2 or 4 or 8?

another opinion is it possible to display hash rate, temp, fan, good shares, stale shares, bad shares in one line like below?

GPU0 : 1100 h/s, Temp : 50C, Fan : 50%, Shares : 100/0/1
GPU1 : 1090 h/s, Temp : 51C, Fan : 51%, Shares : 101/1/2

and another option like --disabledmonitoring to prevent that information showing up every xx seconds. if we want to show that information we can just press h. because I notice if I keep pressing h I don't see any accepted shares from pool so just curios by displaying that information is it reduce our effective hash rate?

Thanks.

[fluxy12]

Hello,

what GPU driver do you recommend ? i don't see it on the first post. Thank you !

ATM my hashrates with 580 Samsung is 1030 h/S (heavy) using the version 31c with 842 multihash and no OC.

[JCE-Miner]

pro-tip : on HD7950, use drivers 15.12 and on FM2 APU, 15.7

i focused on some non-gpu bugs and i'm fixing two:
* blue hashrate stops to popup automatically when gpu status (purple) comes
* miner loses connection to pool but continues to mine in the void (UnclWish bug)


Pressing H (or T or R) stops the miner for a split second, needed to gather the very up-to-date info to display, and to flush the console display. don't manic-press h or it cause the hashrate to drop. it even apply to the cpu miner. if you really want to constantly get the hashrate, open the JSON out in a browser and punch F5 as much as you want.


the multiple of 16 is due to the internal way i pack the data. it must be an even square, the next lower is 4 (2x2) and it's too small, so i need to keep 16.

the purple report is all about physics. fan, temp and gpu compute correctness. adding stale or accepted share info is not about physics, that's about your pool. those info should be displayed, but in the yellow report.
i'd like to avoid adding too many parameters, for simplicity. the default frequency the reports (blue, yellow and purple) pop is already quite low and impact on perf is negligeible.

[lebuawu2]

pro-tip : on HD7950, use drivers 15.12 and on FM2 APU, 15.7

i focused on some non-gpu bugs and i'm fixing two:
* blue hashrate stops to popup automatically when gpu status (purple) comes
* miner loses connection to pool but continues to mine in the void (UnclWish bug)


Pressing H (or T or R) stops the miner for a split second, needed to gather the very up-to-date info to display, and to flush the console display. don't manic-press h or it cause the hashrate to drop. it even apply to the cpu miner. if you really want to constantly get the hashrate, open the JSON out in a browser and punch F5 as much as you want.


the multiple of 16 is due to the internal way i pack the data. it must be an even square, the next lower is 4 (2x2) and it's too small, so i need to keep 16.

the purple report is all about physics. fan, temp and gpu compute correctness. adding stale or accepted share info is not about physics, that's about your pool. those info should be displayed, but in the yellow report.
i'd like to avoid adding too many parameters, for simplicity. the default frequency the reports (blue, yellow and purple) pop is already quite low and impact on perf is negligeible.

Thanks for your explanation about multi_hash, understand by pressing H or T or R will reduce our effective hashrate. normally I often press H when running GPU-Z to know as fast as possible my hashrate already reach peak and then close GPU-Z. so if you able to make GPU reach peak it self not needed to keep pressing H again :-).

The display that I suggested is just my thought base on my experience with other miner like XMR Stak (only display accepted shares and press key if you want to know other information), Phoenix Miner (display accepted shares, stale shares, bad shares), SRB Miner (one line information for each GPU).

Anyway I already happy with how effective hashrate closed to reported hashrate and I think right now is the fastest miner for RX 580 8GB, so keep good work.

[fluxy12]

Hi JCE,

any reason why multi_hash must be multiple by 16? why is it not 2 or 4 or 8?

another opinion is it possible to display hash rate, temp, fan, good shares, stale shares, bad shares in one line like below?

GPU0 : 1100 h/s, Temp : 50C, Fan : 50%, Shares : 100/0/1
GPU1 : 1090 h/s, Temp : 51C, Fan : 51%, Shares : 101/1/2

and another option like --disabledmonitoring to prevent that information showing up every xx seconds. if we want to show that information we can just press h. because I notice if I keep pressing h I don't see any accepted shares from pool so just curios by displaying that information is it reduce our effective hash rate?

Thanks.

Hello, can we get your OC settings to get this results ? do you undervolt ? also what multihash do you use ? 848 ?

For me, more effective settings (at summer 40° celsius) with a cost of 0.14usd/Kwh is : 960 h/s for 95W at wall per rx580 (Wattman : 1100 core 810cv, 1190 mem 830mv)

Thank you

[Lermite]

 I assume hope that a RX 580 8GB is required to get more than 1000 h/s, because on CN V7, Heavy or Saber, all my cards (580 4G, 570 8G, 570 4G) remain between 800 and 970 h/s.

By the way I found out my 580 works better with

Code:

{ "mode": "GPU", "worksize": 8, "alpha": 64, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, ... },
{ "mode": "GPU", "worksize": 8, "alpha": 64, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, ... },

while both my 570 as faster with

Code:

{ "mode": "GPU", "worksize": 4, "alpha": 64, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, ... },
{ "mode": "GPU", "worksize": 4, "alpha": 64, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, ... },

 

[lebuawu2]

Hi JCE,

any reason why multi_hash must be multiple by 16? why is it not 2 or 4 or 8?

another opinion is it possible to display hash rate, temp, fan, good shares, stale shares, bad shares in one line like below?

GPU0 : 1100 h/s, Temp : 50C, Fan : 50%, Shares : 100/0/1
GPU1 : 1090 h/s, Temp : 51C, Fan : 51%, Shares : 101/1/2

and another option like --disabledmonitoring to prevent that information showing up every xx seconds. if we want to show that information we can just press h. because I notice if I keep pressing h I don't see any accepted shares from pool so just curios by displaying that information is it reduce our effective hash rate?

Thanks.

Hello, can we get your OC settings to get this results ? do you undervolt ? also what multihash do you use ? 848 ?

For me, more effective settings (at summer 40° celsius) with a cost of 0.14usd/Kwh is : 960 h/s for 95W at wall per rx580 (Wattman : 1100 core 810cv, 1190 mem 830mv)

Thank you

that's just example, I can get 1140 h/s for cn-saber with cclock 1250/890 mclock 2200/890 multi_hash 944. RX 580 8GB with micron chipset.
Is it true cclock 1100 mclock 1190 can get 960 h/s ? because normally default mclock 2000 so 1190 is too low.

[fluxy12]

Hi JCE,

any reason why multi_hash must be multiple by 16? why is it not 2 or 4 or 8?

another opinion is it possible to display hash rate, temp, fan, good shares, stale shares, bad shares in one line like below?

GPU0 : 1100 h/s, Temp : 50C, Fan : 50%, Shares : 100/0/1
GPU1 : 1090 h/s, Temp : 51C, Fan : 51%, Shares : 101/1/2

and another option like --disabledmonitoring to prevent that information showing up every xx seconds. if we want to show that information we can just press h. because I notice if I keep pressing h I don't see any accepted shares from pool so just curios by displaying that information is it reduce our effective hash rate?

Thanks.

Hello, can we get your OC settings to get this results ? do you undervolt ? also what multihash do you use ? 848 ?

For me, more effective settings (at summer 40° celsius) with a cost of 0.14usd/Kwh is : 960 h/s for 95W at wall per rx580 (Wattman : 1100 core 810cv, 1190 mem 830mv)

Thank you

that's just example, I can get 1140 h/s for cn-saber with cclock 1250/890 mclock 2200/890 multi_hash 944. RX 580 8GB with micron chipset.
Is it true cclock 1100 mclock 1190 can get 960 h/s ? because normally default mclock 2000 so 1190 is too low.

Oh sorry here are the values for 1960 and 95W at wall : 1100 core 810cvv | 2190 mem 830mcv

1140 h/s thats very good hashrate i think but what is your consuption at wall have you measured it ?


PS : i tested with your settings with rx580 msi armor 8gb samsung mem i get 1076 h/s and 124W at wall - Not bad !! thank you !!

PS2 : Not stable i will put 900mv

[lebuawu2]

Hi JCE,

any reason why multi_hash must be multiple by 16? why is it not 2 or 4 or 8?

another opinion is it possible to display hash rate, temp, fan, good shares, stale shares, bad shares in one line like below?

GPU0 : 1100 h/s, Temp : 50C, Fan : 50%, Shares : 100/0/1
GPU1 : 1090 h/s, Temp : 51C, Fan : 51%, Shares : 101/1/2

and another option like --disabledmonitoring to prevent that information showing up every xx seconds. if we want to show that information we can just press h. because I notice if I keep pressing h I don't see any accepted shares from pool so just curios by displaying that information is it reduce our effective hash rate?

Thanks.

Hello, can we get your OC settings to get this results ? do you undervolt ? also what multihash do you use ? 848 ?

For me, more effective settings (at summer 40° celsius) with a cost of 0.14usd/Kwh is : 960 h/s for 95W at wall per rx580 (Wattman : 1100 core 810cv, 1190 mem 830mv)

Thank you

that's just example, I can get 1140 h/s for cn-saber with cclock 1250/890 mclock 2200/890 multi_hash 944. RX 580 8GB with micron chipset.
Is it true cclock 1100 mclock 1190 can get 960 h/s ? because normally default mclock 2000 so 1190 is too low.

Oh sorry here are the values for 1960 and 95W at wall : 1100 core 810cvv | 2190 mem 830mcv

1140 h/s thats very good hashrate i think but what is your consuption at wall have you measured it ?


PS : i tested with your settings with rx580 msi armor 8gb samsung mem i get 1076 h/s and 124W at wall - Not bad !! thank you !!

PS2 : Not stable i will put 900mv

are you sure it's samsung? Because normally samsung can't go with that high mclock. I think it should be hynix.
Did you modded your bios with polaris bios editor?
I have samsung modded with polaris bios editor cclock 1250 mclock 2000 can get 1140 h/s - 1150 h/s.

I never monitor power consumption at wall, but I think it's around 120w-130w.

[heavyarms1912]

Oh sorry here are the values for 1960 and 95W at wall : 1100 core 810cvv | 2190 mem 830mcv

1140 h/s thats very good hashrate i think but what is your consuption at wall have you measured it ?


PS : i tested with your settings with rx580 msi armor 8gb samsung mem i get 1076 h/s and 124W at wall - Not bad !! thank you !!

PS2 : Not stable i will put 900mv

You typically need anything from 875-925mV voltage on core for 1250 core clocks. 
the mcv voltage that you changed is only the floor for the core voltage.

1140 is pretty good for 1250 core clocks.  This is what I get for my config.  Thread 4 and Thread 5 are for an RX570 8gb card.  Keeps hovering between 1145-1170.

Code:

{
  "hashrate":
  {
    "thread_0": 771.17,
    "thread_1": 801.35,
    "thread_2": 796.32,
    "thread_3": 742.88,
    "thread_4": 585.85,
    "thread_5": 585.85,
    "thread_6": 796.32,
    "thread_7": 796.32,
    "thread_8": 708.87,
    "thread_9": 801.69,
    "thread_all": [771.17, 801.35, 796.32, 742.88, 585.85, 585.85, 796.32, 796.32, 708.87, 801.69],
    "thread_gpu": [771.17, 801.35, 796.32, 742.88, 1171.70, 796.32, 796.32, 708.87, 801.69],
    "total": 7386.59,
    "max": 7390.37
  },
  "result":
  {
     "wallet": "WALLET.219000",
     "pool": "bittube.miner.rocks:5555",
     "ssl": false,
     "currency": "BitTube (TUBE)",
     "difficulty": 219008,
     "shares": 4161,
     "hashes": 911292288,
     "uptime": "34:56:08",
     "effective": 7245.82
  },
  "gpu_status":
  [
    { "index": 0, "temperature": 69, "fan": 78, "processor": "Ellesmere", "memory": 4096, "good_shares": 429, "bad_shares": 0 },
    { "index": 1, "temperature": 69, "fan": 78, "processor": "Ellesmere", "memory": 4096, "good_shares": 464, "bad_shares": 0 },
    { "index": 2, "temperature": 64, "fan": 74, "processor": "Ellesmere", "memory": 4096, "good_shares": 484, "bad_shares": 0 },
    { "index": 3, "temperature": 64, "fan": 74, "processor": "Ellesmere", "memory": 4096, "good_shares": 428, "bad_shares": 0 },
    { "index": 4, "temperature": 57, "fan": 66, "processor": "Ellesmere", "memory": 8192, "good_shares": 611, "bad_shares": 0 },
    { "index": 5, "temperature": 75, "fan": 88, "processor": "Ellesmere", "memory": 4096, "good_shares": 469, "bad_shares": 0 },
    { "index": 6, "temperature": 75, "fan": 88, "processor": "Ellesmere", "memory": 4096, "good_shares": 468, "bad_shares": 0 },
    { "index": 7, "temperature": 75, "fan": 86, "processor": "Ellesmere", "memory": 4096, "good_shares": 391, "bad_shares": 0 },
    { "index": 8, "temperature": 68, "fan": 78, "processor": "Ellesmere", "memory": 4096, "good_shares": 418, "bad_shares": 0 },
  ],
  "miner":
  {
     "version": "jce/0.32e/gpu",
     "platform": "Intel(R) Pentium(R) CPU G4400 @ 3.30GHz",
     "system": "Windows 64-bits",
     "algorithm": "13"
  }
}

[JCE-Miner]

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

[vmozara]

Awesome, keep developing Did you already start to have any noticeable income from your miner to be motivated for further development?

[Uaciuganadu]

Hey JCE,


Any chances you can get the JSON output in a more friendly/readable format and not just one string of text?

[JCE-Miner]

Nope, that's pretty low and JCE remains mostly a CPU miner for small CPUs. I've few GPU users. That's the difference between Claymore who entered the game in 2014 and became millionaire and me who came the latest in 2018.
At least I provide a brand new miner, like did fellow CastXMR or SRB, and not just a custom recompile of Wolf0 code, like others.

Ho, i forgot: next GPU will deprecate the least important greeks in config from Gamma to Zeta. Alpha and Beta remain.

JSON : if you use the normal JCE mode, it's quite readable, with clean names and indentation.
The XMRStak mode is a byte-exact redo of legacy Stak format, on purpose. Stak produces a one-liner, so i do the same.

[vmozara]

I just gave SRBMINER 1.6.5 a try again on one of my rigs. The topic claims fastest vega miner on the planet, however with your miner I have 14400 H/S and with srb i have 14130, not even to mention the issues with REAL and transparent hashrate.

I strongly believe you need to forget about all these auto config things and weird stuff at the moment, and make your miner more friendly for serious mining. Add some statistics, add a watchdog and some crap, and launch your miner as real miner, because this is hands down fastest vega cn7 miner. When you get some cash inflow from fees, you will be able to spend part of that money for new cards and development, and then you can return to all these auto configs and things that you like, and you will be much more motivated when you actually earn something from it.

This miner has incredible potential, and once the word start spreading, claymore and others will easily be forgotten. Now, i have the feeling that I am only Vega guy using this miner?

Jce, you never answered, where are you from?

[QuirkSilver]

Hey, so how to disable ultra fast start? need my fast miner back. also same GPUs with identical settings/ clocks get different performance (recently, 0.32X version).
Shall i just go 0.31f for the stable slow start?

[JCE-Miner]

Thanks vmozara, true my miner is very little known, the couple Github page + Bitcointalk topic is the standard diffusion, but as I said, I came late.

I live in Europe, as you can deduce from the time I'm online or not. I won't tell more
About the distant rig rental you offered, sorry I should have answered before, but that's again No, like the previous offers of XeonPhi rigs i got before : 1. i will crash the GPU several times while testing, and i cannot press the Reset button remotely. 2. It would imply I upload a debug clear version of my code, and that's unsecure. So I prefer buying my own vega.

The 0.32 series and the super fast start are now part of my code and I won't go back to the super-long start. I admit it caused some regressions, as I expected since it's completely new, and i'm fixing them step by step.

The best production version if you don't want to participate to the Beta testing is 0.31c and 0.31f
c is better on Vega and f on RX if i remember well. Of course my goal is to make a perfect version with all good aspects (fast start, fast warmup and fast mining).

[Uaciuganadu]

JSON : if you use the normal JCE mode, it's quite readable, with clean names and indentation.
The XMRStak mode is a byte-exact redo of legacy Stak format, on purpose. Stak produces a one-liner, so i do the same.

Oh god, thank you, i forgot i have that flag in there. The normal one is perfect! Thx!

//edit: BTW is it normal for some of the threads to read 0.00 if a refresh the page? It was not doing this with the Stack JSON.