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

[JCE-Miner]

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

Already possible with --any --variation 9

MKT and B2N forks are the same. SRB call it B2N and i call it MKT. I'll just update the doc to say MKT/B2N and auto detect the wallet.

[1715398889]

1715398889

[Sx5000]

Thanks for the base version of watchdog. But from the log it is not clear why it worked.
https://pastebin.com/sUMQMsbp
There is also no adjustment of the response time. And it would be nice that before the exit, the miner would show the current hash of the cards, in order to understand which of the cards fails.

[lebuawu2]

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

you should mention you mining which coin on which pool? did you use static diff or dynamic?
3978 accepted shares count by miner and proxy.
4137 is it accepted shares or only job that sent by miner? because I experienced with phoenixminer and ethermine pool, not all stale shares return by pool.
I think the way dev fee works is base on timer so I guess you cannot count dev fee base on accepted shares because every minutes accepted shares is different.
so if you want to prove somethings wrong with dev fee I think you should check when dev fee started and when dev fee ended.

for me I prefer to check statistic from pool side and try some of them (not only one).

[1rV1N]

you should mention you mining which coin on which pool? did you use static diff or dynamic?
3978 accepted shares count by miner and proxy.
4137 is it accepted shares or only job that sent by miner? because I experienced with phoenixminer and ethermine pool, not all stale shares return by pool.
I think the way dev fee works is base on timer so I guess you cannot count dev fee base on accepted shares because every minutes accepted shares is different.
so if you want to prove somethings wrong with dev fee I think you should check when dev fee started and when dev fee ended.

for me I prefer to check statistic from pool side and try some of them (not only one).

I use my own proxy and my pool and also i use static diff
I count submitted shares.

I will show my tests in couple days

[JCE-Miner]

count fee session time, to avoid luck bias.

do you trust me if i say i don't make your rig magically mine faster when the fee starts?
so measuring time is good.
fee session is every ~100 minutes and last ~1mn. if you detect them at 4 minutes, so there's a problem, but i checked code and behavior and observed those durations.

sure the watchdog needs tuning, the stuck detect looks good but the speed trigger is still primitive.

[wyzdic]

Bittube testing
Vega 64 1570-1600H/s
Vega 56 flash 64 with samsung mem only 1250H/s
0.32k and 0.32j;
Driver 18.6.1;
Windows 10 LTSB;

[heavyarms1912]

suggestion:  In --watchdog N, let the miner figure out after 5 minutes what's the stable value for N and have a user config variable for hashrate drop limit to value 'x'.  So anytime the miner hashrate N drops by value 'x' then reboot miner/rig based on user config.  That saves time for the user to not have different values of N for different CN coins and figuring out hashrate anytime things change.

[laik2]

Hi there,
Do you have any plans(ETA) for linux version?

[JCE-Miner]

Hi all, sorry I had very little time those days

Linux: no ETA so far, i don't even consider the Windows gpu version mature yet. but the cpu version is.

Watchdog: for now i prefer delegate the limit setting to the user, since my warmup may fail and mine at 80% even for more than 5mn

for 1G card start with a very very low single-thread config like multi_hash 64 then increase by step of 16. i tested jce fine on hd 6000 and 7000, not 8000 but it should work if well configured, but will probably mine slowly.

[UnclWish]

JCE did you plan to add overclock/voltage/fan control to GPU miner?

[JCE-Miner]

* Watchdog has to be inside the miner, and it's safe, so I add it
* Fan/temp could be monitored from outside, but it's safe, so I add it
* Voltage/fan control can be controller from outside with excellent tools (like overdriveNTool) and is dangerous.

If I add this feature, which would be very easy since I already have code for the fan/temp, it could make JCE responsible (yet indirectly) from buring a GPU, and so i'll have to add tons of disclaimers and warnings Use at own risks, i'm nor responsible for ....

So the answer is an explicit No.

I usually follow Claymore choices about miner code, but not this time.

A completely different topic: MOX

I'm done implementing that fork, and I did it by reading the reference code of mox-rig, the official miner, a fork of xmrig. So far so good.
But after having read the code, i'm wondering whether the dev is very very bad, or very malicious. I give details:

* The fork is not done normally with github, but is a copy-paste of the source. So there's no history and no way to compare with original xmrig, at least not with the normal github tool.
* the first commit is already MOXed
* The doc says MOX is CN-v7 with a light change. This is wrong.
* The code says this is like XTL, which is wrong too.
* The old unit tests are present, but disabled in a very strange fashion. The mox unit test does not exists.
* The miner can be configured to mine good old CN-v7 or Arto, but will produce only bad shares in such case.

All in all, i advice not to use MOX, or at least not to mine with the reference miners. The only other one, waiting for my next release, is SRB, which is both 3rd party and officially listed by the mox team. So i say nothing about it. Maybe the mox dev is fair and just ridiculously bad, and there's no threat here, but all those strange things in the same project looks suspicious to me.

I'll still provide my own implementation, and it will be the fastest on CPU, on par with TRTL.

[vmozara]

I support your decision to keep the overclocking tool out of the miner. This has to be done externally by specialized tool, if one doesn't know how to setup his rig he should not really mine at all. Also, an overclocking capability will open sea of troubles, problems, compatibility issues and questions for you. I don't believe you are paid well enough to handle that.

In my opinion, just give us stable and efficient miner and we will do the rest.  

I never heard of MOX. You should share this information in MOX topic (if it exists) and on reddit so people can avoid shitcoins and scamcoins. Just look at the front page of this forum, there are at least 3 scam miners promoting themselves. 

[Mighty_crypt]

JCE miner is absolutely faster ,just tried it out last night and the results is huge compare to xmrig that I was using before,thanks

[nordmann666]

love that miner...hoped for MOX that i can switch from SRB - but...will wait

other question

i mine TRTL with GPU @8KHs and with Ryzen @2KHs
BUT why the Masari Fork with GPU @7KHs and Ryzen only @800KHs - shouldnt it be a bit more with Ryzen? (i use auto mode)

[UnclWish]

I didn't support dicision about not implementing OC/V/Fan controls... If user didn't know about settings to OC/V/Fan controls he didn't use them. I think, that controls like in Claymore is very usefull. Didn't need to use any 3rd tools. Just set for each algo needed settings in bat or cfg file. Mining is dangerous itself, and even without this settings miner make stress to GPU's. Users that didn't know that shoudn't mines at all...
So adding this controls may be very-very usefull for people, who didn't use overdriveNTool like me...

[Iamtutut]

Mined XTL (Stellite) non stop for 30-35hs, the hashrate at the pool was exactly what it's supposed to be, slightly above 2.7KH/s for my setup.
Wish I can find a cheap Vega 64 to play with.

[monote]

I just got the last version 32k2 and it's working super stable (as happened for me with 31f)
BUT fixed diff still not working for me...I really have NO clue why...
Anyone having this issue???
Cheers!

[Lermite]

...fixed diff still not working for me...I really have NO clue why...

Not every pools handle the fixed difficulty feature, and each one that handles it does it in its own way, usually with wallet.diff or wallet+diff in the wallet field.

Which pool are you using?

[monote]

...fixed diff still not working for me...I really have NO clue why...

Not every pools handle the fixed difficulty feature, and each one that handles it does it in its own way, usually with wallet.diff or wallet+diff in the wallet field.

Which pool are you using?

I know! This pool does support it.
I'm here:
https://bxc.mine2gether.com

[vmozara]

Did you try another pool, before anything else - I am asking this because for all my rigs effective hashrate on long term is about the same as nominal hashrate (that is the primary reason why I went away from srb and cast miners, as the effective hashrate was 10-20% less than miner shown hashrate)