End of development

Hello all,

Sorry for the 2-week blackout, but i'm coming with bad news: as I expected, i lost most of the dev time I used to have the previous 12 monthes and i now have virtually zero.

I could somehow cheat by taking the reference code I miss (CN-GPU, CN-Monero4, Wow...), compile it and get some fees for free, but that would be mishonnest. Rather than providing bad support, i prefer to explicit say i need to stop.

While the lack of time is the principal reason, i also noticed:
- A strong loss of value of Coins, only a few of them are still profitable, unless you have free power
- My competitors got a lot stronger. Xmrig/stak went from a naive C code (march 2018) to an on-the-fly assembly generator (march 2019). While not impossible, beating them would take a lot more time than it took one year ago when there were just three, simple forks.

I wish i had released one last farewell version, like with CN-ReverseWaltz, but i just have zero time left. I struggled to release the v8-capable in october (almost) in time, but for Monero4 i just can't.

I thank you all for your priceless comments, support and bug report, with a mention for Unclwish who found some crazy obscure bugs.
I'll put an explicit message in first post and GitHub page to state the last supported forks are the ones of jan/fev 2019 (Turtle v2 & al.) and that there will be none for Monero4.

Thanks again and goodbye,
  - JCE

Hi all!

@Unclwish: i may have a fix for your crash, but not sure as I cannot reproduce. I need more tests.

Webchain and Hycon: as said previously, i really don't think i'll have time for them, as they are coin-specific non-standard CN forks. Look at SRB which supports them for GPU mining, and the xmrig forks for CPU.

CN-GPU: it's so different that's no longer CN-ish I think i'll add them but Monero v9 will be the high priority fork, since, as you may have observed, i've very very little dev time left this year. The long part is not to support the fork, but to provide extra speed, otherwise it's non-sense to get fees for the same speed as the reference, open-source miners. And optimizing assembly takes a lot of time.

pool kick: yes  --forever --keepalive is the way to keep connected.

Hello,

Sure it would be helpful to get comparison with same algo...
stak mines with 3 threads with 2M cache each, for your total of 6M cache, which sounds good.

What happens if you mine with the same configuration with JCE ?
multi_hash:1 on three CPUs: 0, 1 and 2?

I'd expect you get at least on par results, not -40%.
Your current config using only 2 cores and 8M cache (2M overflood) is expected to be bad.

add --legacy to force low cpu usage. otherwise the cpu gets involved to sync the gpu and on a weak cpu, it may be heavy. depending on the rig it may be better or worse. looks like on yours it's worse, so use legacy mode.

hello,
while i didn't test on every possible card in existence, the gpu version should work down to the hd6000
If you were talking about the Linux version, it has no gpu support at all.

linux version 0.33q to be uploaded in about an hour, i'm finishing the package.

i expect you reach 800+ on new masari as an order of magnitude on a HD7950/270. i depends on the card, and of course you should flash the bios to use better memory timings, if not already done.

edit: it's online

Very interresting, so i may find the bug with no need to reproduce. I suspected the sync (that --legacy disable) to be able to cause such problem.
Thanks!

Yes, use the private messages feature of that forum please, i don't use social medias like Discord (too time consuming).
Also, i dev alone, no pural developers

@Unclwish: i mined the same way as you (Nicehash Heavy on GPU 0, one thread) and it worked for me. Sad i couldn't reproduce the bug. What happens when you add parameter --legacy ?

I'm building the 0.33b18 GPU, with the same changes as CPU:


edit: it's online now

A 33q CPU is online but I just noticed a bug when mining Masari v8 on a AES cpu with multi-hash=2 (reported on Github).
So I re-release it with the fix included. If you already downloaded 33q, wait a bit and redownload. The linux and GPU version will be released with the fix directly.

edit: it's fixed now. Then come the Linux and GPU version. I'll still give a try to reproduce Unclwish bug.

This may be true for any algo...
On TRTL v2, a AES cpu is close to an asic: all instructions are native (the 128-bits multiply, the 64 bits divide, the squareroot, and of course the AES) with all data fitting into the cache, assuming you have a decent CPU (read: not an Atom).

The next release will default Turtle to v2, as it has just forked, and will enable it among the eligible algo for pool autoswitch.
I'll release CPU version first.

As an exception, i'll ship the new Graft fork right now, with no test on a real pool (tested only on a local node). As --variation 22.
Sorry Unclwish I won't delay the release to investigate your bug since the Turtle fork is somewhat an emergency issue.

Hi all!

Unclwish: i note, i'll try to reproduce the bug on a 2-gpu rig.

HYC: both Hycon and Webchain are non-standard CN forks that would require a lot more refactoring of my netcode than the other forks, so, looking at how little dev time i've left now, i bypassed them for now. My next fork should be Graft. Take a look at SRB who added support for those both forks recently on GPU, and on CPU you can get the reference miner, possibly compiled with zero fees.
Both those forks are not CPU-friendly, and coin-specific, and since my miner is mostly a CPU miner, I somehow overlooked them on purpose. Turtle v2 and Masari v8 are a lot more interresting to mine on CPU.
Now I focus on CN-Waltz for Graft, which is a cleaner and better documented fork.

JCE as a virus: thanks all for the report, and yes that already happened several times, and there's little I can do above putting a warning about the fake releases on all my download pages (here page 1 and Github). I tends to happen to every miner software, very like being detected as a virus by Win Defender and al. That's the game

So sad how all those coin prices are on a down trend. Haven got its price divided by 10

i could reproduce the bug, right
Since I planned to add official support in b17 only, it doesn't change the plan, just i'll invalidate the b16 once b17 is online.
Thanks a lot for the report
The cpu part of b16 can still mine Masari, so there's clearly something missing in my opencl generator.

edit: yeah this was exactly the bug, something missing to handle Masari well.
The new 0.33b17 GPU replaces the b16, with

This is very summarized, but not wrong

Here's the 0.33p CPU Win and Linux, 32 and 64, minor revision

Next comes GPU version. You can already mine Masari v8 with the current 0.33n with parameter --variation 21

Hi all,

first i apologize for the long offline period, but this year i've clearly a lot less time to dev and provide support, as you may have noticed, and it's unlikely it will get better. I don't just give up but the daily releases of december won't happen again.

Quick support:
100% cpu on GPU mining: this is very not the normal behavior, try to add --low --legacy params

new algos
Graft: i'm waiting to see if that's still close to Monero, or a very different fork like Webchain
Masari: as i expected, this is just the same as Stellite v8, so you can already mine it with --variation 21

Still, i'll release new versions with this fork as the default fork for masari wallet (ditto for Stellite) plus the option to restart the miner instead of quit when the watchdog triggers.

Hi all!

Virus: sure, false positive, as with any other miner ever. There's no malicious behavior at all, it's a miner, it mines, period. Just be sure to download it from the github, otherwise the fake ones from Mega are trojan. I'm not related with them in any way, and they are online from almost the very first release of JCE in ~april 2018

Process control: you can pause all devices, and even close the miner itself remotely
Config edit: it's possible in an indirect way, with edition of file serviceconfig.txt (which may be a symlink to a remote file) and then restart. This way you can edit in any way: change pool, number of cpu, whatever.

@maedonald
there's a watchdog to close the miner in such case --watchdog N with N the minimum GPU hashrate (ignoring CPUs).
I didn't implement the restart because i experienced it to always fail with Claymore (the restart froze the miner or the whole PC).
But right, in next GPU version i'll add the option to make the watchdog restart instead of close, since it's a popular request.

Linux crashes: very interresting report. On a modern Ubuntu x64, the casual case. There may be a mem leak that doesn't show in the Windows version.
Did you use SSL? and/or Nicehash? The keepalive?
Those 3 params have an impact on the netcode. The main mining code is just a loop that hash and rehash on the same piece of ram, no allocation. But the netcode plays with the memory.

Stellite: right i release the GPU version now.

cpu perf: i did a lot of tests to compare 2 separate JCE instances against mixed mining, and found a way to slightly improve the efficiency, but my result were inconsistent since the cpu perf is very sensible to any external usage. So try the new version, with your 2 cpu threads plus GPUs and things should be like +1% better pool side. I hope.
I don't count it as a bug, but yes it lacked some optimizations.

0.33b16 GPU

Large pages: they are used the same way as day one, and enabled automatically by default, when possible, so when run as admin (at least once) on a Windows 10 and/or pro. otherwise (win 7/8) manual config is needed.

windows may run out of pages after some time, while it's more rare on linux. quick fix: reboot.

webchain, hycon: i answered just above. my top priority remains masari. any test pool somewhere?

let me look at that ryzen for best config. i've a r5 but no r3

Edit: try
--auto -t 2
and
--auto -t 4

one should be the optimal, i bet on 1st one

P4 32 bits crash on Linux: I'll redo a test on my Core2 duo, the oldest CPU i have, but not sure at all i can reproduce the bug
Sad it would have shined since old cpu mining is my niche expertise, but maybe you use some old Linux distrib or something. It's a lot harder to support linux well because of the large variety of distribs. And i'm also more a Windows person.

Large pages, see the doc here, it needs to be manually enabled, but that's the exact same as for any other miner, so if you find a guide for xmrstak/xmrig/whatever, it will work the same.
https://github.com/jceminer/cn_cpu_miner#large-pages

online is 0.33n CPU Windows

Hello all,
quick support today

Webchain and Hycon: no support yet. I know they got more popular after the support added into Srb, but i chose to focus on the CPU-friendly algos first (Masari and Turtle), as my miner is a mixed CPU/GPU miner. Webchain and Hycon are not special, except they use a pedantically different netcode than others.

@pbfarmer :
Your new data are easier to understand.
The missing hashrate being equal to CPU is coincidental, pause your CPU and you'll see a drop will remain.
The optimal yield you can get is ~99% (100% minus the fees) but depending on your pool aggressiveness, ping and overall CPU usage you may experience lower hashrate, while 96% is somehow in the lower bound. Mining with CPU + GPU has a normally little impact on performance, but it looks like on your rig, it's higher. Maybe because of the chipset or something, or the PCIe lanes used causes some internal delays.
Try to mine with 1 and 0 Cpu and i expect you'll get a better efficiency between the instant and effective hashrate. I already experienced such on one of my rig (a A320 + ryzen). Also remove the --legacy parameter if you use it, while it may provide more stable hashrate, it tends to lower the efficiency of mixed mining.

It's very possible you get different results with another mixed miner like Stak all-in-one, just because we did different choices in term of CPU/GPU sync and netcode aggressiveness. I chose a medium/high aggressivity, but not maximum, to keep a stable hashrate and zero bad shares. It may not be the best choice in term of absolute perf on your precise rig, but that's an overall all-around design.

RX 4G on Heavy/Tube:
try this as a base, for one card

Then try to increase multi_hash by steps of 16