Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 104. (Read 211762 times)

Hello ,
I have a lot of rejected share on nanopool and I want to switch to support xmr:

Can you help me with the config file, which one is correct for supportxmr:

teamredminer.exe -a cnr -o stratum+tcp://pool.supportxmr.com:7777 -u -p MyWorker:email -d 0,1 --cn_config 16+14,8+8

or

teamredminer.exe -a cnr -o stratum+tcp://pool.supportxmr.com:7777 -u -p x -d 0,1 --cn_config 16+14,8+8

or something else ?

This sounds more like the older win terminal issue, should be gone in the next release. Please add —disable_colors.

But... we only support Fiji/Tonga and up though, Hawaii and Tahiti gpus will not work, so even if you get the terminal output going you won’t get the gpus mining .

Yes, 14+14 will increase the rejects for sure, I’d go for 8+8 unless 14+14 is much much better.

Anyone had any luck getting this miner to run on older AMD gpus like the Radeon 7970/280X or the R9 290 ?

I've tried with various AMD drivers from 15.12-19.03 and the program starts and nothing happens. It doesn't freeze or lock the system up, but it just displays the title and that's all.

I tried to run the parameter --list_devices and nothing happens, basically same issue. Tried with both the Lyra and the XMR bat shortcuts provided.

What about optimal settings for Polaris 8Gb cards? On my RX 588 - one of them best settings is 8+8, on other 14+14.

For a CN gpu miner of any sort, with Nanopool rejecting any share belonging to an old job from their perspective, a 1.5-2% reject ratio is to be expected:

• One run of hashes takes ~1.8 secs on a Vega/Polaris gpu. Sometimes more, sometimes less, it also depends on your nr pads used, but this is a good average.
• Nanopool sends out a new job on avg every 47 secs, assuming my logs from 6-7h of mining yesterday provide a good avg.
• During the 1.8 secs it takes to complete a batch of hashes, any result(s) from that wave will be useless.
• On average, you will be in the middle of a hash calculation when a new job appears, so on avg 0.9 secs of gpu runtime will be worthless per job.

The above is simplified, we have some guarantees around our two threads, the nrs aren't fully accurate, you can implement an abort mechanism etc, but the simple point I'm trying to make is that 0.9 / 47 = 1.9%. Add a little network latency for 50ms roundtrip time and you have 0.95 / 47 = 2.02%. Given Nanopool's policy of not accepting any stale share and the fact that we always send all shares found to the pool, regardless if we've received a new job or not, miners will end up with a ~2% reject ratio.

To the best of my knowledge, Nanopool had the same policy for CNv8, so it really is a little surprising if people were seeing close to 0% rejects over time, I'm quite certain I wasn't myself. Supportxmr has pretty much the reverse strategy, they accept any shares that aren't from the stone age, that's why people see 0% rejected shares there. The Nanopool strategy favors cpu miners over gpu miners, supportxmr favors gpu miners over cpu miners by actually accepting some shares that never can be converted into network blocks, and those will typically be submitted by gpu miners. Nicehash is utter shit since they have the shortest avg job time among all "pools" which further amplifies the scenario above.

All this said, I will be running a A+B test tomorrow on my 8x Vega rig, testing TRM 0.4.1 vs xmrig with 4x Vegas each. If xmrig would have a statistically significant lower reject ratio after enough mining time I will continue to investigate.

No problem - happy to share...

Re 56 settings - mine is also a flashed ref, but i'm targeting 1400 cclock (tho only getting to ~1365), so maybe that's the difference.  14+16 was the clear winner for me (though I just realized I haven't tried 14+15.)  As for the 14+16 vs 16+14, if the intention is for both to perform the same, I suppose it doesn't matter as long as one works - more of an oddity then.

Re efficiency - I would say it's roughly the same, but the comparison isn't clear-cut.  My notes on cnv2 are only for a single nitro 64 on Windows - showing 2120h/s @ 825mv for 163w ATW (~13 h/w).  This 64 is a ref on linux, running 2140h/s @ 831mv - i don't have a great wall reading yet.  Both were targeting a 1400 effective cclock (w/ 1107 mclock,) so for the most part i would only expect a 1-2% increase in power based on the mv bump. 

I have a rig w/ 6 nitros and a couple other polaris which I'm about to swap out to make a full 8 x nitro 64 rig - I'll get a good avg once that's done and post back.

120001 is not very low difficulty.

On v8 nanopool had no issues with TRM v0.3.8 with that same fixed difficulty so the current issue is either with nanopool or TRM v0.4.1.

Hey man, as always, thanks for your testing and for sharing the results!

My two cents on your findings: for the 16+14 vs 15+15 on the Vega 64, it should still be the case that 15+15 is the better choice _unless_ you go for a 1500+ cclk. With CN/r and the pretty expensive random ops they added, the higher cclk (probably) kills efficiency in a different way than for CNv8 with a higher cclk. I haven't verified this in practice though, but anything else would be most unexpected. For the V56, 14+14 is the best overall choice for me as well. Most of my V56s are reference cards flashed with V64 bioses, 14+14 still being my optimal choice.

The 14+16 vs 16+14 issue is very surprising, and a driver issue/feature for sure. It will allocate exactly the same amount of memory in both cases, only the order in which certain larger blocks of memory are allocated differs. Somehow this triggers a different allocation path in this driver/config/setup. The numbers are typical for those you can see under Windows when the drivers allows an allocation but actually considers the gpu to be out of mem, instead mapping part(s) of the allocated buffer to host-side memory, and every mem op on the gpu not hitting a cache becomes a PCIe operation. That is at least my own working theory for what happens under Windows. I can't say if the same thing is happening here, only guessing at this point.

May I ask about the efficiency compared to CNv8, assuming that's what you have tuned for?

W/ the GPU clocks/voltages now fully dialed-in, here are the results of the intensity settings (64, then 56):

15+15, 14+14: 2140, 1960
15+15, 15+15: 2140, 1960
14+16, 14+16: 2090, 1990
16+14, 16+14: 770, 1100-1400

Best:
15+15, 14+16: 2140, 1990

I also ran each card individually on 16+14.  Behavior was the same, so it's not one card failing and affecting the other - 16+14 is just no good.

Btw, this is on Ubuntu 18.04 + amdgpu-pro 18.50 (and still using 0.4.0)

Nanopool can't set the difficulty.
And fixed at a very low difficulty.

Left nanopool ,3hours on  supportxmr almost %0 rejects.

Can confirm the "--no_cpu_check" helped a bit on Nanopool.
Went from 2% rejected to 1.75% (tested over 24 hours). Nothing revolutionary but hey.
Probably worth switching pool though. Thinking about the big picture here... Adding up dev fee + pool fee + rejects and you're losing ~5% of your hash.

Any update on when the rejected shares problem on nanopool will be fixed.

I have two systems running TMR 0.4.1 (one with 2x Vega 56's, one with 3x Vega 56's) and both are showing about 2% rejects on nanopool.

2x Vega 56: a:1254 r:26 hw:0 - 2% rejection rate
3x Vega 56: a:1842 r:34 hw:0 - 1.8% rejection rate

if you're asking that question i would suggest win10.

Hi guys. Which os need to be installed for best perfomance on rx470 and rx550/2 with this miner? Thx.

Great , thanks for the answer

Yes, run miner with --help to see all available args. This is what you want:

Hello ,
Is it possible to record log on this miner ? One of mine is freezing but I need to hard reboot it without possibility to know what card crash

Thanks for all the advice.  Yeah, 1V is uber.  But power draw and temps are reasonable. 
I reduced core freq and mem freq to 1150/1975 with core volt 925 and rig ran stably overnight, both cards hashing at 935H/s.   Still memory errors.  Will work on these three parameters when I get home from work:
Core freq
Core volt
Mem freq
Looks like the mem strap is too tight for CNR, so will have to reduce mem freq further.   Cards work flawlessly at 1100/2000 on ETH with core volt at 813mV.
For CNR core volt needs at least 925 mV...
Anyhow, the miner software looks to be stable.  Thankyou goes to the developers.