vmozara
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 190
Merit: 59
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 23, 2018, 06:09:24 PM |
|
Is it normal that with drivers 18.5.1 I had 1850h/s and now i installed 18.11.2 (for battlefield5) and I have 1130h/s with vega 56
I didnt change shit on config
you probably had power tables before. now that you installed the driver, your power table is overwritten and vega hashes bad and consumes a lot. I am not sure how to connect good miner vega and good gaming vega into same PC. Try to apply power table and see if your vega now hashes correct, and if the game plays alright (nowthe game will probably have reduced performance)
|
|
|
|
arierep60
Newbie
Offline
Activity: 50
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 23, 2018, 11:53:27 PM |
|
Guys please fix this: If my rig have more than 10 gpu I don't get the gpu information like I had in version 0.3.1 ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Here is a Rig with 9 GPU, everything looks fine https://i.imgur.com/jXLtzbt.pngAnd here is a Rig with 13 GPU https://i.imgur.com/HnDtGrC.pngI get no GPU info and 3 gpus appear black squares. Could you fix this please? Thank you Hi! Hmm, I'm guessing you have some externally provided HiveOS integration for tdxminer? Since we've changed the output, maybe some log/output parsing is broken now? Do you remember how you set things up way back when for 0.3.1? still have this problem not showing all gpus... any update on this? thanks
|
|
|
|
kerney666
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 658
Merit: 86
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 24, 2018, 05:27:56 AM |
|
Anyone have a tip about get optimal hashrates on RX 550 4GB and 560 4GB? I'm getting a little bit more than 400 H/s with both 550/560s, in best case scenario. Running RX 560 at 1200 MHz Core, 1980 MHz Mem. 550 at 1200 MHz Core, 2000 MHz Memory.
TeamRedMiner prefer 2+2 on the 550's and 4+2 on the 560's I think. But I manually set them to 3+3 to 550 and 4+4 to 560... Any help?
In the upcoming version we have made a better optimization run for 550/560s. This is one reason for it being delayed, we wanted to wrap that up properly. Todxx knows more, but afaik the results have been very good in many cases. So, stay tuned...
|
|
|
|
kerney666
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 658
Merit: 86
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 24, 2018, 05:34:08 AM |
|
Guys please fix this: If my rig have more than 10 gpu I don't get the gpu information like I had in version 0.3.1 ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Here is a Rig with 9 GPU, everything looks fine ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FjXLtzbt.png&t=665&c=WzG4rbe1ZLbyjA) And here is a Rig with 13 GPU ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FHnDtGrC.png&t=665&c=eOXjLbDRWn2Ryw) I get no GPU info and 3 gpus appear black squares. Could you fix this please? Thank you Hi! Hmm, I'm guessing you have some externally provided HiveOS integration for tdxminer? Since we've changed the output, maybe some log/output parsing is broken now? Do you remember how you set things up way back when for 0.3.1? still have this problem not showing all gpus... any update on this? thanks I'm no HiveOS expert, but I'm guessing this integration is based on parsing the output from the miner rather than using the sgminer-compatible API that we provide. That output format has changed between versions, and I believe one thing is that the ninth gpu is still printed as "GPU 9" but you now see "GPU10" rather than "GPU 10" to keep things aligned vertically. Hence, I'm guessing there is some script parsing output that now is broken for GPU10 and forth. However, unless you can point me to the specific implementation you're using, there's not much I can do. I need to see the shell/Python/Perl/awk/sed/whatever script running on your box that is parsing the output. I'm guessing it could be a trivial patch of some regular expression or awk statement. When we have the time we might make sure there's a proper HiveOS custom miner integration ourselves, this time using the API rather than parsing miner output.
|
|
|
|
kerney666
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 658
Merit: 86
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 24, 2018, 05:40:46 AM |
|
Is it normal that with drivers 18.5.1 I had 1850h/s and now i installed 18.11.2 (for battlefield5) and I have 1130h/s with vega 56
I didnt change shit on config
Well, I'm quite sure we didn't change shit in the miner code either when you switched driver version ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) . This is the painful world of trying to develop against AMD's drivers. CN is perhaps the most sensitive algo of all when it comes to mem controller tweaks in the driver, and man do they hack that shit between driver versions sometimes. Unfortunately, AMD's incentives are rather to maximize the frame rate in the latest and greatest games than making sure CN miners are happy. So, there's not that much we can do unfortunately ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) .
|
|
|
|
pbfarmer
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 340
Merit: 29
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 24, 2018, 06:24:03 AM |
|
Is it normal that with drivers 18.5.1 I had 1850h/s and now i installed 18.11.2 (for battlefield5) and I have 1130h/s with vega 56
I didnt change shit on config
First, check if the Compute mode is on. Second, from what i have heard, Vegas have issues with drivers past 18.6.1. So you may have to downgrade the drivers. The 18.6.1 issue was just on xmr-stak/variants, or any other miner using the old wolf codebase which generated opencl kernel binaries at runtime. I have had no issues w/ any driver version through 18.10.x on other miners including this one - though I can't vouch specifically for 18.11 yet.
|
|
|
|
arierep60
Newbie
Offline
Activity: 50
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 24, 2018, 08:50:40 AM |
|
Guys please fix this: If my rig have more than 10 gpu I don't get the gpu information like I had in version 0.3.1 ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Here is a Rig with 9 GPU, everything looks fine https://i.imgur.com/jXLtzbt.pngAnd here is a Rig with 13 GPU https://i.imgur.com/HnDtGrC.pngI get no GPU info and 3 gpus appear black squares. Could you fix this please? Thank you Hi! Hmm, I'm guessing you have some externally provided HiveOS integration for tdxminer? Since we've changed the output, maybe some log/output parsing is broken now? Do you remember how you set things up way back when for 0.3.1? still have this problem not showing all gpus... any update on this? thanks I'm no HiveOS expert, but I'm guessing this integration is based on parsing the output from the miner rather than using the sgminer-compatible API that we provide. That output format has changed between versions, and I believe one thing is that the ninth gpu is still printed as "GPU 9" but you now see "GPU10" rather than "GPU 10" to keep things aligned vertically. Hence, I'm guessing there is some script parsing output that now is broken for GPU10 and forth. However, unless you can point me to the specific implementation you're using, there's not much I can do. I need to see the shell/Python/Perl/awk/sed/whatever script running on your box that is parsing the output. I'm guessing it could be a trivial patch of some regular expression or awk statement. When we have the time we might make sure there's a proper HiveOS custom miner integration ourselves, this time using the API rather than parsing miner output. sent you a PM mate ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
|
twotwosix
Newbie
Offline
Activity: 118
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 24, 2018, 05:16:59 PM Last edit: November 24, 2018, 06:31:31 PM by twotwosix |
|
What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"
|
|
|
|
kerney666
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 658
Merit: 86
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 24, 2018, 08:00:07 PM |
|
What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"
It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it.
|
|
|
|
twotwosix
Newbie
Offline
Activity: 118
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 24, 2018, 10:09:31 PM |
|
What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"
It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it. im using 0.3.6 version, i cant run 0.3.7 with same config
|
|
|
|
iRonNuke
Jr. Member
Offline
Activity: 98
Merit: 6
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 24, 2018, 10:20:24 PM |
|
Anyone have a tip about get optimal hashrates on RX 550 4GB and 560 4GB? I'm getting a little bit more than 400 H/s with both 550/560s, in best case scenario. Running RX 560 at 1200 MHz Core, 1980 MHz Mem. 550 at 1200 MHz Core, 2000 MHz Memory.
TeamRedMiner prefer 2+2 on the 550's and 4+2 on the 560's I think. But I manually set them to 3+3 to 550 and 4+4 to 560... Any help?
In the upcoming version we have made a better optimization run for 550/560s. This is one reason for it being delayed, we wanted to wrap that up properly. Todxx knows more, but afaik the results have been very good in many cases. So, stay tuned... Very nice! I'm really seeing forward to this!
|
|
|
|
ku4eto
Jr. Member
Offline
Activity: 194
Merit: 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 25, 2018, 07:06:13 AM |
|
What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"
It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it. im using 0.3.6 version, i cant run 0.3.7 with same config Lower the CN Algo.... I used 8-7 before, but for 0.3.7 i need 7-7 (4GB cards).
|
|
|
|
tvukoman
Jr. Member
Offline
Activity: 69
Merit: 5
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 25, 2018, 09:58:37 AM Last edit: November 25, 2018, 01:09:34 PM by tvukoman |
|
Just testing older 0.36 vs newer 0.37 version for 48 hours.
Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1
Same H/s.
EDIT: lol, and again, go to 0 H/s after 2 days of running :-)
|
|
|
|
issie81
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 25, 2018, 01:12:38 PM |
|
Just testing older 0.36 vs newer 0.37 version for 48 hours.
Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1
Same H/s.
EDIT: lol, and again, go to 0 H/s after 2 days of running :-)
restarting miner fixes it usually, but needs to be tweaked by team
|
|
|
|
twotwosix
Newbie
Offline
Activity: 118
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 25, 2018, 05:11:32 PM |
|
What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"
It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it. im using 0.3.6 version, i cant run 0.3.7 with same config Lower the CN Algo.... I used 8-7 before, but for 0.3.7 i need 7-7 (4GB cards). Using 15+15 in my rx580 8gb in 0.3.6 , in 0.3.7 crashes when starting with 7+7, 8+8, 14+14 ... 0.3.7 fail
|
|
|
|
kerney666
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 658
Merit: 86
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 25, 2018, 06:26:59 PM |
|
What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"
It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it. im using 0.3.6 version, i cant run 0.3.7 with same config Lower the CN Algo.... I used 8-7 before, but for 0.3.7 i need 7-7 (4GB cards). Using 15+15 in my rx580 8gb in 0.3.6 , in 0.3.7 crashes when starting with 7+7, 8+8, 14+14 ... 0.3.7 fail Can you describe the crash that you’re referring to? Is it on startup or after working for a little while? Does the card initialize at all? I think you’re hitting an initialization corner case that should be solved in upcoming 0.3.8, but would love to get more info.
|
|
|
|
kerney666
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 658
Merit: 86
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 25, 2018, 06:33:51 PM |
|
Just testing older 0.36 vs newer 0.37 version for 48 hours.
Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1
Same H/s.
EDIT: lol, and again, go to 0 H/s after 2 days of running :-)
restarting miner fixes it usually, but needs to be tweaked by team The miner has a quite aggressive style. When you lose a gpu after a few hours or even days there’s no bug per se in the miner, it’s the opencl api and/or driver that stops responding. The only solution (except you lowering clocks) is a redesign of the kernels, although it’s probable this is also more about your psus rather than the gpu clocks. We have the next-level design ready though, we’ll attack it in the near future.
|
|
|
|
alucard20724
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 25, 2018, 07:47:24 PM |
|
Just testing older 0.36 vs newer 0.37 version for 48 hours.
Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1
Same H/s.
EDIT: lol, and again, go to 0 H/s after 2 days of running :-)
restarting miner fixes it usually, but needs to be tweaked by team The miner has a quite aggressive style. When you lose a gpu after a few hours or even days there’s no bug per se in the miner, it’s the opencl api and/or driver that stops responding. The only solution (except you lowering clocks) is a redesign of the kernels, although it’s probable this is also more about your psus rather than the gpu clocks. We have the next-level design ready though, we’ll attack it in the near future. i think you should attack it now. I see the exact same problem with going to 0 h/s after a day. It happens on 10 different machines with 470/480/570/580/Vega56/Vega64. The problem that causes this for me is that when cpu mining, teamredminer does not initialize the gpu and so my hashrate drops to zero. This only happens with TeamRed. SRBminer, and CastXMR does not exhibit this problem.
|
|
|
|
kerney666
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 658
Merit: 86
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 25, 2018, 08:20:16 PM |
|
Just testing older 0.36 vs newer 0.37 version for 48 hours.
Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1
Same H/s.
EDIT: lol, and again, go to 0 H/s after 2 days of running :-)
restarting miner fixes it usually, but needs to be tweaked by team The miner has a quite aggressive style. When you lose a gpu after a few hours or even days there’s no bug per se in the miner, it’s the opencl api and/or driver that stops responding. The only solution (except you lowering clocks) is a redesign of the kernels, although it’s probable this is also more about your psus rather than the gpu clocks. We have the next-level design ready though, we’ll attack it in the near future. i think you should attack it now. I see the exact same problem with going to 0 h/s after a day. It happens on 10 different machines with 470/480/570/580/Vega56/Vega64. The problem that causes this for me is that when cpu mining, teamredminer does not initialize the gpu and so my hashrate drops to zero. This only happens with TeamRed. SRBminer, and CastXMR does not exhibit this problem. I know you have this startup problem, which is unrelated to the 0 h/s gpu hang after mining successfully for a while. It has nothing to do with the redesign of the kernels. Your issue is about cpu starvation when our miner starts up. Comparisons to srb and cast are irrelevant since we use a different initialization process. Have you tried starting the miner with a real-time process priority? Theoretically windows should preempt your cpu miner threads much more aggressively in favor of the gpu miner. When the gpu miner is running the effect on the cpu mining hashrate should be tiny.
|
|
|
|
alucard20724
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 25, 2018, 08:47:25 PM |
|
Just testing older 0.36 vs newer 0.37 version for 48 hours.
Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1
Same H/s.
EDIT: lol, and again, go to 0 H/s after 2 days of running :-)
restarting miner fixes it usually, but needs to be tweaked by team The miner has a quite aggressive style. When you lose a gpu after a few hours or even days there’s no bug per se in the miner, it’s the opencl api and/or driver that stops responding. The only solution (except you lowering clocks) is a redesign of the kernels, although it’s probable this is also more about your psus rather than the gpu clocks. We have the next-level design ready though, we’ll attack it in the near future. i think you should attack it now. I see the exact same problem with going to 0 h/s after a day. It happens on 10 different machines with 470/480/570/580/Vega56/Vega64. The problem that causes this for me is that when cpu mining, teamredminer does not initialize the gpu and so my hashrate drops to zero. This only happens with TeamRed. SRBminer, and CastXMR does not exhibit this problem. I know you have this startup problem, which is unrelated to the 0 h/s gpu hang after mining successfully for a while. It has nothing to do with the redesign of the kernels. Your issue is about cpu starvation when our miner starts up. Comparisons to srb and cast are irrelevant since we use a different initialization process. Have you tried starting the miner with a real-time process priority? Theoretically windows should preempt your cpu miner threads much more aggressively in favor of the gpu miner. When the gpu miner is running the effect on the cpu mining hashrate should be tiny. considering that this only happens with your miner, and not with any of the other 20 miners that i use, this isn't a good case for changing my system when all other software works. my systems are set up for multi-algo, multi-software mining.
|
|
|
|
|