Cost wise it would save me 10 dollar/year, as my power is about 0.20 dollar / kWh.
if your power costs $0.2 then you're already losing money mining coins that buying them. 
Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 118. (Read 211762 times)
December 16, 2018, 02:43:15 PM
December 16, 2018, 07:33:51 AM
For who is interested:
Running on a RX570 4GB ITX, CC 1075 MC 775 MC 1910 MV 787, getting 870 h/s reported, maybe 860 h/s at the pool, using 86.5 watt at the wall (minus mobo draw without card installed) (CNv8). (max hash is about 920 h/s or so for this card, but it uses about 112 watt (just without mem errors etc)
about 3 mem errors / hour (2.5 hour test run), non hw in the miner. Voltages are ridiculously low, especially for TRM. Determined these odd clocks and voltages using SRB to give the most hash/watt, (and no mem errors), and then tried them as well for TRM. SRB 1.7.0 gets 9.4 h/w, TRM 0.3.8 almost 10.0 h/w. Was surprised TRM did not crash on these low voltages, as at higher core clocks it needs the power.
Cost wise it would save me 10 dollar/year, as my power is about 0.20 dollar / kWh.
So TRM can be a decent competitor, when some more features will be introduced
, and the dev fee goes down just a tickle more 
Running on a RX570 4GB ITX, CC 1075 MC 775 MC 1910 MV 787, getting 870 h/s reported, maybe 860 h/s at the pool, using 86.5 watt at the wall (minus mobo draw without card installed) (CNv8). (max hash is about 920 h/s or so for this card, but it uses about 112 watt (just without mem errors etc)
about 3 mem errors / hour (2.5 hour test run), non hw in the miner. Voltages are ridiculously low, especially for TRM. Determined these odd clocks and voltages using SRB to give the most hash/watt, (and no mem errors), and then tried them as well for TRM. SRB 1.7.0 gets 9.4 h/w, TRM 0.3.8 almost 10.0 h/w. Was surprised TRM did not crash on these low voltages, as at higher core clocks it needs the power.
Cost wise it would save me 10 dollar/year, as my power is about 0.20 dollar / kWh.
So TRM can be a decent competitor, when some more features will be introduced
, and the dev fee goes down just a tickle more December 16, 2018, 05:11:58 AM
did you try reducing intensity?
I haven't figured out how to change it. I've tried + and - keys from both places of the keyboard with no change.Not sure if this affects intensity but
CN 16+14(tried few others but no change other than hash speed decreased)
December 15, 2018, 10:47:31 PM
For me it's just a single Vega 56 alone right on pcie 16x. Dual "monitor" setup(144hz freesync + 60hz tv).
Asus Prime B350 Plus / Ryzen 1600 / Win10 Pro 1809(Os Build 17763.194, should be latest) / 2x4GB 3000mhz and 16000MB virtual memory on Samsung EVO850 SSD / CN 16+14(tried few others but no change other than hash speed decreased)
Just ran teamred for the night as I wasn't using the PC; otherwise it works wonderfully except the system lag.
Asus Prime B350 Plus / Ryzen 1600 / Win10 Pro 1809(Os Build 17763.194, should be latest) / 2x4GB 3000mhz and 16000MB virtual memory on Samsung EVO850 SSD / CN 16+14(tried few others but no change other than hash speed decreased)
Just ran teamred for the night as I wasn't using the PC; otherwise it works wonderfully except the system lag.
So, I upgraded my gpu dev workstation to 18.12.2 today, hoping it'd reproduce the system lag issue. Unfortunately, everything is running just fine:
Code:
[2018-12-15 21:02:53] Stats Uptime: 0 days, 07:14:02
[2018-12-15 21:02:53] GPU 0 [60C, fan 60%] cnv8: 1.011kh/s, avg 1.010kh/s, pool 1.007kh/s a:212 r:0 hw:0
[2018-12-15 21:02:53] GPU 1 [64C, fan 17%] cnv8: 1.039kh/s, avg 1.040kh/s, pool 1.086kh/s a:229 r:0 hw:0
[2018-12-15 21:02:53] GPU 2 [54C, fan 29%] cnv8: 2.081kh/s, avg 2.081kh/s, pool 2.109kh/s a:448 r:0 hw:0
[2018-12-15 21:02:53] Total cnv8: 4.131kh/s, avg 4.132kh/s, pool 4.203kh/s a:889 r:0 hw:0
[2018-12-15 21:02:53] GPU 0 [60C, fan 60%] cnv8: 1.011kh/s, avg 1.010kh/s, pool 1.007kh/s a:212 r:0 hw:0
[2018-12-15 21:02:53] GPU 1 [64C, fan 17%] cnv8: 1.039kh/s, avg 1.040kh/s, pool 1.086kh/s a:229 r:0 hw:0
[2018-12-15 21:02:53] GPU 2 [54C, fan 29%] cnv8: 2.081kh/s, avg 2.081kh/s, pool 2.109kh/s a:448 r:0 hw:0
[2018-12-15 21:02:53] Total cnv8: 4.131kh/s, avg 4.132kh/s, pool 4.203kh/s a:889 r:0 hw:0
The box is a pretty standard Dell Win 10 Pro Ryzen 7 1700X, 16GB ram, 48GB overkill swap. It runs a Rx580 at PCIe 3.0 x8, Vega 64 LC at PCIe 3.0 x16 and a Rx570 on a riser at PCIe 2.0 x1.
So, when running the miner using standard configs (8+8,8+8,16+14) and getting the results above after 7h, I experience zero lag or sluggish feeling. No difference logged in remote vs physically. However, there's no chance in hell I can run my Vega 64 at 16+14 when it's driving monitor(s), hashrate drops significantly.
I'd love to be able to reproduce and nail this issue, I have a few ideas about things that could make TRM stick out compared to other miners. Right now we don't have a workstation or rig exhibiting the problems described, but we'll continue the search.
Just curious if any of you guys having this problem could try a compute algo as well and check if you still have the issue? For example, you can just run the provided start_phi2.bat in the 0.3.8 release.
December 15, 2018, 06:25:34 PM
For me it's just a single Vega 56 alone right on pcie 16x. Dual "monitor" setup(144hz freesync + 60hz tv).
Asus Prime B350 Plus / Ryzen 1600 / Win10 Pro 1809(Os Build 17763.194, should be latest) / 2x4GB 3000mhz and 16000MB virtual memory on Samsung EVO850 SSD / CN 16+14(tried few others but no change other than hash speed decreased)
Just ran teamred for the night as I wasn't using the PC; otherwise it works wonderfully except the system lag.
Asus Prime B350 Plus / Ryzen 1600 / Win10 Pro 1809(Os Build 17763.194, should be latest) / 2x4GB 3000mhz and 16000MB virtual memory on Samsung EVO850 SSD / CN 16+14(tried few others but no change other than hash speed decreased)
Just ran teamred for the night as I wasn't using the PC; otherwise it works wonderfully except the system lag.
did you try reducing intensity?
December 15, 2018, 06:21:58 AM
For me it's just a single Vega 56 alone right on pcie 16x. Dual "monitor" setup(144hz freesync + 60hz tv).
Asus Prime B350 Plus / Ryzen 1600 / Win10 Pro 1809(Os Build 17763.194, should be latest) / 2x4GB 3000mhz and 16000MB virtual memory on Samsung EVO850 SSD / CN 16+14(tried few others but no change other than hash speed decreased)
Just ran teamred for the night as I wasn't using the PC; otherwise it works wonderfully except the system lag.
Asus Prime B350 Plus / Ryzen 1600 / Win10 Pro 1809(Os Build 17763.194, should be latest) / 2x4GB 3000mhz and 16000MB virtual memory on Samsung EVO850 SSD / CN 16+14(tried few others but no change other than hash speed decreased)
Just ran teamred for the night as I wasn't using the PC; otherwise it works wonderfully except the system lag.
December 15, 2018, 02:24:51 AM
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-2
Download as usual.
Sapphire Pulse Vega 56 & Cryptonight V8 algo.
Probably need new CN-values.Release notes https://www.amd.com/en/support/kb/release-notes/rn-rad-win-18-12-2
Download 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.
i7-5930k, one vega56 pciex16 slot with monitor connected, two vega56 on risers, one vega64 on riser... all set to 14+14, win10x64
My system is similar except for the risers, so that's something to look into.
If you have a chance, could you try to run the miner on each card individually to see if the lag issue is caused by a particular card or set of cards?
December 14, 2018, 10:54:48 PM
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-2
Download as usual.
Sapphire Pulse Vega 56 & Cryptonight V8 algo.
Probably need new CN-values.Release notes https://www.amd.com/en/support/kb/release-notes/rn-rad-win-18-12-2
Download 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.
i7-5930k, one vega56 pciex16 slot with monitor connected, two vega56 on risers, one vega64 on riser... all set to 14+14, win10x64
December 14, 2018, 10:50:56 PM
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-2
Download as usual.
Sapphire Pulse Vega 56 & Cryptonight V8 algo.
Probably need new CN-values.Release notes https://www.amd.com/en/support/kb/release-notes/rn-rad-win-18-12-2
Download 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.
December 14, 2018, 04:35:40 PM
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-2
Download as usual.
Sapphire Pulse Vega 56 & Cryptonight V8 algo.
Probably need new CN-values.Release notes https://www.amd.com/en/support/kb/release-notes/rn-rad-win-18-12-2
Download 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.
December 14, 2018, 03:29:58 PM
Speed is the same with Automatic (my memory straps). Power consumption seems 5-10W lower. Running on Polaris cards only. Fan curve seems to disable the Zero RPM fans...
December 13, 2018, 11:26:27 AM
Did you try the different memory timing options? Did they increase your hashrate or lower your stable overclock?
Well I tried automatic functions like undervolt, oc gpu and oc memory but the increased hashrate is from the same manual settings I used before(just used wattman this time instead of overdriventool). Now I just don't need powertable regfile for it. You need to pick one from the automatic options and I just rather do undervolt + oc memory at once so manual works for me better. Also automatic oc never did over 800mhz on memory(it's max value on default settings but with manual one can adjust like before) and I rather have 900mhz at least. There are two memory timing levels but too busy to test them out now(wouldn't know if it could crash and no time for that).EDIT: Both memory timing levels give a bit better hashrate for me than default value "Automatic". First tier a bit better, very very little. Tried every other gpu miner I know there is and no OS lag(whole windows and videos) with any of them. I hope this is something that can be fixed within teamred so I can go back to it.
December 13, 2018, 11:08:09 AM
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-2
Download as usual.
Sapphire Pulse Vega 56 & Cryptonight V8 algo.
Probably need new CN-values.Release notes https://www.amd.com/en/support/kb/release-notes/rn-rad-win-18-12-2
Download as usual.
Sapphire Pulse Vega 56 & Cryptonight V8 algo.
Did you try the different memory timing options? Did they increase your hashrate or lower your stable overclock?
December 13, 2018, 10:34:38 AM
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-2
Download as usual.
Sapphire Pulse Vega 56 & Cryptonight V8 algo.
Probably need new CN-values.Release notes https://www.amd.com/en/support/kb/release-notes/rn-rad-win-18-12-2
Download as usual.
Sapphire Pulse Vega 56 & Cryptonight V8 algo.
December 11, 2018, 07:33:05 PM
Vega 64 16+14
1630 core 1190 hbm
2470 H/s
Somehow, my watercooled vegas have better hashrate than normal vega 64 even when ODN settings are the same. I have only 2 watercooled vegas so the sample size is not so big, yet if I use for example 1450/1100mhz, normal vega 64 will be around 2150 and liquid vega at around 2250. I will try in following days to flash liquid vega bios to normal vega and see what happens
1630 core 1190 hbm
2470 H/s
Somehow, my watercooled vegas have better hashrate than normal vega 64 even when ODN settings are the same. I have only 2 watercooled vegas so the sample size is not so big, yet if I use for example 1450/1100mhz, normal vega 64 will be around 2150 and liquid vega at around 2250. I will try in following days to flash liquid vega bios to normal vega and see what happens
I also tested the LC vegas. Go with max 1150. Anything above will result in too many HW and rejected, which will drop your effective hashrate below the 1150 results.
December 11, 2018, 07:21:26 PM
Vega 64 16+14
1630 core 1190 hbm
2470 H/s
Somehow, my watercooled vegas have better hashrate than normal vega 64 even when ODN settings are the same. I have only 2 watercooled vegas so the sample size is not so big, yet if I use for example 1450/1100mhz, normal vega 64 will be around 2150 and liquid vega at around 2250. I will try in following days to flash liquid vega bios to normal vega and see what happens
1630 core 1190 hbm
2470 H/s
Somehow, my watercooled vegas have better hashrate than normal vega 64 even when ODN settings are the same. I have only 2 watercooled vegas so the sample size is not so big, yet if I use for example 1450/1100mhz, normal vega 64 will be around 2150 and liquid vega at around 2250. I will try in following days to flash liquid vega bios to normal vega and see what happens
December 11, 2018, 06:58:36 PM
Thanks! Sorry, sometimes I am total idiot when it comes to PCs. Most of these commands i just copy from the forum guys who already got it working and then i try random things until it works the way i want to. But most of the time, I am really bad with software (but at least my rigs look super nice, haha!) Thanks for being nice!
December 11, 2018, 05:25:19 PM
Guys what is the command to reorder GPUs by BUS ID? Kerney, todxx, This command is not in the readme or first page of topic, only text "Added option to reorder GPU by BUS ID", can you add it to have it in readme? 
Guess we're *nix guys at heart or something, we expect everyone to run the miner with "--help" as argument and read there
. That's really the one place we keep up-to-date with all arguments and help descriptions. Should add that to the readme and first page at least!To answer your question though, it's "--bus_reorder".
December 11, 2018, 03:54:31 PM
Guys what is the command to reorder GPUs by BUS ID? Kerney, todxx, This command is not in the readme or first page of topic, only text "Added option to reorder GPU by BUS ID", can you add it to have it in readme?
December 11, 2018, 02:34:38 PM
TOO MANY REJECTS--
Your explanation makes sense and is mostly true, but I think the code needs to be refined to reduce rejects. I stopped using TeamRedMiner for anything but my Vega cards. There is solid improvement on my Vegas, maybe 30%, over XMR-Stak, but the rejects are still there. My lesser RX series cards do not show real improvement on pool-side statistics. The rig-side hash rate is higher, but after fees and rejects, pool-side is slightly less.
Smooth out the code please. I am hoping to build more Vega rigs. Your miner is good, but it needs some work.
Thanks for the good code, make it better! --scryptr
Your explanation makes sense and is mostly true, but I think the code needs to be refined to reduce rejects. I stopped using TeamRedMiner for anything but my Vega cards. There is solid improvement on my Vegas, maybe 30%, over XMR-Stak, but the rejects are still there. My lesser RX series cards do not show real improvement on pool-side statistics. The rig-side hash rate is higher, but after fees and rejects, pool-side is slightly less.
Smooth out the code please. I am hoping to build more Vega rigs. Your miner is good, but it needs some work.
Thanks for the good code, make it better! --scryptr
You need to consider the lower power usage with TeamRedMiner. Atleast it's quite big difference between for example SRBMiner/XMR-Stak and TeamRedMiner. With TeamRedMiner I'll get around 1100 W with my rig, and with the other miners I gets around 1250 W, big difference! I have a mix of RX 560/570/580 and Vegas in that rig. I also are running a rig with some RX 550/560 and that rig saves only about 10 W.
EDIT: But I can agree with you about rejected shares. When looking right now at my bigger rig, it says 9691 accepted and 253 rejected. Seems very high.
Hm, it is interesting though. I mean, I believe we _always_ submit stale shares rather than discard them, even though we know we just received a new job. This means you'll see them as rejected in TRM but not see them at all in e.g. stak. At the end of the day, the only interesting number is the accepted poolside hashrate, all other numbers can be dependent on different miner implementations and strategies.
For the "true" rejects, they should only be dependent on (1) pool policy for stale shares, (2) miner thread job runtime, (3) any additional overhead/latency in the network/miner.
(1) above has nothing to do with the miner, (2) should be very aligned between TRM and stak. (3) is a little interesting though. We refuse to steal any open source code, so we wrote our CN CPU verification from scratch in plain C code. It is def a lot slower than the AES-NI code in xmr-stak and others and could maybe be bumping the reject rate a little, but it shouldn't really be much.
So SCRYPTR, just curious if you see any difference if you disable the cpu verification with "--no_cpu_check"? I don't know if some pools have a window after sending out a new job where old shares are still accepted, but after 100ms they are rejected. If that's the case our slower cpu verification could very much be a factor.
THANK YOU FOR THE RESPONSE--
I have not tried the "--no_cpu_check". I never submit stales, with "--no_submit_stale". That could be a possible option, but it is not yet implemented in your code. And, your theory about slow code sounds reasonable.
Right now, my 4xVega box reports about 7,500 accepts with about 225 rejects, a rig-side hash rate of 8.1kH/s, a pool-side hash rate of 7.75kH/s. The 225/7500 yields a 3% reject rate, and the (8.1-7.75)/8.1 yields about a 4.3% hash loss due to the various reasons you cited. But the Vegas are outperforming my other RX series cards by far; the lesser cards had more rejects. And, the Vegas outperform themselves by at least 1/3 compared to their hash rate when mining with XMR-Stak.
So, I wait. The latest XMR-Stak, 2.7.0, did wonders for my other cards. My Vegas are doing better on TRM than before on XMR-Stak.
Thanks again! --scryptr
Jump to: