[ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More

[kerney666]

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

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

Code:

      --log_file=FILENAME   Enables logging of miner output into the file
                              specified by FILENAME.

[1715295959]

1715295959

[1715295959]

1715295959

[1715295959]

1715295959

[1715295959]

1715295959

[1715295959]

1715295959

[carlosmonaco]

Great , thanks for the answer

[jazz1984]

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

[heavyarms1912]

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

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

[MinersRus]

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

[dragonmike]

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

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.

[fenomenyaa]

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

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.

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

[wei0339]

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

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.

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

[pbfarmer]

@kerney666 @todxx

Not sure if this is by design, but just noticed, 16+14 is very different from 14+16 - at least on linux/cnr.  On a 2 vega (56 + 64) rig I'm benching w/ 1350(actual)/1107 clocks, running 14+16 produces a pretty stable ~1970 h/s each, but 16+14 produced very strange behavior, where the first vega (64) was running ~750 h/s, while the second (56) was bouncing around between 1100-1500 h/s.

That is odd behavior. The only thing that would/should be affected is the order in which large gpu mem allocations are done at init time. What happens with 15+15 for the V64 and 14+14 for the V56 in the same setup?

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)

[kerney666]

@kerney666 @todxx

Not sure if this is by design, but just noticed, 16+14 is very different from 14+16 - at least on linux/cnr.  On a 2 vega (56 + 64) rig I'm benching w/ 1350(actual)/1107 clocks, running 14+16 produces a pretty stable ~1970 h/s each, but 16+14 produced very strange behavior, where the first vega (64) was running ~750 h/s, while the second (56) was bouncing around between 1100-1500 h/s.

That is odd behavior. The only thing that would/should be affected is the order in which large gpu mem allocations are done at init time. What happens with 15+15 for the V64 and 14+14 for the V56 in the same setup?

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

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?

[MinersRus]

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

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.

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

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.

[pbfarmer]

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?

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.

[kerney666]

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

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.

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

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.

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.

[UnclWish]

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

[adaseb]

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.

[kerney666]

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

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

[kerney666]

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.

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 .

[carlosmonaco]

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 <wallet> -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 <wallet.worker/email> -p x -d 0,1 --cn_config 16+14,8+8

or something else ?

[jazz1984]

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

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

I asking that because i was testing my rx470 on win 7 and i have not even 700 Hashes on v8, and on R. Now i think about some rx550/2, and i dont know what os will be better for that rig Thank you for reply.

[kerney666]

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 <wallet> -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 <wallet.worker/email> -p x -d 0,1 --cn_config 16+14,8+8

or something else ?

Iirc the first one. User field is for wallet and also static diff, i.e. if you want e.g. 10000 static diff you set user to "<wallet>+10000". Worker id and email go into the password, like you suggested.