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

you can try telnet to your pool and port you are using from command prompt, if you are able to connect then should be good.
you also can try other pool just to check.

telnet xmr-asia1.nanopool.org 14444 that is the example if your pool is nanopool and you are using port 14444.

I have an issue that I've already explained to JCE on a french forum, but I'd like to know if I'm the only one.

It happens with every 0.32 versions and only on Cryptonight V7 (--variation 3): each connection attempt to the pool fails.
All the other algos (CN Light, Heavy, Saber,...) work fine with the 0.32 versions. The issue only concerns CN V7.

The culprit is not my firewall because disabling it has no effect on the issue.

Am I the only one to have to use the 0.31f to mine CN V7?

it's a bit strange because for me static diff work perfectly with miner.rocks.

I believe you are referring to Claymore cryptonote, because Claymore ethash since version 9.6 already sorted by bus id.
yes we need to change the config if in one rig contains different GPU type, but I still prefer with order by bus id because of GPU-Z, HWInfo, OverdriveNTool they order by bus id.

Hi JCE,

thanks for additional report how many re-connection occurs (with that I can check if the hash rate drop mostly because of connection drop).

recently I tried driver 18.6.1 and 18.8.1 with JCE 032h or 032j (heavy algorithm) but it instantly crash if all 8 or 10 GPU I used, but if I only configure 6 GPU it's fine. can you please help to take a look of this problem?

driver 18.3.4 with JCE 032h or 032j (heavy algorithm) everything fine with 8 GPU or 10 GPU.

Thanks.

It should have been the default order, but I wanted to be somehow compatible with claymore 9 and Stak (which also used OpenCL order). And now changing the default could cause chaos with existing configurations.

--bus-order
It's very nice feature:P, JCE gpu list same with hwinfo now.

Yeah, actually taking a closer look, it did arrive to 1.5m diff...
Btw, I'm using 32f version of the miner cause I don't know why, last version wasn't stable for me.
After some time one of the cards randomly stops and resets its clocks to 300mhz...mega weird...
Anyways, this doesn't happen (like NEVER) using 32f miner version

Cheers mate!

Jumps to 400k ?
It's similar to a previous bug I already fixed about the share counter (which was a cosmetical but misleading bug). And again, only for CN-Heavy. I'll take a look back once i'm done with the Watchdog.

RX550 : my lovely cards, my underestimated favorite. With JCE (and in a lesser extent Stak or others) you can easily pull ~500 h/s from them on v7. Thanks to their memory controller which is the same as the bigger rx560, and for which JCE has dedicated code. So you get a quarter of a vega for a fraction of the price, best efficiency.

The vega jump happened with Cast and the BetaBlockchain. Now the recent 18.x drivers give full power of Vega and we're reaching hardware max at ~2100h/s. It still requires dedicated code to have good performance but no longer hacks to force Compute mode.

Yeah, true that it isn't a big threat but sometimes miner stays like 7 minutes without finding hashes.
For example I start at 25k diff but it increases (as far as I could see) to 400k...then moving up and down, etc.
Anyways, thanks mate!

Weird scenario, My vega 64 is running actually cold In the latest version. Mostly it 72-73 but now 68 max. Maybe it's the driver (I use 18.8.1). Great work ,jce miner.


And A Quick question, in the past rx 550 did 250+ hs, but now we can squeeze 480+ hs. Does the same apply to vega cards or the current hs is their limit...?

Thanks


Interresting, so it may come from my netcode. A possible explaination could be the devfee session that may get a different diff as the user pool. But the devfee sessions are Claymore-style: small randomized sessions that don't disconnect your own pool, so you may encounter a few shares with a different diff from time to time (0.9% of time average) but not a permanent change.
Also strange is that i got this problem reported on CN-Heavy coins, while of course my netcode is the same whatever the coin is (only Nicehash has dedicated netcode).

This is not a big threat since all diff are equivalent in term of efficiency, but that's still a bug. Also check pool side the shares you get are the same as the effective hashrate reported by the yellow report, within a ~2% tolerance, and after a few hours of mining. If you observe a huge result difference, so it could be a critical bug.

I quick read the code, and the purpose is to monitor the hashrate and restart the vega drivers and the miner when they drop.
The monitoring is to circumvent the lack of Watchdog in Stak, and the reset/restart is the pupose of a watchdog too.

So my answer is that once JCE watchdog is released, this script won't be needed, a simple .bat would do the job:

(pseudo-bat and dummy values)

My wording was bad, that was a OpenCL generation bug caused by the Vega detection routine. It appeared in 0.32i and was immediately fixed thanks to the report of samvicky. 0.32i has been removed and replaced by 0.32j

Hi again and thanks for the answer.
So, i do get the message: "Pool changes Difficulty to XXXX." therefore as you say it's a pool's job.
Weird part is that when using fixed diff like 25k with jce-miner, diff changes after some time but same 25k with xmr-stak, diff stays fixed... :/

Cheers!

What is vega bug? Never had issues with vegas and jce miner

Can you make jce gpu miner compatible for this
 https://github.com/zbobyuan/JJ-s-XMR-STAK-HashRate-Monitor-and-Restart-Tool....? I was using this for xmr-stak,it was every effective.

Very interresting, i was tracking that bug for a long time, and thanks to your comment, i know it's related to my "vega detect" routine. I fix it and re-release. Bad bug, but good news for me somehow. This error had been reported on github previously, with a different error code but i could check it was the same bug. Thanks !

Nope, on purpose, i've no time enough to provide a decent real-time support, and opening a ghost, mostly unused Twitter account would be quite lame. I answer on this topic and the Github page, but no social medias.


1. nice to have but Watchdog has higher priority to be dev'ed
2. Very good idea, i do it right now.
3. Sure, stupid i didn't do it before, but it's longer to dev so it will be in version after next
4. This is my definition of Watchdog, just the "min" will default to zero, but you can set any number. On my rigs with my dev prototype (the future 0.32k) it is set to 90% of normal hashrate as "min".

I haven't tested explicitely, but some (most?) pools will force a variable diff if you mine too fast or too slow with a fixed diff. Look at the log, if you get a message "Pool changes Difficulty to XXXX." so that's your pool's job, JCE don't change the diff by itself. I'll switch one rig to that pool for a few hours to check for that (but I mine v7 and not Heavy since i've low-mem cards).

edit:
0.32j online - minor version

Hi JCE,

Just want to write some feature request & feedback :
1. Please add feature keep alive option.
2. Please add report in yellow how many miner reconnect to pool after connection drop.
3. Please do warm up again after miner reconnect to the pool.
4. Along with watch dog for next release is it possible to add feature min speed, so if overall hash rate below min speed for 5 min (after the warm up session) than it will restart the miner or windows.

thanks for new feature order by bus id, it really helpful.

Please have a social media account where we can contact you. Maybe Discord/Twitter..

Starting GPU Mining thread 22, on GPU 3
Created OpenCL Context for GPU 3 at 00000195b06b7950
Created OpenCL Thread 22 Command-Queue for GPU 3 at 00000195b04fea40
Scratchpad Allocation success for OpenCL Thread 22
Allocating big 2400MB scratchpad for OpenCL Thread 22...
Compiling kernels of OpenCL Thread 22...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: s-331.16

Starting GPU Mining thread 23, on GPU 3
Created OpenCL Thread 23 Command-Queue for GPU 3 at 00000195b04ff220
Scratchpad Allocation success for OpenCL Thread 23
Allocating big 2400MB scratchpad for OpenCL Thread 23...
Compiling kernels of OpenCL Thread 23...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: s-331.16


Getting this error on my vega 64. I am on 18.8.1 driver and win 10. I even tried --auto but same issue. I am using the latest 32i but 32h doesnt have this issue,No issues on my 3x Rx 550 2gb cards

Veronite is to be added in the upcoming 0.32i, meanwhile you can mine with parameter --any --variation 5
let me check on that pool, it will be a good test for the new native Veronite support

edit, tried with current version (the wallet is a dummy one):


Expected, and it says what to do: add --any --variation N with N=Cryptonight-Heavy=5

[/quote]


Thanks for the answer man. And yes, it does set the diff to whatever you put after the ".", BUT after mining a bit,
it starts to increase, decrease, etc, as if you don't put anything!