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

[1033ruben]

Thanks all for report and sharing your optimal config. Don't forget to tell what algo you're mining
so i can put those config in the Github doc.

well maybe someone can send me a link to this.
THANKS
P.S. Again I need the config for a ryzen 1600 for cnv7. the reasin why i ask is because as of right now am only getting like high 200's with this miner and am getting like high 400s with xmr stak.

[TigTex]

Hello

I'm testing your miner on 5 rx580 4gb on moneroocean.
Since 0.33c you support "pool managed autoswitching" but it doesn't seems to work like the other miners
For example, I would like to set each algo performance so that the pool always mines the most profitable coin. Also, if I use the same config for the different algorithms, the miner will run out of memory (for example, cn8 intensity cant be used on a cn-heavy algo). It needs to support multiple configuration files or multiple algos on config.txt
Is this going to be implemented?

[JCE-Miner]

Github page: that's on first page of this topic
direct: https://github.com/jceminer/cn_gpu_miner

Again I need the config for a ryzen 1600 for cnv7

I answered just above

And that's with usage of FX4330(4-core, 8M, 4GHz)

CN-Heavy consumes 4M of cache, better use two threads with multi-hash 1

pool managed autoswitching

Please read the full doc about how to setup a different config for each algo:
https://github.com/jceminer/cn_cpu_miner#pool-managed-autoswitch

Three config arrays for three algo class (Light, normal, Heavy)

multiple algos on config.txt

That's exactly how it works. Example from the doc:

Code:

/* This is the configuration when Cryptolight class algo is mined */
"cryptolight_cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : true, "multi_hash":1 },
],

/* This is the configuration when Cryptonight class algo is mined */
"cryptonight_cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true, "multi_hash":1 },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true, "multi_hash":1 },
],

/* This is the configuration when CN-Heavy class algo is mined */
"cn_heavy_cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true, "multi_hash":1 },
],

And adding a hint for the pool to select your most profitable algo is planned, it has been requested in a Github ticket

[Uaciuganadu]

Hey JCE,

Would you be able to create a benchmark flag? For example we can use it for testing all the compatible  variations of intensity in order to find the best one for a specific algo. It can run for 2min at a time for eatch variation and export them to TXT at the end. It can take a while but it can find unexpected variations that no one ever atempted to try and will take the guessing out of the configuration.

[Lermite]

I still have hashrate droops with the 0.33b6.
One has just occurs on my RX 570 4G after two hours of mining CN V8: from 1100 to 965 h/s.
It's the same hashrate droop I had with the b4 and b5 versions.

[JCE-Miner]

What you need is already available to script this:

* Do short tests: parameter --autoclose N to close after N minutes (the 1st minute has no fee)
* Generate a different config for each test: just generate the JSON config, it's a piece of standard JSON
* Read the hashrate: the JSON output is perfect, or use --log <file> then parse the file

and repeat repeat until you get the optimum.

[JCE-Miner]

I still have hashrate droops with the 0.33b6.
One has just occurs on my RX 570 4G after two hours of mining CN V8: from 1100 to 965 h/s.
It's the same hashrate droop I had with the b4 and b5 versions.

I fixed drops on CN-Heavy (and related) only. If i have good feedbacks about it, so i'll put it on V8 too.

[TigTex]

Please read the full doc about how to setup a different config for each algo:
https://github.com/jceminer/cn_cpu_miner#pool-managed-autoswitch

Hmm, I was reading the cn_gpu_miner github page and that info is missing from there. My bad, didn't noticed that there are 2 projects
Thank you for your fast and kind reply. I'll look into it

[lstrike]

It seems the drops in hashrate remained at 033b6...

The strange thing is that it affects polarises (470/580) - 8GB and at each restart affect random cards of them. They work properly with stable hashrate (but little bit lower) with 032q, so I use that old version for them only. On polarises 4GB it is not noticed, also vegas.

[Max Hatchett]

 Hi, I've have to honest on this one - I’ve tried ver 06, unfortunately so far no improvement at all...I’m just not sure if it really worth it. currently, the ver.b6 doesn’t give me any of the advertising hash rate. (10-15%  -realy???/are you sure?)
To be clear, a have an excellent performed on my  46 rigs of Sapphire AMD Radeon  GPU RX 480 8gb Samsung, each  easily giving 8930-8950 h/s, founded best  running on 33ver.b2, /////  and  running  by very  similar hashrate 8800--0890 on ver, 0.3.b4 on my  17 rigs 8x580  8Gb powered by Hynix memory, its sems more  stable on this version .  So if you going  with Polaris on 8Gb Samsung – the 0.33.b2 its the best version for you, on the Hynix Memory-  its hard to beat ver b4. JUST IGNORE THE VER B05 / B06 AT ALL COST!!!! 

[io8621]

A few hours before the release of 0.36 get stable configuration also with 0.35 on my rx card.

Example, for 580 8gb on heavy algo get stable 1035 hs with multihash 896 or 1062 with 832.

Increase value of multihash parameter get instable hashrate.

This is, test now 0.36

[Ultrasonik]

http://json.org/

ws
    ""
    '0009' ws
    '000a' ws
    '000d' ws
    '0020' ws

Whitespace can be inserted between any pair of tokens.

So my JSON is conformant, and said differently, JSON do'nt care about blankspaces and indentation.

0.33b6 to be released in less than one day, with the OpenCL bug O.2.10 fixed.

033 b6  not work  , reports the same errors 
may need a specific version of the video driver?

[Iamtutut]

It's online 0.33b6 GPU

I mined Haven for 48 hours on 3 capricious RX and had a very stable hashrate, varying +/- 2% not more, I hope it will be better for everybody.

My GPUs could get through the warmup, still with swings (mostly RAM frequency, sometimes core freq). Declared speed in itself is highly improved compared to my reference JCE 0.32G version, +15% for same power draw (at wall). If my computer stay stable during the night, I'll check the reported HR at the pool.

Almost 9hs mining tube and counting.
Max speed is 2316H/s, I had never got above 2030H/s with my reference 0.32G version, so that's a solid +15% speed.
Current effective HR: 2250H/s.
Power draw at the wall: 365-370W, this include the CPU mining which consumes around 30W.

That's a HUGE improvement in terms of speed with the same wattage, impressive.


One important point: I had to lower both core and mem clock on 2 out of 3 GPUs.

[UnclWish]

On my RX 580 8G cards speed with b6 a bit lower, but still unstable. One of cards drops speed to 985 h/s and didn't rise it again...

[fluxy12]

The b6 doesn't work on my rx580 8Gb samsung rigs, it is unstable exactly like the b5.

[lstrike]

On polarises 4GB it is not noticed, also vegas.

Correction - same problem with Vega.
As a conclusion - unstable hashrate is noticed on 8GB cards. Also I think it is related to power drops (seen in gpuz) - I don't know whether they are cause ot result...

[JCE-Miner]

OpenCL bug 0.2-10: i could reproduce it on my rig by using exotic characters in the path where JCE exe was, and this case is fixed. But there may be another cause of bug. Did you use non-english path too?

Hashrate: first, yes, the +15% is not fake, but it can be canceled by the higher instability on some cards. On old cards, it's +20% faster and stable, easy. HD6000, HD7000, R7, R9... On big RX and Vega, things are more complicated.
I read here opposite results, so:
* Ensure you're talking about CN-Heavy and related, CN-v8 is not concerned by the 0.33b6 release
* Is it unstable on the 8Gb RX and Vega only? Sure that's the most common cards, but if this is the status, it's an important detail to track the bug down. I did my long-run tests on 2G and 4G cards only so far. If I need a 8G card to reproduce the bug, i've some, so i need to focus on them.

I suspend GPU support and dev for now, going back to CPU version where i've a fistful of Github tickets to close.

[vmozara]

Guys chech your multihash, if it is too high you will get all kinds of hashrate issues.

On my Vega rig i dropped multihash form 960 to 896 and hashrate stayed the same but now i had same hashrate over all cards
I was just testing the rig, it was connected to bittube pool and it was working like 10 hours with 0 issues

[JCE-Miner]

Thanks, and that's also my first idea: recent JCEs are faster but support a lot less to mine on 99% available memory. The trick is that the b5 and b6 no longer need to use all memory to get fast, I tried to configure my 4G cards exactly like my 2G (with about 1900M memory allocated) and they mined fast. Increasing the 4G cards load over 2G gave very little extra speed at the cost of a very unstable hashrate.

Maybe the fix is just to warm users to update their older config and use less memory. I'm afraid a lot of users just updated their binary keeping the old config on 8G with maximum memory load, as it was the rule on previous versions, and is still on other miners like Cast or SRB.

To all who have the problem: configure your 8G card like if it was a 6G, leaving free vram on it and retry. I'd expect to get -1% speed and a very more stable hashrate.
I remember this rule from older Claymore 9 with mode -a 1: it provided +2% extra perf with +20% power consumption, 100% memory usage and random crashes. Not a good deal.

[vmozara]

JCE,
as other miners alrady asked, please can you explain what are alpha, beta, gamma, zeta...? So at we have basic idea of what are we doing when putting all the random numbers