Yep, with Uber-Mix 3.1

Same issue: 1.6.0 gets 1080 h/s on RX 588, but 1.6.2 - only 1025 h/s with same config.

sorry i don't understand the question

Right now:
720
880
880
Max hashrate: 2833 H/s.
345W from the wall

I mined a bit of XTL with the GPU miner

Config: Win 10 build 1803, AMD drivers 18.6.1
3X RX570 4GB with bios mod.
Display GPU (0): 1230/2100. Intensity: 720
GPU 1: 1230/2035. Intensity: 816
GPU2: 1230/2030.. Intensity: 816

Max speed: 2780 H/s. Power draw less than 350W. Others have a much higher intensity for this kind of algo, so I could get better hashrates.

JCE, one idea:
At some point, for one particular Stellite V4 kernel compilation, my display GPU had an exceptionnal hasrate regarding the intensity (always much lower than the two other GPUs), I had around 1030H/s. Could you program include something that compare the current compiling kernel to the best result (that would be saved) and keep the best of the two ? Like this, each GPU could have a optimum kernel regarding the intensity setup.

What a welcome message, thanks!

I already discussed about the real hashrate of close-source miners, and I still claim that some do cheat, the most blantant case for me was Claymore 11.3 on cn-classic.

Just run Claymore 9.7 on an old non-forked coin like Bytecoin. You'll get 99% of the reported hashrate. Do the same with 11.3 and you'll get 90%.

I know about the random factor and the Stale shares, but on exact same pool, exact same hardware, on the long term (>24h) you should get the same ratio.
JCE does no tweak about the hashrate, may everybody check themselves and they can see.

I got good results on Vega, which is funny since i don't even own any myself. But i applied all the best optimizations possible (except on Heavy, not good yet) and i got excellent results on RX550 and vega, good on RX560 and 7850, and decent on RX570/580

I've finished the Bittube-v4 fork assemblies (ouch, ~100 asm files to update) and openCL (with the same bad perf than Heavy). And fixed the netcode, but i want to test more before release.
I expect the CPU version of bittube-v4 JCE to be a lot faster than on other miners, since I used assembly pseudo-aes implementation and not naive C like others.
There will be a complete release with CPU and 32-bits and Linux this time, not just GPU version.

Yes, i've lowered the intensity, now it's working with stellite, but not with IPBC, I tried with heavy and IPBC variations.

Here is my config: (3X RX570)

"gpu_threads_conf" :
[
   { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
   { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 0, "multi_hash": 944},
   { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
   { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 1, "multi_hash": 992},
   { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
   { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 2, "multi_hash": 992},
],

Here is my start.bat:
jce_cn_gpu_miner64.exe -c config.txt --any --forever --no-cpu -o mining.bit.tube:15555 -u bxdWD*******S5zNmeioRQahVNGgyxBL1boqPpEmv -p Z***t %SSL% %*

Kernels are compiled but y hashrate is 0 with IPBC ot Stellite (when changing pool in start.bat)

What am I doing wrong please ?

Thanks

I've re-uploaded the 0.30b with the extra Nicehash fix. I recheck at every step the Job and the nonce is still valid. And again before sending the result to the pool. If nicehash after that still says the nonce is invalid or the job doesn't exist, well, i'm out of ideas.

i also added the total cpu hashrate in the log.

ok, i've an idea about where it could come from. My last idea.

I looked at the new Bittube v2, they use a tweaked AES algo to prevent the CPUs to use their native hardware AES instruction. No problem to implement it, but i'll have tons of assemblies to update

yeah i need to look at the new Bittube fork

Nicehash: that's very strange, I rewrote large parts of my nicehash netcode, i know how to handle the nicehash mode (keep the high-order byte of the nonce) and, I couldn't reproduce despite long tests on my rig today. Sure there's a problem, but it's getting complicated.

i really observed -10% on both my hd7000 and rx560 rigs. it was blatant. while claymore 9.7 and stak gave, yeah, ~98% of theorical power.

it's documented to produce bad shares with parameter -h too high, but if i lowered it i got hashrate very low, lower than stak.
sure i'll fix the nicehash netcode.

So you're talking about Nicehash?
i didn't do my tests on nicehash but on a normal pool.
i think i understand where the problem may be now you told that's about nicehash

ho, and while you're near, let's talk again about why Claymore produce ~10% less effective hashrate: false negative.


we can observe the bad shares, the false positive. but it probably also gets a lot of valid shares it cannot compute well and skip. the false negative. hence why it display a high hashrate i never get pool side, even after 500h of mining. stak, xmrig, and sure jce, produce the good hashrate poolside, minus ~1% of stale shares, fees deduced.