Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 58. (Read 90841 times)

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

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.

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;

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.

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

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

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.

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.

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 ^^

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.

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

 

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

or

so up to this point, nanopool looks bad.

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)

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

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.

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

Please add bitcoin2network algo.There bitcointalk link https://bitcointalksearch.org/topic/ann-bitcoin2network-pow-cryptonightb2n-privacy-freedom-equality-4311333

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

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

 

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

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

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