Hi guys!

Really sorry to hear about the issues of getting this stable . We have done tons of testing, incl larger Vega rigs, and haven’t had the same issues. I have a theory on what the issue is, and it’s again more related to host-side aspects such as weaker cpu and how the mobo is constructed. What supports it is that no low clocks in the world seem to help, indicating that this isn’t about the gpus. We have a test version running in a farm now that has had the same issues on 8 x Vega56 rigs. I’m waiting to hear back reg the overnight stability. I just woke up and had no message about a crash waiting for me, but need to confirm it.

The dev fee switching is a total red herring. There is no dev fee switching in this miner, we do it continuously so it’s absolutely fair for the miner. Every enqueued job is the same from the gpu’s perspective, and there are no interruptions or reinitializations once you have started the miner. That said, something is for sure going on, but it isn’t dev fee switching.

@vmozara @LordPower If you’re available right now and also would like to test the new version, please send me a pm or find me on discord (can send you an invite to some server over pm if necessary). We’re super grateful for the time you’ve invested so far!

that would be amazing! thank you so much

I am very happy to participate in the new version of the test, I have 8x vega56 rigs, win10 LTSB, celeron CPU, cer in the 0.34 and 0.35 versions, the rig always crashes between 40 minutes and 2 hours, the same parameters use xmr-stak or The SRB is operating normally.
In the test version, the same parameters, 1407/950, did not crash for 11 hours of normal operation, and had the hashrate (16.1K) closest to v7 and the power consumption closest to v7.

No way!!
Is that so??
Who'dve thunk!


On a more serious note, no.
I have a 1500W gold rated PSU and sitting at 1275 at the wall currently so I'm happy where I am. But by all means, crank it up, dude!

Ok, after getting crazy yesterday, where my rigs were getting stuck no matter the clocks or voltages, i tried one thing that i didn't pay attention to. I changed default config 16+14 to 15+14. Now, all 3 problematic rigs started without issues and work for few hours already. Maybe there is some issue with intensity and slow CPU.

If you have vega rigs and are having troubles even at super safe clocks, simply try to change the intensity from 16+14 to 15+14, hash drop is minimal, so far it works for me!

with this it starts but still getting random reboots

Can you explain this better? What connections are made?

My stable rig that is working 24 hours without interruptions is printing 14.7 KH/s and support xmr says 24 hour average is 14.5, another is 14.2 and pool is 13.8. Home PC is 2250H/s and pool is 2150. Unfortunately other rigs were unstable so can't give any results.

Sorry to hear it. I know we are as clean as can be, so not sure what you are 'insinuating' really? We also tried hard to let non-affiliated forum members verify poolside hashrate before releasing just to not have your kind of posts in the thread. The hashrate displayed is legit.

There is a single outbound connection for the dev fee to a single IP. It will be active at all times and should not change. There is no dev fee switching. For gratified.approvalbureau.com I can't even make a successful public DNS lookup using Google (8.8.8.8, 8.8.4.4) for it so I'm guessing you have a typo somewhere. The other URL resolves to a 207.148.248.143 which is not affiliated with our miner in any way.

Using standard Win10 tools, open the Resource Monitor, go to the Network tab, sort the TCP Connections on Image name, find teamredminer.exe in the sorted list, verify you have two outbound tcp/ip connections, one to your pool and another for our dev fee. On linux, use netstat -nltp | egrep teamred while running the miner. If you're running our binary downloaded from github, there will be nothing else there to find unless that account has been hacked, which I doubt.

Yep, we'll be getting a new version with 550 support out soon, current last version doesn't recognize the cards. We delayed it do finish some stability tests for large Vega rigs to include those fixes as well. I got a report from an early tester that it still failed for his 550s under 18.5.1 though, zzz...

MoneroCrusher, if you have a mins, can you run "clinfo" from a command prompt and find this section for one of your 550s? I'd like to verify you're seeing "gfx804" as the device name.


  ...
  Platform ID:                                   00007FFF3BE5FFD0
  Name:                                          gfx804
  Vendor:                                        Advanced Micro Devices, Inc.
  Device OpenCL C version:                       OpenCL C 2.0
  Driver version:                                2580.6
  Profile:                                       FULL_PROFILE
  Version:                                       OpenCL 2.0 AMD-APP (2580.6)
  ...

Yup it's gfx804.
You have Discord or Telegram? Can I also test it on Linux?

Also: are proxies supported? Like XNP or xmrig-proxy?
I really need proxy support if I want to deploy this on larger scale.