New AMD gpu drivers are out and with so many new things I just gotta use them. So far mining speed on teamred seems to be a bit better and now one can undervolt well enough without registery powertables.. Not sure if the combination of new drivers + teamred or just teamred but whole system seems to be laggy while mining. It wasn't before  Probably need new CN-values. Release notes https://www.amd.com/en/support/kb/release-notes/rn-rad-win-18-12-2Download as usual. Sapphire Pulse Vega 56 & Cryptonight V8 algo. i can verify the lagginess with teamread and 18.12.2. drivers with my vega56/64. hashrate is higher without having to mess with powertables, but there's a substantial lag on the system now. Can you elaborate a bit more on your setup? Are you running the cards with risers? I just ran my Vega 64 LC on 18.12.2 and did not have any problems. |
|
|
|
any plans to include lyra2rev3?
Yep, we've looked at it and we're hoping to have it ready by the time of the fork. |
|
|
|
So, my internet died for some reason for 8 hours. After it came back, and few hours of mining, i see this: http://i67.tinypic.com/25zs5tj.pngThe Miner reported seems OK, the AVG seems OK, considering 8H of 0H/s. But the pool reported does not seem ok. Why is that? The "pool" hashrate displayed is an average just like the "avg" hashrate displayed is. Both are averaged over the time the miner has been running, so they should track each other, as they seems to be doing. |
|
|
|
Then there is no point in Watchdog. Without it, at least, the miner continues to work.
Most users of the watchdog script have it setup to reboot their machine and have the miner setup to auto-start after reboot. As previous posts have mentioned, you may need to perform additional steps in your watchdog script to make sure the system will reboot without getting stuck. |
|
|
|
Again the miner could not restart. Uptime: 1 days, 16:43:37
[2018-12-05 02:14:42] Stats Uptime: 1 days, 16:43:37
[2018-12-05 02:14:42] GPU 0 [51C, fan 50%] cnv8: 997.9 h/s, avg 986.7 h/s, pool 1.036kh/s a:584 r:0 hw:0
[2018-12-05 02:14:42] GPU 1 [62C, fan 56%] cnv8: 1.021kh/s, avg 1.021kh/s, pool 764.3 h/s a:432 r:0 hw:142
[2018-12-05 02:14:42] GPU 2 [63C, fan 99%] cnv8: 966.2 h/s, avg 966.2 h/s, pool 927.4 h/s a:522 r:0 hw:0
[2018-12-05 02:14:42] GPU 3 [ 0C, fan 0%] cnv8: 912.8 h/s, avg 912.5 h/s, pool 902.3 h/s a:508 r:0 hw:0
[2018-12-05 02:14:42] GPU 4 [62C, fan 66%] cnv8: 985.1 h/s, avg 991.5 h/s, pool 935.2 h/s a:526 r:0 hw:2
[2018-12-05 02:14:42] GPU 5 [64C, fan 99%] cnv8: 1.019kh/s, avg 1.018kh/s, pool 1.003kh/s a:566 r:0 hw:0
[2018-12-05 02:14:42] GPU 6 [64C, fan 67%] cnv8: 1.019kh/s, avg 1.019kh/s, pool 1.021kh/s a:578 r:0 hw:0
[2018-12-05 02:14:42] GPU 7 [66C, fan 70%] cnv8: 1.019kh/s, avg 1.020kh/s, pool 1.022kh/s a:576 r:0 hw:0
[2018-12-05 02:14:42] GPU 8 [64C, fan 67%] cnv8: 1.013kh/s, avg 1.014kh/s, pool 1.049kh/s a:594 r:0 hw:0
[2018-12-05 02:14:42] Total cnv8: 8.953kh/s, avg 8.947kh/s, pool 8.660kh/s a:4886 r:0 hw:144
[2018-12-05 02:14:53] GPU 8: detected DEAD (10:00.0), will execute restart script watchdog.bat
[2018-12-05 02:14:53] Watchdog triggering miner shutdown after restart script execution.
[2018-12-05 02:14:53] Shutting down...
Watchdog restarting miner in 30 secs.
Bpeмя oжидaния 29[2018-12-05 02:14:54] GPU 1 CN thread 0 exiting.
[2018-12-05 02:14:54] GPU 4 CN thread 0 exiting.
[2018-12-05 02:14:54] GPU 5 CN thread 0 exiting.
[2018-12-05 02:14:54] GPU 2 CN thread 0 exiting.
[2018-12-05 02:14:54] GPU 4 CN thread 1 exiting.
[2018-12-05 02:14:54] GPU 3 CN thread 0 exiting.
[2018-12-05 02:14:54] GPU 6 CN thread 1 exiting.
[2018-12-05 02:14:54] GPU 7 CN thread 0 exiting.
[2018-12-05 02:14:54] GPU 0 CN thread 0 exiting.
[2018-12-05 02:14:54] GPU 1 CN thread 1 exiting.
[2018-12-05 02:14:54] GPU 5 CN thread 1 exiting.
[2018-12-05 02:14:54] GPU 2 CN thread 1 exiting.
[2018-12-05 02:14:54] GPU 3 CN thread 1 exiting.
28[2018-12-05 02:14:55] GPU 7 CN thread 1 exiting.
[2018-12-05 02:14:55] GPU 0 CN thread 1 exiting.
[2018-12-05 02:14:55] GPU 6 CN thread 0 exiting.
20[2018-12-05 02:15:04] GPU 8 thread 0 shutdown timed out.
[2018-12-05 02:15:04] GPU 8 thread 1 shutdown timed out.
19[2018-12-05 02:15:04] Unclean shutdown.
0
Team Red Miner version 0.3.8
[2018-12-05 02:15:28] Auto-detected AMD OpenCL platform 0
If your GPU has crashed you will most likely need to reboot before it will function again. Starting a miner with a GPU that is already crashed will usually lead to hangs in the driver, like the situation you're seeing. |
|
|
|
Faced a problem. The miner just stops working. It does not hang and can be closed.
Same here. Mining for 4 days and than in 7 AM just stop, when I came home about 6 PM just click to miner "h" or something, and miner start mining again  [2018-12-03 07:15:45] Pool at02.supportxmr.com share accepted. (GPU0) (a:12435 r:0) (36 ms) [2018-12-03 07:16:06] Stats Uptime: 4 days, 07:15:55 [2018-12-03 18:55:49] Pool at02.supportxmr.com received new job. (job_id: fys23FOZGVBTDnniqeH7zmyUc6fW) [2018-12-03 18:55:49] Pool at02.supportxmr.com set difficulty to 204697 SupportXMR pool show no hashing for that whole time. So, I think we have new bug on 0.3.8  You might possibly have clicked into the miner with your mouse, leaving the cursor there and blocking it from working (known issue). If you press a key or click the cursor away mining resumes. You can lock your window and prevent this from happening if you right-click on the top bar, then "properties" and uncheck "quick edit mode". Hmm, that can be possible  I checked miner before work, so it is possible. Txs Dragonmike, turning off quick edit mode ;-) Hmm, this is actually an interesting point. As is the miner can get hung if the output is blocked, like when you go into that editing mode in windows. We'll change it in the next version so that the inability to print will not have an effect on mining. |
|
|
|
Another API woe: GPU3 crashed, and was declared Dead, but the API status was still showing Alive. http://i67.tinypic.com/2s7gxi1.pngThe program seen there checks the JSON data and the Status Field specifically is like this: GpuDetails.Substring(GpuDetails.IndexOf("Status=") + 7, GpuDetails.IndexOf(",Temperature") - (GpuDetails.IndexOf("Status=") + 7));
That is indeed a bug. Sorry about that. We'll fix it in the next release. |
|
|
|
I know what you mean, but i tested the scaling and....
Elpida 1280Mhz Core GPU 3
1850 - 1047H/s
1875 - 1050-1052H/s
1900 - 1052-1054H/s
1925 - 1052-1054H/s
1950 - 1043H/s
------
Elpida 1875Mhz Mem GPU 3
1280 - 1050-1052H/s
1250 - 1028H/s
1225 - 1010H/s
1200 - 991H/s
------
Elpida 1280Mhz Core GPU 0
1900 - 1049-1050H/s
1925 - 1052H/s
1950 - 1054H/s
1975 - 1057H/s
------
Elpida 1900Mhz Mem GPU 0
1280 - 1049-1050H/s
1250 - 1028-1029H/s
1225 - 1010-1011H/s
1200 - 991-992H/s
------
Samsung 2100Mhz Mem GPU 1
1280 - 1057H/s
1250 - 1035H/s
1225 - 1014H/s
1200 - 995H/s
------
Samsung 1280Mhz Core GPU 1
2075 - 1055H/s
2100 - 1057H/s
2125 - 1059-1061H/s
2150 - 1060-1061H/s
First is Memory clock scaling, then Core clock scaling. GPU 0/3 -> 570/580 Elpida. GPU 1 -> 580 Samsung. Seems weird, for 75Mhz Memclock increase, to get only about 10Hs. Usually, it should be around 30H/s for ~75Mhz increase (at least on XMR-Stak). EDIT: For clarification, are HWs actually considered Bad shares, that failed CPU check (meaning, GPU worked on them, and before submitting, it failed) ? Our tests have shown that memory clock should have a noticeable effect. Are you testing on windows? Did you make sure that your memclock changes are taking effect by checking actual memclock speeds in say hwinfo? As for the HWs, that is the number of shares that the GPU found that failed CPU verification. This indicates that something went wrong on the GPU and it performed the share calculations incorrectly. Typically, this is due to errors from aggressive core/mem clocks and/or voltages. The miner does not submit these shares to the pool as it already knows that they are invalid. |
|
|
|
@ todxx L3+3 , WIN 10- 1709 -18.6.1  Well that's really strange. This is the first time I've seen L3+3 have lower perf than L2+3. I take it you've had bad results with L4+3 as well? That said, your results with L2+3 of 560h/s were pretty damn good already. Edit: Just to double check, but do you have compute mode enabled on all those cards? |
|
|
|
Damn... I love you guys!
My rx550 2gb are once again the stars of the show.
L4+3
1180/1950
540hs each
Glad we could help  |
|
|
|
Authors, did you plan to add old cards support such as Pitcairns (270, 370), Tahiti (280) and so on?
Hi UnclWish, Unfortunately we do not plan to support older GPU architectures. The oldest GPUs that we could currently support are Fiji and Tonga, although Tonga will take some more work, and the existing Fiji support in the miner is not well tuned. |
|
|
|
V0.3.7  V0.3.8 first test  Magic  RX550 2G , 1250/2100 HYNIX --cn_config L2+3,L2+3,L2+3,L2+3,L2+3,L2+3,L2+3,L2+3,L2+3 rx 460 unlock 2g is gpu 0 . Yeah, those little lexas are quite impressive  You should be able to run L3+3 on 2GB cards. We've also seen L4+3 work reliably for linux. On windows L4+3 occasionally works, but usually ends up crashing |
|
|
|
RX550 jump from 460 to 545 h/s
RX560 no improvement for me , i try with and w/o L
edit:
rx560 i manage to overclock high . +20 core and +25 mem , that about 1% hashrate improvement
Yes, the 550s are really the big target with the L option. It has the largest improvement on 8CU and 10CU cards. |
|
|
|
Good job again Todxx and Kerney666. Your Phi2 miner is a whopping 50% faster than FancyIX's attempt at forking Sgminer. What also needs to be said is that this miner is rock solid. At the same clocks, Sgminer will die a thousand deaths. This just runs. Beautiful.  Thanks dragonmike! It's always nice to know one's work is appreciated |
|
|
|
Will you guys support zcoin MTP algo?
Hey Mashy81, We will not be supporting MTP, at least initially. Due to the way the Zcoin team decided to setup the MTP proofs, it has created a huge mess for the stratum protocol. It will take a lot of effort for us to support the new stratum protocol, and we have other higher priority items on our todo list right now. |
|
|
|
Team Red Miner v0.3.8 releasedhttps://github.com/todxx/teamredminer/releasesChanges in v0.3.8 - Added support for fan speed and temperatures.
- Added watchdog function for gpu init stuck, dead gpu, over-temp gpu, and non-responding pool.
- Added new optional 'L' config prefix for low-end cards like lexa/baffin for a 10+% speed-up on some cards
- Added an option for writing out a log file.
- Added cycling through multi-entry dns records when connecting to pools.
- Added a pool-connect timeout.
- Added measurement and displaying of pool response times.
- Added support for 80-byte headers for Phi2 algo (for non-LUX coins).
- Slightly tuned the '+' mode for polaris, some GPUs will show slight performance increase.
- Fixed bug with API interface occasionally getting stuck.
You can now use this miner to mine phi2 coins other than LUX!
|
|
|
|
Team Red Miner v0.3.8 releasedhttps://github.com/todxx/teamredminer/releasesChanges in v0.3.8 - Added support for fan speed and temperatures.
- Added watchdog function for gpu init stuck, dead gpu, over-temp gpu, and non-responding pool.
- Added new optional 'L' config prefix for low-end cards like lexa/baffin for a 10+% speed-up on some cards
- Added an option for writing out a log file.
- Added cycling through multi-entry dns records when connecting to pools.
- Added a pool-connect timeout.
- Added measurement and displaying of pool response times.
- Added support for 80-byte headers for Phi2 algo (for non-LUX coins).
- Slightly tuned the '+' mode for polaris, some GPUs will show slight performance increase.
- Fixed bug with API interface occasionally getting stuck.
Anyone running 550s and 560s should try out the new 'L' prefix for configs, this improves hashrates significantly on 8CU and 10CU cards. Please see the tuning guide for more details on configs to try.
|
|
|
|
Guys, does pool hashrate (reported by miner) reflect HWs?
Hi visari! The pool hashrate in the miner is based only on shares that are submitted and accepted by the pool. The miner does not submit HW error shares to the pool, so they would not be counted in the pool hashrate reported by the miner. |
|
|
|
Great job on this miner!
But, does anyone know why I get 1.850kh/s on average on my miner with 1x vega56 and on two different pools (nano and supportxmr) I get an average of approx. 1.75kh/s ?
Thank you!
I have 6x vega 64 and test my rig in two different pools ,I got an average 100h less than miner reported each card.whats the problem? Can you guys provide a bit more information? How long did you run the miner? How many shares were submitted to the pool during your test? Where any shares rejected? Were there any hw errors? How does the pool report hashrate? Are you looking at a 24 hour average reported by the pool? Which of the 3 hashrates printed by the miner are you comparing to the pool hashrate? Can you post the output of the miner at the end of your test? |
|
|
|
I've checked with the latest TRM miner the following pools:
wownero.ingest.cryptoknight.cc
graft.ingest.cryptoknight.cc
xmr-eu1.nanopool.org
europe.cryptonight-hub.miningpoolhub.com
gulf.moneroocean.stream
I've get the same error with SRB miner. With Stak-XMR everything works fine. I've tried with turned off Defender and FW also.
After a Windows reinstall, with 18.5.1/18.6.1/18.11.1 in the cryptoknight and MPH pool still no luck. Is there a log or debug mode in the miner? Maybe that could help to find my problem. I mean, it seems clear that there's something very uncommon going on here given that you're the only one I know of with this problem and you're also seeing the same thing with SRB. It rather feels related to your networking setup. Personally, I would install Wireshark next and look at the network traffic to see what's going on. Really shooting from the hip here, but do you have any weird IPv6 setup? Another thing you could post here would be the output of "netstat -n -p tcp" from the command prompt when (1) xmr-stak is running and (2) right when TRM or SRB is trying to connect to the same pool. Today I've tested the mining with direct connection to the ISP with PPPoE. Everything is working fine. Now I'm searching for my network's problem. I've a not so special setup. Asus router with a TP-Link switch, everything is in IPv4. Update:
I've found the problem! After I've turned off my Asus router's AiProtection/Network Protection/Malicious Sites Blocking "feature" the mining was started without any error. Thank you guys for the help! That's great! Glad we could help |
|
|
|
|
Show Posts
