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

[JCE-Miner]

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

[Iamtutut]

STELLITE ANNOUNCEMENT, https://medium.com/stellitecash/fork-announcement-stellite-v5-63cc481a880a ."As fork height we decided the block 503001 and it should happen approximately 16/1/2019 1am UTC."

[dov17]

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

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

for V8 better -t 2 - 104 h/s
for turtles perfect -t 4 - 420 h/s 
This new CPU 200GE is a kind of RX550 (minimum price 55$ and minimum power consumption - tdp 35W)

[pbfarmer]

@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.

Thanks for the detailed explanation.  I've let my larger rig run about a week now, and it's stabilized at a ~3% spread, which is once again almost exactly the CPU h/r (pool is showing a 24hr of 9.8kh/s atm.)

Code:

{
  "hashrate":
  {
    "thread_0": 63.71,
    "thread_1": 63.67,
    "thread_2": 64.33,
    "thread_3": 64.33,
    "thread_4": 623.13,
    "thread_5": 623.13,
    "thread_6": 629.29,
    "thread_7": 623.13,
    "thread_8": 592.92,
    "thread_9": 598.50,
    "thread_10": 592.92,
    "thread_11": 592.92,
    "thread_12": 607.45,
    "thread_13": 610.76,
    "thread_14": 607.45,
    "thread_15": 604.18,
    "thread_16": 623.13,
    "thread_17": 622.92,
    "thread_18": 610.37,
    "thread_19": 604.57,
    "thread_all": [63.71, 63.67, 64.33, 64.33, 623.13, 623.13, 629.29, 623.13, 592.92, 598.50, 592.92, 592.92, 607.45, 610.76, 607.45, 604.18, 623.13, 622.92, 610.37, 604.57],
    "thread_gpu": [1246.25, 1252.41, 1191.41, 1185.83, 1218.21, 1211.63, 1246.05, 1214.93],
    "total": 10022.71,
    "max": 10256.21
  },
  "result":
  {
     "wallet": "bxc5rbWK8vhjHUvntsXoHxB5BxBcDmnApK8yBruAifJKASDLgwBZi2q7Q3zMSTmaLqhKu4gFgXEQjiyq7kKyhFH41un6Z7seX",
     "pool": "ca.bittube.miner.rocks:7777",
     "ssl": false,
     "reconnections": 0,
     "currency": "BitTube (TUBE)",
     "difficulty": 529002,
     "shares": 10489,
     "hashes": 5461064802,
     "uptime": "155:34:01",
     "effective": 9751.19
  },
  "gpu_status":
  [
    { "index": 0, "temperature": 39, "fan": 21, "processor": "Ellesmere", "memory": 8192, "good_shares": 1324, "bad_shares": 0 },
    { "index": 1, "temperature": 40, "fan": 27, "processor": "Ellesmere", "memory": 8192, "good_shares": 1388, "bad_shares": 0 },
    { "index": 2, "temperature": 39, "fan": 30, "processor": "Ellesmere", "memory": 8192, "good_shares": 1280, "bad_shares": 0 },
    { "index": 3, "temperature": 40, "fan": 23, "processor": "Ellesmere", "memory": 8192, "good_shares": 1285, "bad_shares": 0 },
    { "index": 4, "temperature": 39, "fan": 36, "processor": "Ellesmere", "memory": 8192, "good_shares": 1262, "bad_shares": 0 },
    { "index": 5, "temperature": 39, "fan": 24, "processor": "Ellesmere", "memory": 8192, "good_shares": 1312, "bad_shares": 0 },
    { "index": 6, "temperature": 39, "fan": 22, "processor": "Ellesmere", "memory": 8192, "good_shares": 1285, "bad_shares": 0 },
    { "index": 7, "temperature": 39, "fan": 33, "processor": "Ellesmere", "memory": 8192, "good_shares": 1282, "bad_shares": 0 }
  ],
  "miner":
  {
     "version": "jce/0.33b14/gpu",
     "platform": "AMD Ryzen 5 1600 Six-Core Processor ",
     "system": "Windows 64-bits",
     "algorithm": "13"
  }
}

I wasn't really comparing yours to other miners - I already know yours is the best.  But the part that doesn't align w/ your explanation (and why i suggested there may be a bug) is that this discrepancy goes away when the gpu and cpu are split into independent processes.  Really not a big deal at all - i'm fine splitting them, just thought i'd give you a heads up in case it was something that could be fixed.

[JCE-Miner]

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

* Stellite v8
* Rig-id
* Light optim for mixed cpu/gpu mining

[Megansbay]

Hello,

I'm adding on to the "Segmentation fault (core dumped)" conversation . I am running release "m" on two Linux boxes and the miner periodically crashes on both systems. Sometimes they run for a large number of hours and sometimes they fail quickly. So far I have not made it past 24 hours on either system without re-starting the miners. Here are the specs for each box:


System One
Z87-GD65 GAMING (MS-7845)                         - motherboard
Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz   - processor
32GiB                                                                 - memory
Ubuntu 18.04.1 LTS                                           - OS

System Two
ASRock 970 Extreme4                                      - motherboard
AMD FX-8320E Eight-Core Processor              - processor
12GiB                                                                 - memory
Ubuntu 18.10                                                     - OS

An additional comment is that I experienced the same core dumps with the prior JCE release. I wanted to add this information for you because the problem seems to be more general in nature given that it is happening across different distros and hardware configs. My final observation is that I am running the miner on two WIN-10 boxes and I have had a couple of segmentation faults on them as well although they are running mostly with out issue.

Hope this helps a bit!

[ILYA_Zzz]

@JCE-Miner: Sorry for not responding immediately, and thanks for the quick response and improvements!
--mport - checked at the very beginning (033j).
--mpsw - unfortunately not working.
  Memories of Clamore (Standalone utility "EthMan").
1. Monitoring: online / offline
2. Process control: start / stop
3. Configuration editing: 1 core or 16, change pool.
- without having to go to the PC by the ip address or physically.
I hope that someday I will be able to remotely control, as before

[maedonald]

How to restart miner if hashrate lower than specific number

[th3dark1nSid3me]

Trying to set up your miner and have a look.

The jce_cn_gpu_miner64.exe is identified as "Win64/Packed.Enigma.Q" by ESET. "Enigma" and "trojan" are 2 things I want my computer far away from.
I know that all mining software give false positives but having an alert from my antivirus for a known trojan that encrypted everything and asked for ransom is not a pretty site.

Any inputs on this?

[Iamtutut]

Read the doc, it's a false flag.

No issue

[Iamtutut]

With my usual config, I get around 7.5KH/s with Stellite v5 algo. It's power hungry at 540W/h
Config is 4 RX 574 with bios mod.

[JCE-Miner]

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.

[Uaciuganadu]

Hey JCE,

Any plans of speed improvement and maybe algo switch on GPU?

[nordmann666]

tried new GPU Version with TRTL - Vega auto settings give only 4khs on each vega...tried my old cn_lite config...same Hs

the miner hiimself runs realy realy slow (pressing h = it need some seconds for displaying the hs rates).

whats wrong? it should run with --auto (not optimized but better than 4khs)

[HardKano]

@JCE-Miner : you should follow it for your GPU software update and test it before they implement it. Graft will create their own algo : https://www.graft.network/2019/01/23/nicehash-attacks-update/

[livada]

tried new GPU Version with TRTL - Vega auto settings give only 4khs on each vega...tried my old cn_lite config...same Hs

the miner hiimself runs realy realy slow (pressing h = it need some seconds for displaying the hs rates).

whats wrong? it should run with --auto (not optimized but better than 4khs)

trtl algo give 16000hr on vega 56

[nordmann666]

tried new GPU Version with TRTL - Vega auto settings give only 4khs on each vega...tried my old cn_lite config...same Hs

the miner hiimself runs realy realy slow (pressing h = it need some seconds for displaying the hs rates).

whats wrong? it should run with --auto (not optimized but better than 4khs)

trtl algo give 16000hr on vega 56

...config please!

and also with --no-cpu the cpu is on 100% - thats why also is laggy

[Azzgard1980]

HI JCE, What about massari fork ?

[JCE-Miner]

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.

[HardKano]

Cool JCE ! Real life and bills to pay ! I hope your miner will get more traction and you might be able to retire and live from developing it 😎