 Show Posts
|
|
Pages: [1] 2 »
|
|
Hi guys!
After 2 weeks of experimenting and modding I finally succeeded.
I have an Rx 5700 xt Red Devil with Micron memory. I had issues with consumption and of course temperatures were very high.
There was no way to do something with her bios even if I tried too many times and different setups.
So I decided to work with another one vbios from Sapphire brand applied to my Red Devil.
Here's the results.
53.84 mh/s, 78-79w, 55C - 74C gpu - mem, 40%fan, 1355mhz gpu, 875mhz mem...
Of course it can go higher if someone wants to but I keep it easy for now with low wattage consumption and low frequency stress for my Red Devil.
|
|
|
|
You need good timing straps to reach 1k+ on CN-V7. 8gb cards can do 1k+ on CN-Heavy easily.
I have also got 1260 H/s on an RX 570 8gb card (1466/2300 clocks). They do 1140 H/s @ 1250/2240 clocks and 900mV core (105w from wall). So it's pretty much possible.
Also, All 4gb cards that I have Elpida, Hynix do 1k+ on CN-V7.
I want to see that... Can't get more that 700h/s with Elpida 570 pulse 4gb (with stak and SRB) RX570 8gb 1260 H/s on CN-Heavy (i posted this some pages back) 6 x RX580 4gb cards + 1 RX570 8gb (GPU4).  Hi heavyarms! Can you share your timing straps please? Thank you in advance |
|
|
|
test a lot of configs
18.5.1 drivers is best. stable high rate
Anyone have noticed the inability of 18.5.1 driver to recognize RX 570's??? In my system it sees all my RX 570 as 580!!! So I couldn't run miner. I reverted back to 18.3.4. win update 1803. Even the 18.5.2 driver does the same. Thanks in advance. win1803 should be avoided at all cost. Gentlemen, it's not 1803 update definitely. I installed 18.5.1 on my previous win 1709 and there was the problem! So I decided to update to 1803. |
|
|
|
test a lot of configs
18.5.1 drivers is best. stable high rate
Anyone have noticed the inability of 18.5.1 driver to recognize RX 570's??? In my system it sees all my RX 570 as 580!!! So I couldn't run miner. I reverted back to 18.3.4. win update 1803. Even the 18.5.2 driver does the same. Thanks in advance. |
|
|
|
V1.6.0- Added support for Haven new algo after fork (block 89200) - Added support for Masari new algo (fast) after fork (block 204000) - Job timeout default is now 20 minutes - More logging on miner startup - Added option 'persistent_memory' in gpu_conf + 2 new algos added : 'haven' and 'fast' So after the fork you can use them like : "cryptonight_type" : "fast"
"cryptonight_type" : "haven"+ As some have issues with miner 'just waiting some time' on startup, i added more logging option so we can catch where it hangs, and i can possibly fix that + 'persistent_memory' parameter added to gpu_conf, basically what it does is tries to allocate some memory that is normally not available to the GPU. It can increase hashrate in some ocassions, by finding the right intensity and threads setup, but also it can make the gpu crash, so it's up to you to experiment  I am still looking for the cause of random miner crashes (mostly on new 'great' win 1803 update), also for the abnormality that causes higher hashrate on after X runs. Hi Doc! as I told you before, you have to take a good look at memory usage in task manager for the first run after reboot and all the next ones. There is something strange there! Behaviour is different. PS. This doesn't happening in other miners. |
|
|
|
Hi Doc!
A strange behavior!
I've noticed that a long time ago but now I've decided to tell you.
It may help you debugging the code.
I've automated startup procedure for the miner whenever windows starts.
Let's take for example one of my rigs with 6 cards.
Windows boots and after a while miner starts.
After some time of stabilization watching memory usage in task manager I see it stable at ~286 - 290 M.
If I kill the miner process and start it again giving it time to stabilize it stays at ~560 - 570 M.
That's why I was saying all the time about "memory management".
I don't know but this is the behavior.
It may help.
Greetings!
ps: in heavy algo.
well if you would follow this thread regulary you would know that this is very well known, and can be fixed by just fireing up GPU-Z  You know something Doc, you didn't understand me. I'm not talking about the known hashrate drop problem which I first introduced to the community the temporary solution with GPU-Z but about different seized memory (MB) into 2 different runs of miner which of course may related. No hard feelings! No hard feelings, we did not understand eachother. Also i don't take notes who said/wrote what and when , so i couldn't know you found this nice 'fix'. Is this behaviour you are referring to happening every time (like first run always less mem used, second run always ok) ? I see other miners have this 'problem' too on heavy. Yes, happening all the time. Miner uses about half the mem every time machine reboots and for every next run about double of that. Also what means compute errors? I've installed a new Gigabyte rx580 8gb card. I have no memory errors, no hang ups, working fine but only this new card reports 1 or 2 compute errors in stats in a day! |
|
|
|
Hi Doc!
A strange behavior!
I've noticed that a long time ago but now I've decided to tell you.
It may help you debugging the code.
I've automated startup procedure for the miner whenever windows starts.
Let's take for example one of my rigs with 6 cards.
Windows boots and after a while miner starts.
After some time of stabilization watching memory usage in task manager I see it stable at ~286 - 290 M.
If I kill the miner process and start it again giving it time to stabilize it stays at ~560 - 570 M.
That's why I was saying all the time about "memory management".
I don't know but this is the behavior.
It may help.
Greetings!
ps: in heavy algo.
well if you would follow this thread regulary you would know that this is very well known, and can be fixed by just fireing up GPU-Z You know something Doc, you didn't understand me. I'm not talking about the known hashrate drop problem which I first introduced to the community the temporary solution with GPU-Z but about different seized memory (MB) into 2 different runs of miner which of course may related. No hard feelings! |
|
|
|
|
Hi Doc!
A strange behavior!
I've noticed that a long time ago but now I've decided to tell you.
It may help you debugging the code.
I've automated startup procedure for the miner whenever windows starts.
Let's take for example one of my rigs with 6 cards.
Windows boots and after a while miner starts.
After some time of stabilization watching memory usage in task manager I see it stable at ~286 - 290 M.
If I kill the miner process and start it again giving it time to stabilize it stays at ~560 - 570 M.
That's why I was saying all the time about "memory management".
I don't know but this is the behavior.
It may help.
Greetings!
ps: in heavy algo.
|
|
|
|
Hi hesido!
do you have 13 cards running on the same machine?
are all these cards AMD brand?
All I want to know is how many cards of the same type (AMD) we can run under Win10.
Thanks in advance
istr
Yes, on 13 cards on a single machine, all AMD. Asus B250 miner m/b. Thanks, But do you or someone else know how many AMD cards can we run simultaneously on a single machine under win10? Can we run all 19 cards ASUS B250 Mining Expert supports? Greetings from Hellas |
|
|
|
is there a "ideal scenario" to run GPU-Z? I noticed a hashrate drop while running.
For who had success doing this: what you did? What version? Running gpu-z.exe -minimized? How can I minetize the procedure?
In my personal experience, I had same cards with same mem type and same OC settings, yet some did 950 h/s, some did, 980, some did 1020. When I shut down the miner and I restarted, this time a card would randomly work at 950, although it could be 1030 the previous run. By chance, I read here that someone had their hash rate increase when GPU-Z was turned on and he looped through each card. In my case, no such thing is necessary. I just fire it up, and it "fixes" hash rates in 1-2 minutes. It fixes the hash rate fall from switching pools in a few minutes in the same manner. I have 13 cards running, win 10, adrenaline drivers. Maybe it works for setups with many cards, maybe not. Maybe it works with adrenaline drivers, maybe not I can't be sure, but if you are suffering from random hashrates from the same card, this may work for you. Hi hesido! do you have 13 cards running on the same machine? are all these cards AMD brand? All I want to know is how many cards of the same type (AMD) we can run under Win10. Thanks in advance istr |
|
|
|
|
Hi Doc!
Good news!
Did you make something to the code???
I have a small increase in hashrate with the last version!
You may find it at least!
Keep up!
Greetings
|
|
|
|
|
Hi Doc!
any news about the known hashrate drop in heavy?
|
|
|
|
|
Thank you a lot lebuawu2,
your strap helped me!
it is better than the PBE's one.
Have you any other modified straps, maybe for UberMix 3.1 or Elpida, Hynix?
|
|
|
|
Cryptonighy-Heavy. 1200+ H/s on RX 570 8gb (Micron). Also, serving as primary display card so couldn't push them too far. Makes my Vega 56 look bad hashing at 1400 H/s  have left them hashing at 1130 H/s 1250/2200 clocks @ 906mV. which intensity you used? did you modded your bios with polaris editor one click timing? 56. Dual threads. Not the PBE strap. PBE timings are pretty good too. They do 1080 on similar settings. Haven't tested those at 1400+ clocks nice strap, can you please share your strap? for me 1250/2200 only got 1110 and with intensity 54. intensity 56 will lower my hashrate. did you try intensity 54? if your GPU can reach 62 intensity I bet it will reach 1200 h/s with 1250/2200. Hi lebuawu2, could you please share your Micron straps? I think they are better than mine. Thanks! |
|
|
|
Cryptonighy-Heavy. 1200+ H/s on RX 570 8gb (Micron). Also, serving as primary display card so couldn't push them too far. Makes my Vega 56 look bad hashing at 1400 H/s  have left them hashing at 1130 H/s 1250/2200 clocks @ 906mV. which intensity you used? did you modded your bios with polaris editor one click timing? 56. Dual threads. Not the PBE strap. PBE timings are pretty good too. They do 1080 on similar settings. Haven't tested those at 1400+ clocks Hi heavyarms! please, can you share your Micron straps you are getting this amazing speed? Thank you in advance! |
|
|
|
Hello guys,
In heavy algorithm I use 1300 mhz core and depending on memory type (Samsung, Micron...) some cards work on 2000 mhz and some others on 2150 - 2200.
What do you suggest for voltages on both core and memory?
Right now I use core 975 mv and mem 1000 mv. Is it good or I can lower it a little more to save energy?
Cards are RX 580 8gb.
Thanks in advance!
Istr, what is your hashrate per rx580 card? I do 1160mhz coreclock + 2220mhz on my microns, 880mV vcore and vmem., I get 1010 mh/s, using polaris 1 click timings I do 1160mhz coreclock + 2100mhz on one of my hynix, 900 mV vcore and vmem, with a custom timing strap, and get 1005mh/s, I do 1160mhz coreclock + 2190mhz on my other hynix, 900 mV vcore and vmem, with polaris 1 click timings, and get 950mh/s I think, you cannot set vcore to be less than vmem, so your cores are effectively running at 1000mV. I must say though, my hynix that does 1005 is not very stable, it does crash every once in a while, and it is the one with hashing errors, although no memory errors are reported. Some of my microns report mem errors but they never procuded bad hashes. That hynix one was bad from the beginning, but the custom ram timings saved a lot of performance and reduced the errors to acceptable levels. I can't flash the other hynix as it's index is too high and I have to shutdown mining and disable some gpu's to reach it with ATI flash. [/quote] Hi hesido, thank you for your replay! As I said in an earlier post I get from 1070 to 1148 h/s. I have 2 rigs. The first one with 6 RX. 2 480's and 4 580's 8gb all. (All 8gb in one rig for testing reasons). 2 Pulse's with Micron running 1300 mhz core and 2150 and 2200 mhz mem. I get on them 1070 and 1094 h/s stable. 1 XFX RX 480 8gb Samsung running 1220 mhz and 2000 mhz mem. I get on this 1106 h/s stable. 1 PowerColor RX 580 Micron running 1300 mhz core and 2170 mhz mem. I get on this 1080 h/s stable. 1 RX 480 Nitro+ Samsung running 1280 core and 2000 mem giving me 1134 h/s also stable. and 1 Pulse RX 580 Samsung running 1300 core and 2000 mem giving me 1148 h/s also very stable for days and days. Second rig and last, pitty! 4 Sapphire RX 570 4gb Nitro+ Hynix mem type running 1280 core and 2000 mem giving me 755 to 765 h/s also stable all the time. and 2 Sapphire RX 580 4gb Nitro+ Elpida mem type running 1280 core and 1900 mem giving me 776 to 780 h/s stable all the time. This second rig with the 4gb memory NEVER had the hashrate drop problem. They reach maximum speed from the beginning. I wish I had more!!! :-))) To be honest I'm waiting for one Sapphire RX 580 8gb Special Edition. We'll see how it'll go. All these on heavy algo. Greetings from Hellas! |
|
|
|
Doc, I can confirm, that my RX580 cards with 8GB get a Hashrate drop after Pool switch / dev Pool. After start and close GPU-Z while miner is running, the max. Hashrate come back again.
Would be nice to implement the „Magic Function“ to the Miner :-)
Greetings from Germany
Oliver
Hashrate shouldn't drop after devfee mining, because when switching do devfee pool, user pool is not disconnected, it's running in the background, and when devfee finishes it just takes work from user pool and continues hashing. User pool can lower difficulty because user is not sending shares for 1 minute, but i don't believe that should be a reason for the hashrate to drop. Also it would be nice to know what is gpuz doing Tricky :-) I also think, that the lower difficulty after devfee is NOT the reason because i set a static Diff. Algo: Heavy, last Version of GPU-Z I can confirm what Doktor says, that there is NO drop in hashrate after devfee pool disconnects, some versions now. That was the occasion some versions before when Doc was disconnecting user pool being connected to his. But we have hashrate drop whenever we switch pools. That's a different story. As you understand the problem arises whenever GPUs loose "load" and have to start over again. For me, when my GPUs reach maximum speed with whatever way (GPU-Z,...), they stay ROCK STABLE for days until I'll stop SRBminer just to reboot my machine. I don't switch pools now for long time. I'm rock stable in one :-))) "Also it would be nice to know what is gpuz doing " Doc, maybe if you ask the dev team? |
|
|
|
|
Hello guys,
In heavy algorithm I use 1300 mhz core and depending on memory type (Samsung, Micron...) some cards work on 2000 mhz and some others on 2150 - 2200.
What do you suggest for voltages on both core and memory?
Right now I use core 975 mv and mem 1000 mv. Is it good or I can lower it a little more to save energy?
Cards are RX 580 8gb.
Thanks in advance!
|
|
|
|
|
I've just tested all new Cryptonight algorithms Alloy, Arto and IPBC in accordance to hashrate drop.
No, there is NO PROBLEM there for all type of cards (4gb, 8gb).
These algorithms work rock stable from the beginning of SRB. No need to fire up GPU-Z.
|
|
|
|
|
Another problem I noticed is that there is no "total" hashrate line when disabling a gpu.
This reminded me previous post with its screenshot.
|
|
|
|
|
