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

[JCE-Miner]

exactly, if you have only GPU configured, you pay only the gpu fee 0.9% and this is true for all JCE-GPU versions from the very first.
But if you have a CPU configured and then you pause it, you will still pay for the CPU mining.

fees are logged at startup, if you read "CPU devfee" so you pay them, if you read "GPU devfee" so you pay them, if you read both, so you pay an average between both.

[samvicky]

I just asked to confirm that.So, that I could recommend your miner to my friends.

[JCE-Miner]

thanks

Is the (new) 0.32k working well on Vega?
I know there may be perf regression between 0.31f and the 0.32 since all code is new, but I cannot go back to the ultra-long compiling version 0.31

Try to re-configure the multi-hash values, 0.32 tend to prefer slightly bigger values (+16 or +32)

[samvicky]

It's working great ,currently doing 4295 hs.

[vmozara]

For me it sucks on CN7. Vega 64 rig dropped from 14800 to 14100. that is like 5% less I went back to 0.32j version.

[Lermite]

For me it sucks on CN7. Vega 64 rig dropped from 14800 to 14100. that is like 5% less I went back to 0.32j version.

Same here on three RX5.
Raising the multi-hash by 16 only worsen the hashrates or crashed the GPU.
Decreasing it by 16 didn't improve them. They remained unstable and lower than the 0.31f's.

[samvicky]

Mostly I mine cryptonight-lite v7 coins. My rig is pretty much stable.
This what I get after some over clocking.
21:07:06 | Hashrate CPU Thread 1: 150.02 h/s
21:07:06 | Hashrate CPU Thread 2: 152.76 h/s
21:07:06 | Hashrate CPU Thread 3: 152.82 h/s
21:07:06 | Hashrate CPU Thread 4: 144.86 h/s
21:07:06 | Hashrate CPU Thread 5: 149.35 h/s
21:07:06 | Hashrate CPU Thread 6: 152.20 h/s
21:07:06 | Hashrate CPU Thread 7: 152.64 h/s
21:07:06 | Hashrate CPU Thread 8: 146.10 h/s
21:07:06 | Hashrate CPU Thread 9: 150.32 h/s
21:07:06 | Hashrate CPU Thread 10: 153.36 h/s
21:07:06 | Hashrate CPU Thread 11: 153.38 h/s
21:07:06 | Hashrate CPU Thread 12: 141.62 h/s
21:07:06 | Hashrate CPU Thread 13: 145.26 h/s
21:07:06 | Hashrate CPU Thread 14: 148.97 h/s
21:07:06 | Hashrate CPU Thread 15: 148.18 h/s - Total CPUs: 2383.81 h/s
21:07:06 | Hashrate GPU Thread 16: 518.56 h/s
21:07:06 | Hashrate GPU Thread 17: 501.73 h/s - Total GPU 0: 1020.29 h/s
21:07:06 | Hashrate GPU Thread 18: 505.52 h/s
21:07:06 | Hashrate GPU Thread 19: 503.67 h/s - Total GPU 1: 1009.18 h/s
21:07:06 | Hashrate GPU Thread 20: 508.02 h/s
21:07:06 | Hashrate GPU Thread 21: 520.21 h/s - Total GPU 2: 1028.23 h/s
21:07:06 | Hashrate GPU Thread 22: 2152.51 h/s
21:07:06 | Hashrate GPU Thread 23: 2165.15 h/s - Total GPU 3: 4317.66 h/s
21:07:06 | Total: 9759.15 h/s - Max: 9775.47 h/s

[JCE-Miner]

On my RX560 i had a few more h/s on V7 with the k but the consensus is that it's worse, so i do a k2 version with 1rv1n and Lermite fixes but with j OpenCL. I'll look back at the perf later.

0.32k2 online, with exact same OpenCL as the j

[Lermite]

The 0.32k2 works fine to me, with the same hashrates than the 0.31f so it's worth the upgrade.

[JCE-Miner]

again, it took me three uploads to get one that works

Hoo i miss the time I was CPU only, it was simpler...

not, with hundreds to assemblies to update

[1rV1N]

@1rV1N : if you redo your test with version 0.32k, you should get a perfect one-for-one match between the yellow hashrate and your proxy. And no change pool side, since the fixes were cosmetical. Don't forget to add --no-cpu, or let your CPU really mine.

I took lastest version  32k use --no-cpu key
test 5 hours
count in proxy and Accepted shares in miner eq 3978
But.. network snifter says me all sent shares eq 4137
4137*0.961 = 3978

I think bug isn't fixed


Proof of I can use sniffer
43iLTAWVG....
95.213.2...

 

[JCE-Miner]

the wallet you cleverly found is… the donation wallet that is documented in the .bat of the very first version, even in the cpu or linux version, no need to do such hacks. I released the 0.32k almost just for you, and answered all your question, why being so aggressive?

there may be more fee shares if the fee diff is lower, that's very normal, and is a complain that Claymore experienced so much that he documented it in his FAQ.
i don't apply a fake 4% fee, the ratio is 0.9% randomized Claymore style. if you're still in doubt compare your hashrate (blue) with your pool/proxy hashrate, it won't be 4%. A lot of users before you did that bench and replied JCE gives 98% of power to their pool, ~1% fee ~1% stale. not 95%.

[samvicky]

Please add bitcoin2network algo.There bitcointalk link https://bitcointalk.org/index.php?topic=4311333.0

[JCE-Miner]

i'll take a look
i still have to add MOX too

[JCE-Miner]

@1RV1N : i've a last idea to convince you my fee are fair, then i give up.
since you wiresharked my netcode, measure :
P the period between two fee pool connections.
F the fee session duration. this is the time between the connection and the last fee share. not really, since the fee doesn't start immediately after the connect and the last fee share does not always happen at the exact time of end but that will give you the order of magnitude. do not measure between connect and disconnect, since i explicitly delay the disconnect not to overlap with the user pool reconnect, if any (it happens often with Nicehash).

and divide F by P. you'll get ~0.9% but not 4%.

since all values are randomized, take several sessions and do an average. in such case it will remove the diff bias and you should get a good value.

edit:

I think bug isn't fixed

Since i couldn't understand how you could measure a quadruple value, i re checked everything. I, again, confirm the fee session is 0.9% of time. May you do the test i explain above and you'll see. You can do your sniff test on every single version of JCE ever released, even the first CPU version, i never changed the fee system, always used the Claymore-style principle, with same fees (3%, 1.5%, 0.9% or mixed average). And maybe you should do a test on a pure CPU mining where the hashrate is ultra-stable, pool side you'll see the effective hashrate is consistent with the CPU hashrate, on the long term.

But I still found a bias.
The durations (all of them) are rounded up to the whole second. This is to have a light netcode (to give all power to the mining CPUs) and avoid the race case of a zero-length duration. It applies to both the normal and fee sessions. It also explains why, when you press H or R the report may take a split second to come. All is the same code.

Now the maths, in the worst case, it may turn
F/P into (F+1)/P or F/(P+1) or (F+1)/(P+1)

If F is big, it would be negligible. But F and P are the same order of magnitude as other miners like SRB or Stak or Claymore 10+ : P = ~6000 and F = ~50, randomized.
And F against F+1 with F=50 is a 2% bias in worst case, 0% bias in best case, 1% average.
Here i'm talking about percent of percent, so the real effective average fee level of JCE GPU is not 0.9% but 0.909%

it's a very low bias, and does not explain your number of 4%, but it's still a bias that worth to be fixed. Not an emergency, it will be fixed in next normal release.

[coke15]

hi

hum:maybe nanopool xmr is dead (no share arrive to it,but rigs are ok for days and no reboot,no lost connection)  or jce miner is stuck in devfee :/ since 9.00 this morning(french)

[JCE-Miner]

the wording is important, it cannot be stuck in devfee (which would mean i steal all your shares), but maybe because of fee session, it already happened to UnclWish and that's a bug I fixed a long time ago. The bug i evoked with 1rv1n above. The fee connection is hard cut (socket closed) after a few seconds the fee session ends (Something our felow hacker 1rv1n could confirm ) as an additional security, so that cannot happen.

What version of miner do you use?
Do you get "Accepted" replies?
If you use the display-fixed 0.32k2, is your yellow share counter increasing?
If yes, so the shares are sent to your pool, and, lucky, 1rv1n quote of yesterday

count in proxy and Accepted shares in miner eq 3978

confirms this.

edit:
I was thinking of something, i remember that Claymore watchdog had three triggers:
* stuck GPU
* temperature overheat or fan fail
* dead pool (not the comics!)

Since i'm adding the first two, it would be fine I add the third one too. If claymore had to make it, that's probably because it may happen, even if on my rigs, i never experienced it.

edit:
thanks to the high diff of nanopool, i managed to send one share (whoohoo!) and when i ask their API the current or historical hashrate, it says zero. So either their stats are dead, or there's a delay or thresold or something. I used a proxy like 1rv1n to check the share was sent to user pool, and it was.

edit:
i retried and i get either

Code:

{
    "status": false,
    "error": "No data found"
}

or

Code:

{
    "status": true,
    "data": 0
}

so up to this point, nanopool looks bad.

[coke15]

hi jc.
no it's good,nanopool was in the "choux"

 

[JCE-Miner]

good to read it. The first message not telling i'm stealing the fees for a long time!
I'm working on the watchdog and the new algos now.

[Iamtutut]

Tried the K2 version on bittube, with my GPUs I switched back to G version. Almost 4 hours mining, 2,4+ KH/s (reported stat from the miner) with 3 RX 570 4GB ^^