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

[todxx]

Code:

[2018-11-07 03:02:09] Pool xmr-us-east1.nanopool.org share accepted. (GPU4) (4726/4575/95)
[2018-11-07 03:02:13] Pool xmr-us-east1.nanopool.org share accepted. (GPU1) (4728/4576/95)
[2018-11-07 03:02:13] Pool xmr-us-east1.nanopool.org failed to parse server rpc: {"id":101,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}

how to fix that?

what method are you guys using to have a fixed core clock ?
i set it up for let's say 1400mhz for vega56 using overdriventool but when watching it with HWiNFO is not the same it's about 1350Mhz
The readme file states that core clock is the way to get a better hashrate using this miner I want to take advantage of that and it is said that used ppt mod i guess that means SoftPowerTables ?
any hint appreciated

Hey Germini,

The error you're seeing is because nanopool's stratum doesn't follow the standard protocol.  We will have a work-around option for pools like this in the next release.
As for your card clocking down, is the card thermal or power throttling?  What temperatures does it report?  What voltage are you using for the 1400 clock?

[1715355545]

1715355545

[1715355545]

1715355545

[1715355545]

1715355545

[1715355545]

1715355545

[1715355545]

1715355545

[williet]

these guys with rx 570/580 hashing below 1kh/s i think are doing it wrong. check your straps and oc.

all of my rx 570 hashes above atleast 1kh be it 4gb or 8gb. the only problem i have is micron, which i think is the worst in cn variants.

Agree, matches what we found as well. Haven't really found any card stuck below 1kh/s, except for Micron mem where we've been stuck around 860 h/s on some cards whatever we try for straps and clocks. Samsung by far the easiest, Hynix often also just a copy of lower-to-higher straps. And, I'm really not that good with straps, I should add.

Great job TeamRed!

Read every post here, testing rig for about 8 hours without crash. Now trying to fine tune.

Here is mixed rig (1 x rx570 4GB Elpida, 2 x Vega 56 referent + 1 Vega 64 Asus Strix)
Vega 56 hashing about 2000 H/s, Vega 64 2240 H/s). Vega 56 have low clock and memory 1408/1088 because on SRB is overheating and crashing on more clocks. Vega 64 is on 1520/1100.

Funny thing about RX570 is that hashrate of RX570 somehow depends of configuration on Vega cards.

When i first start miner (without --cn_config) RX570 Nitro + (Elpida) hash 920 H/s with timings 1200/1980.

Than I experiment and put on RX570 7+7 (default was 8+7) and lower clock and memory to 1225/1940 (as user Dragonmike recommended). Playing with OverdriveNtool when hashing, been able to get 942 H/s with 1200/1920 but i think that time i put Vega 56 to 15+15.

When i restarted rig, RX 570 hash just 880 H/s? Try appy OverdriveNtool with same clocks as before 1200/1920 but still 880 H/s. Than i apply 1250/1980 and still 880 H/s. mV for clock and memory 900 mV.

What am i missing and is it possible and where to delete kernel files to make automatic initialization of the cards again?

That sounds a little weird. I don’t know if you restarted the miner or rebooted the rig in between runs? One issue we have (which I’m a little ashamed of tbh) is our unclean shutdown. It has led to me losing perf between restarts at times. Can you reproduce your test, i.e. whenever you run the 570 only after a clean reboot you hit ~940 h/s, but 570+Vegas after a clean reboot and it’s lower for the 570?

Yes, something with RX570 4GB is weird.

Tested a little, two times rebooted the whole rig and whatever clocks applied max hash is just 880 H/s.

Than rebooted third time, and my Task Scheduler automatic run SRB Miner.bat and apply Overdrive profile and my RX570 hash 910 H/s in V8 which is normal to me in SRB Miner for this card.

And than weird again :-) start TRM and RX570 hash with same 910 H/s like in SRB :-) Bump from 880 to 910.

I leave it that way from last night almost 24 hours stable running:
[2018-11-06 21:28:13] Stats GPU 0 - cnv8: 910.2 h/s, avg 906.8 h/s, pool 924.0 h/s 386/0
[2018-11-06 21:28:13] Stats GPU 1 - cnv8: 1.998kh/s, avg 1.996kh/s, pool 1.895kh/s 787/0
[2018-11-06 21:28:13] Stats GPU 2 - cnv8: 2.202kh/s, avg 2.242kh/s, pool 2.232kh/s 926/0
[2018-11-06 21:28:13] Stats GPU 3 - cnv8: 1.997kh/s, avg 2.002kh/s, pool 2.002kh/s 833/0
[2018-11-06 21:28:13] Stats Total - cnv8: 7.107kh/s, avg 7.148kh/s, pool 7.053kh/s

Here is this (for me) stable Setup of mixed rig with 730W from the wall (-50W and + 300 H/s):
Win 10, Adrenalin 18.6.1
GPU 0 (RX 570 4GB Elpida Nitro+) 7+7 core 1180/850 mV memory: 1980/900 mV. One click strap.
GPU 1 (Vega 56 ref. with 64 bios ) 16+14 core 1408/950 mV memory: 1070/950 mV
GPU 2 (Vega 64 Asus Strix) 16+14 core 1520/920 mV memory: 1100/910 mV
GPU 3 (Vega 56 ref. with 64 bios ) 16+14 core 1408/955 mV memory: 1088/945 mV

As you can see, Vega 56 ref with Samsung mem can in your rig hash much better with more clock on core and mem, i must lower it because rig is in small space and overheating. Waiting for the winter to come :-)

I tested intensity and found that Vega 56 Reference even on this lower clocks still more like 16+14, than 15+15.

Change your Vega 56 back to stock.

I get on 16+14  1500 clock and 950mem 2050h/s

[GreyGhost_rc]

What will my bat file script be if I want to mine on Nicehash pool? anyone?

I just wanna try it for a week or so...

[seefatlow]

Thank you dev for this amazing miner. It worked flawlessly right off the bat!!

I have a 9 Vega card rig and it's running 120W less than SRBminer off the wall at a 1K higher hashrate. Kudos.

Eagerly waiting for other CN variant support and AMD CGN optimization for X16r algo. 

[kerney666]

What will my bat file script be if I want to mine on Nicehash pool? anyone?

I just wanna try it for a week or so...

Hi! Nicehash is supported out of the box, no special parameter. Do you need help to get the miner going in general?

This is an example command line running against Nicehash that will run using automatic config using all AMD gpus it can find. You might want to change the stratum server location from usa to one of eu, hk, jp, in, br depending on your location.

teamredminer.exe -a cnv8 -o stratum+tcp://cryptonightv8.usa.nicehash.com:3367 -u 3D35kjxxxxxxxxxxxxxxxxxxx -p x

If it doesn't work or your hashrates aren't the expected ones, dump the output here and we'll make a manual config.

[kerney666]

Thank you dev for this amazing miner. It worked flawlessly right off the bat!!

I have a 9 Vega card rig and it's running 120W less than SRBminer off the wall at a 1K higher hashrate. Kudos.

Eagerly waiting for other CN variant support and AMD CGN optimization for X16r algo. 

Thank you! We're on it, we'll be releasing a stability release within a day, there has been a number of early issues to weed out. Many users still have random gpus not working in the init process, that should be solved now! After that we should hopefully be able to return to the gpu side and start banging out more algos!

[peterboy1]

ill be waiting for that new release today. im having a random rig freeze today.

hopefully you could add more algo soon.

[Germini]

Code:

[2018-11-07 03:02:09] Pool xmr-us-east1.nanopool.org share accepted. (GPU4) (4726/4575/95)
[2018-11-07 03:02:13] Pool xmr-us-east1.nanopool.org share accepted. (GPU1) (4728/4576/95)
[2018-11-07 03:02:13] Pool xmr-us-east1.nanopool.org failed to parse server rpc: {"id":101,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}

how to fix that?

what method are you guys using to have a fixed core clock ?
i set it up for let's say 1400mhz for vega56 using overdriventool but when watching it with HWiNFO is not the same it's about 1350Mhz
The readme file states that core clock is the way to get a better hashrate using this miner I want to take advantage of that and it is said that used ppt mod i guess that means SoftPowerTables ?
any hint appreciated

Hey Germini,

The error you're seeing is because nanopool's stratum doesn't follow the standard protocol.  We will have a work-around option for pools like this in the next release.
As for your card clocking down, is the card thermal or power throttling?  What temperatures does it report?  What voltage are you using for the 1400 clock?

this are the settings for some of the cards all vega56 others use lower mem clock that is the only clock stable and fixed.
 temps are stable in those values I think they are ok don't know how to see if it's power throttling
http://i98.fastpic.ru/big/2018/1107/2c/542857353862d14b7e75f64e92c8d52c.jpg

Thanks

[kerney666]

ill be waiting for that new release today. im having a random rig freeze today.

hopefully you could add more algo soon.

This isn't critical, I'm mostly curious: was it a Vega or Polaris card? And, did the issue happen at startup or later?

[Hackintoshihope]

ill be waiting for that new release today. im having a random rig freeze today.

hopefully you could add more algo soon.

This isn't critical, I'm mostly curious: was it a Vega or Polaris card? And, did the issue happen at startup or later?

Just to respond to your question on my end Vega. I have somewhat random freezes where it gives a posix win threads error? Also when the computer restarts usually a bluescreen error accompanies this then the miner doesn't initialize a card on restart and i get 0H/s.

[kerney666]

ill be waiting for that new release today. im having a random rig freeze today.

hopefully you could add more algo soon.

This isn't critical, I'm mostly curious: was it a Vega or Polaris card? And, did the issue happen at startup or later?

Just to respond to your question on my end Vega. I have somewhat random freezes where it gives a posix win threads error? Also when the computer restarts usually a bluescreen error accompanies this then the miner doesn't initialize a card on restart and i get 0H/s.

Hm, the posix win threads error seems like a crash, either voluntary or unexpected. Did you see the last outputs in the display before this happened? Did we report any clear error message?

The issue that we have addressed is purely on startup, the current version will say the card was initialized ok but this isn't the case, and you will see 0 h/s for the card(s) and often a subsequent hard driver hang when you try to exit the miner. For most Vega rigs, it will never happen, it's more common for Polaris, but it is not impossible.

Another category is after a network outage, the next release will be more lean on the cards when starting up again.

[Hackintoshihope]

ill be waiting for that new release today. im having a random rig freeze today.

hopefully you could add more algo soon.

This isn't critical, I'm mostly curious: was it a Vega or Polaris card? And, did the issue happen at startup or later?

Just to respond to your question on my end Vega. I have somewhat random freezes where it gives a posix win threads error? Also when the computer restarts usually a bluescreen error accompanies this then the miner doesn't initialize a card on restart and i get 0H/s.

Hm, the posix win threads error seems like a crash, either voluntary or unexpected. Did you see the last outputs in the display before this happened? Did we report any clear error message?

The issue that we have addressed is purely on startup, the current version will say the card was initialized ok but this isn't the case, and you will see 0 h/s for the card(s) and often a subsequent hard driver hang when you try to exit the miner. For most Vega rigs, it will never happen, it's more common for Polaris, but it is not impossible.

Another category is after a network outage, the next release will be more lean on the cards when starting up again.

I highlighted in bold about something that does happen on 6 card vega rigs of mine upon some restarts. However I assume you are right about the posix it is probably a crash from a bad overclock etc.

[Mashy81]

Only time I have had trouble is if I restart the miner to quick after closing it.
Also if a card hangs (while finding optimal clocks) restart the rig.
The miner it self I find flawless. crashes or failed starts are operator error in my case.

[kerney666]

Only time I have had trouble is if I restart the miner to quick after closing it.
Also if a card hangs (while finding optimal clocks) restart the rig.
The miner it self I find flawless. crashes or failed starts are operator error in my case.

The release tonight or tomorrow also includes clean shutdown code when ctrl-c is pressed. It should make stopping/restarting much more stable as well. Should really have been there from the start .

[N2DCRYPT]

Hey guys,

Something I rigged up, some people here might find it useful, maybe not, just thought I'd share.  Those of you vega miners who have been around a while may remember JJ's (Jericho Jones) Hash Rate Monitor. Used to be super useful back in the day on the buggy BC drivers with maintaining consistent hashrate on Vega rigs.

I've tweaked it to work with the TRM miner. Wasn't that intuitive, as the API in TRM differs from CAST and STAK. Used a recommended php file from the sgminer repo to pull the necessary data, only thing with that is you'll need to have a phpserver on your pc, I downloaded and use wampserver64 for that, sure there are other lighter ones that would work as well. If you do use wampserver, you'll need to add the address of the wamp php.exe to the path environment variable. There are tutorials online how to do that.

In the powershell script, you'll need to add the instruction line from the TRM bat file to line 112. Make sure to have --api_listen=127.0.0.1:4028 in the instruction line, or whatever port you decide to run the api on. Will have to tweak the port in multiple places if you change it, though. One other thing, the name of the important field in the api changes depending on how often you report data. I recommend adding -l 15 to your TRM script, that's what the PHP file is defaulted to.

Other important items: change the value in line 144 to the minimum allowable total hashrate (in kH/s) before you want your rig to restart TRM. For rigs with less powerful CPUs, you might need a longer stabilization time in line 142 (in s). The script can reset the Vegas on restart. This can be useful in the case of hard crash of gpus, but if you don't want it, comment out line 672 with a #. You can also run ODTool on restart (will need to add your OD script to line 121 though). If you don't want that, comment out line 121 with a #.

The script has helped me maintain hashrate on buggy rigs, which has been a problem for me so far with TRM. My most common problem has been gpus going to 0 HR and being stuck there, sometimes after mining for a while and sometimes just because of buggy initialization. Hope someone gets some good out of it, happy to answer any Q's.

Here's the link, only three files included: the php script, the powershell script, and a bat file to run the PS script in an elevated context.

https://mega.nz/#!khl2RCIT!Hh2gBaolaqs4L0jVRZSwloPjnJwIz_48qPiLNqygPw8

Peace,
N2

[kerney666]

Hey guys,

Something I rigged up, some people here might find it useful, maybe not, just thought I'd share.  Those of you vega miners who have been around a while may remember JJ's (Jericho Jones) Hash Rate Monitor. Used to be super useful back in the day on the buggy BC drivers with maintaining consistent hashrate on Vega rigs.

I've tweaked it to work with the TRM miner. Wasn't that intuitive, as the API in TRM differs from CAST and STAK.

Wow, nice! I remember the JJ script days . I have some plans on getting a little Python hack going that acts as an adapter against the messier sgminer API and provides an xmr stak equivalent html and http/json interface. Time time time...

One other thing, the name of the important field in the api changes depending on how often you report data. I recommend adding -l 15 to your TRM script, that's what the PHP file is defaulted to.

This is such an idiotic design by cgminer/sgminer, but we had to follow it to maintain compatibility. However, there is a correct way of doing it. First, you run the config command ({"command":"config"}). In that json response, you'll find the key "Log Interval", which is what the log interval in secs the running miner is configured for. That value is then used in the keys in other json messages for e.g. hashrate, as you've noticed.

The script has helped me maintain hashrate on buggy rigs, which has been a problem for me so far with TRM. My most common problem has been gpus going to 0 HR and being stuck there, sometimes after mining for a while and sometimes just because of buggy initialization. Hope someone gets some good out of it, happy to answer any Q's.

We have a release in the pipeline right now, should be out in an hour or two. There are number of stability issues being addressed there. Hopefully it will improve things, especially at startup, but also after e.g. a network or pool outage.

Anyway, thank you for the time spent, much appreciated!

[todxx]

Team Red Miner v0.3.7 released

https://github.com/todxx/teamredminer/releases

Changes in v0.3.7

• Redesigned GPU initialization, should now be less error prone.
• Added clean shutdown to reduce driver/GPU crashes.
• Added staggered GPU start-up to reduce GPU crashes.
• Added CPU verification for CNv8 and associated --no_cpu_check option.
• Fixed crash on pool authentication error.
• Added --pool_broken_rpc work-around option for pools that violate json rpc spec.
• Added option to reorder by PCIe bus numbers.
• Added --list_devices option to show available devices.
• Added changed stats formatting to indicate which numbers are accepted/rejected/hw-error shares.
• Added uptime to stats.

Hopefully this release addresses a lot of the bugs you guys have reported!
As you can see from the change list, we've been pretty busy this week

[Mashy81]

Testing now. All seems good.
Love how easy it is to configure and start it takes no time at all

[ku4eto]

Okay, i tried 0.3.7.

There is an issue when starting the miner and the GPUs.

For some reason, one of my GPUs will NOT initiate properly (first was GPU2, now is GPU1), and it will run at only 1 thread, the other thread is seemingly crashed, since it spews 500+HWs per 30 sec. Running 0.3.6 is all OK.

[todxx]

Okay, i tried 0.3.7.

There is an issue when starting the miner and the GPUs.

For some reason, one of my GPUs will NOT initiate properly (first was GPU2, now is GPU1), and it will run at only 1 thread, the other thread is seemingly crashed, since it spews 500+HWs per 30 sec. Running 0.3.6 is all OK.

Hi ku4eto,

These stability issues seem to have no end.  It seems like every time we change something to get some rigs to be more stable, some else's start having problems.

That said, can you provide a bit more information about your rig and how the miner is behaving?
What OS are you running?
What version drivers are you using?
What GPUs are you running?
Can you post the output of the miner when it is having the issues you described?

This information would help us a lot in trying to find the cause of the problem.