Awesome sauce, just in time!

Now if you also can do delayed pool switch, this is going to be even better! In a long list of pools, this would avoid frequent connects / disconnects / job flushes! (Defer by timer or wait until new job, or wait until accepted hash, all would do fine with me


Understandable. I was going to try to create a monitor along with a coin switcher. Guess it's technically still possible through keyboard emulation, but that does sound too "hacky".

Doktor, any plans to integrate command functions to the api? Like I want to switch pools etc, control the miner basically.

I do not understand what the big deal is either, create a pools-a.txt, pools-b.txt, and have separate .bat's targeting those pool files.

Having said that, it would be nice to have a dynamic reload of the selected pools txt.

I will go through logs sometime but devfee switch does not seem to cause trouble with the hashrate, and on my end, keeping GPU-Z turned on keeps everything at full speed. Having said that, manual switch shoots down the hashrate a lot. Just having GPU-Z open fixes that too in a few minutes.

I wonder why you cannot see the effect, maybe you are running a special debug version doing extra calls or something?


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.

I think I found a bug, I place all same algo coins in my pool txt (pool-allheavy.txt etc. etc.) and I may switch pools based on network difficulty, when SRB detects a gpu crash, it starts from the first coin in list, even though I manually switched to some coin. I think it should remember the last selected pool.


I too agree defining which config to use and pool list to use provide better abstraction. That said, dynamic reload of specified pool.txt would be nice.

Instead of ctrl+number to switch, you could also have a delayed switch, so you don't disconnect and connect several times. I made this advice a few pages ago, I hope Doktor takes either one of us into account!

I will try this next time.

However, unlike istr says, in my environment, keeping gpu-z open is actually good! Turns out it protects from hashrate drop, and unlike him, I do not go through each and every one of them to achieve the full speed, sorry to complicate things a bit, but that's the case with me!

While SRB is running, I start GPU-Z. It takes a good while for it to initialize, but you can see the hashrate going up during the process. After some hours, rate fell a bit but it was still higher than it was before, I restarted GPU-Z and it went backup, just 5 minutes ago. It may be falling during pool switches, have to check the logs, but it's great something has a testable positive effect on the rate, which may be replicated inside SRB.

I wanted to try this, and I got 1000 h/s across the board just by firing up GPU-Z.. Awesome. Wish I had known this earlier! The GPU-Z launch was unusually slow... Very strange! Whatever it is doing to the gpu's, SRB can do too, this gives me hope.

GPU-Z is 2.8.0, and I'm ignoring the update to 2.9.0 in case it works differently, lol.

To follow up my own post about pool switching, currently, pool switching causes hashrate fluctuations (at least for Cryptonight Heavy), although technically it shouldn't be much different from getting a new job from the same pool as far as performance is concerned. The fact that there are fluctuations after switching could lead you to find the problem that causes the fluctuations to begin with, maybe it will make it easier to debug that.

Just half an hour ago SRB did an auto switch and the hasrate dropped by 500 mh/s, and it's very slowly recovering. A manual switch also causes hashrate drops.

Hi all..

Can I write identifying information to BIOS, using atiflash (give it some custom serial / id / pn or something) so I can flash specific gpu using command line , without having to use the GPU index?
Atiflash has these command parameters as you'll know..
-padevid=<ID>   Use with -pa command to update adapters of specific device ID.
-passid=<ID>    Use with -pa command to update adapters of specific SSID.
-pasvid=<ID>    Use with -pa command to update adapters of specific SVID.
-pavbpn=<VBPN>  Use with -pa command to update adapters of specific VBIOS PN.
If I can modify any of them, I should be able to flash them without having to use the GPU index... This way I could mark the GPU's BIOS and not have to use their indexes, which is good because the index may change when I'm trying to weed out a bad riser etc., and that also enables to target 11th, 12th gpu's which Atiflash cannot address with the -p command alone.

Any ideas are welcome!

Doktor, can you make "fast pool switch" not so fast? If you can add a 3-4 second delay ("switching to pool: xxxxx in 3 seconds") while allowing the user to press p again to switch to the next pool, this would allow us to switch pools without connecting and disconnecting many times if we have many pools in pools txt, so I'd be able to press p three times to switch to the 4th in list, without connecting and disconnecting the first three, and the switch would be more graceful (without having to dispose the current job, connect, fire up the next job, only to dispose it again because I'm trying to connect to the other pool). Every key press would cancel the previous timeout, and add a new 3-4 seconds timeout.

Sure:
Log For Doktor

You can search for "hesido" where I added comments. There's not much meat though, it just hangs. Here you won't see retrying and stucking again becasue I either restarted after XMR-Stak or rebooted. You can also see the wildly varying hashrates for the same gpu's.

For example, I start a run, and 1 or 2 gpu's produce 0 hashes, and this is warned in the console. I quit without waiting.. Start again, the first gpu which produced 0 hashrate cannot get past the compile, it just hangs, no errors. When this happens, the gpu never gets past the compile phase with SRB. I then run XMR-Stak, GPU is working, and I go back to SRB, the GPU passes compile and starts working, sort of like XMR-Stak gets it unstuck, maybe it does something different when initializing GPU's.

Doktor, what can you say about the random hash rate?

SRB does get the best hashrate, and I even managed 1000 mh/s for all my cards, in one run, but what happens is this:
e.g. Sometimes, GPU0 gives 920h/s, sometimes the same gpu, just by restarting miner, gives 1000 mh/s, but then some other card, e.g. GPU5 which gave 1000mh/s, may (or may not) do 920-940 mh/s.. The total may vary +/- 800 mh/s, and it doesn't change much during the run (it gets stabilized in a few minutes, stays that way)

Sometimes a gpu gets 0 hashrate, I restart, it fails on compilation phase. I use XMR-Stak to get it working back, switch back to SRB and it begins working (SRB cannot get it unstuck however many restarts!)

You can set different config.txt's and have that run in .bat:

--config config580.txt

and the other with
--config config570.txt

Hashrate lottery..

Hi all, I'm getting the occasioanal 1000 mh/s from some of my identical rx580's with identical OC parameters, other times they do 930-950, but it's so random.. With the same settings, in one run the same gpu may do 1000, the next run it's 950 but another one takes the crown... Do you have any idea why this would happen? Using auto-intensity which sets at 51. If I manually set it to 50 I get slightly lower hashrate (duh), if I set it to 52 a couple or more doesn't start hashing.

I *once* managed 1000 mh/s from all of them, it wasn't even a clean re-start, but a switch between xmr-stak.. Would love to hear why this would happen.

Thanks! I don't want to flash anymore as every time I do it I get shivers down my spine

But here's one thing about flashing, two of my cards failed flash... Bios write failed multiple times, gpu's no longer listed as AMD, bios read was not even working. Then I continued a few hours of operation with other gpu's, reading about fixing bricked cards, and then they literally fixed themselves, with the original bios. I don't think MSI Armor has dual bios so I don't know how that happened. You guys have any ideas??


Maybe if I increase the Core clocks to 1240 it'd do 1050-1100 but it gets too hot and I have to crank up vcore so I think I struck a nice balance here, will try those after I get the hardware cost covered lol

MSI Armor RX580 8GB - Micron, using one click patch timings in Polaris Bios Editor.

Getting 1010 h/s using:
Intensity: 51, threads: double (Constrained by the Virtual Mem Size, out of space on SSD, could be higher)
1160 cclock / 880 vcore
2220 mclock / 880 vmem

Double threads are very important, it increases occupancy. Make sure you have sufficient vmem space, check out vmem usage using HWINFO, make sure there's at least 10% free vmem left during mining.

Microns are good, I like'em. One click patch timings in Polaris is very good for ETH mining (31-32 Mh/s) and it's possible that there may be timings that will take one to the moon at 2100 mclock catered for Cryptonight, but I don't want to play with BIOS everytime, it's really stressful because I'm afraid of bricking cards, so not going to touch'em for now.

Also, you need to close gpu-z or hwinfo during mining, it slows down the mining slightly but the losses would accumulate over time.