SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching

[murgorx]

Okay, well I am not gonna lower the intensity in that case, because I simply do not use the rig as a computer anyway Just for a couple of secs each and every other day.
Thanks for the answers!

[1686173953]

1686173953

[1686173953]

1686173953

[istr]

@doktor83   I'm pretty sure that you are aware of all these occasions, I mean with the hashdrop.
Cards with 4gb memory dont have this issue, at least to me. They reach maximum hashspeed immediately.
The problem is with the 8gb cards.
Whenever I start your miner one of them, sometimes more, can go up to maximum, others no and they stay low all the time
even after 2,3,4 hours of mining.
Next time I'm starting your miner some other cards or card do the opposite thing. It's a random situation.
To help things out, you of course the developer of a great miner to me, I found out that running GPU-Z at the time your miner runs
and passing throu all cards one by one and then exiting, voula all cards running full speed. Problem solved.
But of course this is not a solution!!!
Maybe something with the interrupts?
I'm  trying to help!

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.

Hi, could you please explain a bit detail about steps to achieve it? Did you run GPU-Z right before ran SRB? Or while you clicked start SRB Miner, you then ran GPU-Z? Thanks.

Gentlemen,
things are very simple.

You have started SRBminer waiting a while, 2-3 minutes, to report the first hashrate total and give it some time to reach the top hashspeed as doktor83 says.
Then you realize the drop on some or all of your cards.
Now it's the time to fire up GPU-Z as miner runs and uses all the resources of GPUs.
I'm passing throu all GPUs one by one and then exiting from GPU-Z. If you stay running it you'll realize that there's a small drop in hashrate on all cards.
This is normal because of the memory resource usage of the 2 programs.
The great thing is that GPU-Z motivates SRBminer to reach the highest it can get.
As a programmer, I'm suspecting something with the interrupts or the memory management of GPUs.
For some cards it may need to run it a second time or and a third one.
Keep in mind that all this has to do with the RX 480-580 8gb cards which of course I run them with 2 threads and intensity 54, worksize 8.
I reach on them from 1070 to 1148 h/s.

There is no problem at all with RX 570-580 4gb cards. These cards, of course with 1 thread - worksize 8 - intensity 60-61, reach maximum hashing speed at once.
I'm getting on these cards from 755 to 780 h/s.
Sorry, I've forgotten to mention that all these are on heavy algorithm

I'm glad to help the community!
and waiting for a better miner from Doktor83.

[UnclWish]

@doktor83   I'm pretty sure that you are aware of all these occasions, I mean with the hashdrop.
Cards with 4gb memory dont have this issue, at least to me. They reach maximum hashspeed immediately.
The problem is with the 8gb cards.
Whenever I start your miner one of them, sometimes more, can go up to maximum, others no and they stay low all the time
even after 2,3,4 hours of mining.
Next time I'm starting your miner some other cards or card do the opposite thing. It's a random situation.
To help things out, you of course the developer of a great miner to me, I found out that running GPU-Z at the time your miner runs
and passing throu all cards one by one and then exiting, voula all cards running full speed. Problem solved.
But of course this is not a solution!!!
Maybe something with the interrupts?
I'm  trying to help!

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.

Hi, could you please explain a bit detail about steps to achieve it? Did you run GPU-Z right before ran SRB? Or while you clicked start SRB Miner, you then ran GPU-Z? Thanks.

Gentlemen,
things are very simple.

You have started SRBminer waiting a while, 2-3 minutes, to report the first hashrate total and give it some time to reach the top hashspeed as doktor83 says.
Then you realize the drop on some or all of your cards.
Now it's the time to fire up GPU-Z as miner runs and uses all the resources of GPUs.
I'm passing throu all GPUs one by one and then exiting from GPU-Z. If you stay running it you'll realize that there's a small drop in hashrate on all cards.
This is normal because of the memory resource usage of the 2 programs.
The great thing is that GPU-Z motivates SRBminer to reach the highest it can get.
As a programmer, I'm suspecting something with the interrupts or the memory management of GPUs.
For some cards it may need to run it a second time or and a third one.
Keep in mind that all this has to do with the RX 480-580 8gb cards which of course I run them with 2 threads and intensity 54, worksize 8.
I reach on them from 1070 to 1148 h/s.

There is no problem at all with RX 570-580 4gb cards. These cards, of course with 1 thread - worksize 8 - intensity 60-61, reach maximum hashing speed at once.
I'm getting on these cards from 755 to 780 h/s.
Sorry, I've forgotten to mention that all these are on heavy algorithm

I'm glad to help the community!
and waiting for a better miner from Doktor83.

GPU-Z didn't use any GPU's resources. it just connects to GPUs and monitors them.

All this connected to low-level accessing to GPUs via AMD ADL or other low-level driver such as phymem or like this.
I noticed that effect about year ago. It happens on GGS miner too. And not only GPU-Z has the same effect ))). Some hardware monitoring tools can do that too. Like HWInfo, but not all versions. It's exists method even without any tools to do that, but only for GPU wich display connected to.

Must to notice that Claymore's miners never had that issue. His miners allways runs at max speeds. This another one proof that Claymore knows more than others on AMD GPU programming. Looks like he realy worked or works now for AMD.

[Kgonla]

@doktor83   I'm pretty sure that you are aware of all these occasions, I mean with the hashdrop.
Cards with 4gb memory dont have this issue, at least to me. They reach maximum hashspeed immediately.
The problem is with the 8gb cards.
Whenever I start your miner one of them, sometimes more, can go up to maximum, others no and they stay low all the time
even after 2,3,4 hours of mining.
Next time I'm starting your miner some other cards or card do the opposite thing. It's a random situation.
To help things out, you of course the developer of a great miner to me, I found out that running GPU-Z at the time your miner runs
and passing throu all cards one by one and then exiting, voula all cards running full speed. Problem solved.
But of course this is not a solution!!!
Maybe something with the interrupts?
I'm  trying to help!

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.

Hi, could you please explain a bit detail about steps to achieve it? Did you run GPU-Z right before ran SRB? Or while you clicked start SRB Miner, you then ran GPU-Z? Thanks.

Gentlemen,
things are very simple.

You have started SRBminer waiting a while, 2-3 minutes, to report the first hashrate total and give it some time to reach the top hashspeed as doktor83 says.
Then you realize the drop on some or all of your cards.
Now it's the time to fire up GPU-Z as miner runs and uses all the resources of GPUs.
I'm passing throu all GPUs one by one and then exiting from GPU-Z. If you stay running it you'll realize that there's a small drop in hashrate on all cards.
This is normal because of the memory resource usage of the 2 programs.
The great thing is that GPU-Z motivates SRBminer to reach the highest it can get.
As a programmer, I'm suspecting something with the interrupts or the memory management of GPUs.
For some cards it may need to run it a second time or and a third one.
Keep in mind that all this has to do with the RX 480-580 8gb cards which of course I run them with 2 threads and intensity 54, worksize 8.
I reach on them from 1070 to 1148 h/s.

There is no problem at all with RX 570-580 4gb cards. These cards, of course with 1 thread - worksize 8 - intensity 60-61, reach maximum hashing speed at once.
I'm getting on these cards from 755 to 780 h/s.
Sorry, I've forgotten to mention that all these are on heavy algorithm

I'm glad to help the community!
and waiting for a better miner from Doktor83.

I've seen also small changes in H/s with V7, it just increases a bit after running GPU-Z but the hash rate is more stable, only in 8GB cards, there is no change in 4GB ones.
When using Heavy with 8GB I get best results with almost maximum intensity: "intensity" : 62, "worksize" : 8, "threads" : 2
Setting it to 63 H/s go heavily down & with 64 don' work, when lowering to 61, 60... the H/s goes down.
But when I run V7 for 4GB is the same than Heavy "intensity" : 61, "worksize" : 8, "threads" : 2 is the max. & best.
For 8GB in V7 if I go with I higher than about 82 there is almost no increase in H/s & it becomes more unstable the higher the I, when 122 or so should give the best results, I think.
 

[clancy182]

@doktor83   I'm pretty sure that you are aware of all these occasions, I mean with the hashdrop.
Cards with 4gb memory dont have this issue, at least to me. They reach maximum hashspeed immediately.
The problem is with the 8gb cards.
Whenever I start your miner one of them, sometimes more, can go up to maximum, others no and they stay low all the time
even after 2,3,4 hours of mining.
Next time I'm starting your miner some other cards or card do the opposite thing. It's a random situation.
To help things out, you of course the developer of a great miner to me, I found out that running GPU-Z at the time your miner runs
and passing throu all cards one by one and then exiting, voula all cards running full speed. Problem solved.
But of course this is not a solution!!!
Maybe something with the interrupts?
I'm  trying to help!

On my Vega 56 on 18.3.4 drivers (HCC disabled), I run cast_xmr with the maxmem option and then when the hash rate gets a little higher than 1325, I quit and switch to SRB miner (56 intensity, 8 worksize) and then I get the 1450-1500 hashes

Some people have reported that if you do this with 60 intensity and then drop it back down to 56, you get the full hashrate but I haven't gotten it to work

When I had blockchain drivers, I couldn't get this to work reliably but I did succeed a few times by enabling HCC memory

in my case, i launch the miner with 60 intenisty, i kill the process and i relaunch it with 56 to have 1500 hs per vega56

[niko2004x]

If started with Vegas miner does not create cached compiled kernels.
Each start it compiles kernels again. Only zero-sized file with name '687F' is created.
Start of the log looks like this.

GPU0: 687F:C3 [gfx901] [8176 MB][Intensity 110.0][W: 8][T: 2][K: 1][BUS: 19]
GPU1: 687F:C1 [gfx901] [8176 MB][Intensity 110.0][W: 8][T: 2][K: 1][BUS: 3]
GPU2: 687F:C1 [gfx901] [8176 MB][Intensity 110.0][W: 8][T: 2][K: 1][BUS: 10]
GPU3: 687F:C3 [gfx901] [8176 MB][Intensity 110.0][W: 8][T: 2][K: 1][BUS: 7]
GPU4: 687F:C1 [gfx901] [8176 MB][Intensity 110.0][W: 8][T: 2][K: 1][BUS: 16]
GPU5: 687F:C1 [gfx901] [8176 MB][Intensity 110.0][W: 8][T: 2][K: 1][BUS: 13]

---------------------------------------------------------
SRBMiner Cryptonight AMD GPU miner 1.5.3
DevFee 1 minute every 2 hours (~ 0.85%)
Press 's' to get some stats
Press 'h' to get some hashrate
Give it a few minutes to reach maximum hashrate
---------------------------------------------------------
Total pools: 1

Please wait...

Cryptonight ArtoCash mode enabled

[2018-05-13 16:14:07] Heating up system, please wait...
[2018-05-13 16:14:07] Compiling kernel for DEVICE BUS ID 19 ...
[2018-05-13 16:14:21] Compiling kernel for DEVICE BUS ID 19 ...

[doktor83]

Interesting, all that gpu-z does (or it should do ) is to run a few opencl queries, and some monitoring stuff. But who knows.
I tried that suggestion to fire up gpu-z and it should improve hash on 580 8g cards on heavy, but that is not the case here.

Here's an idea for you guys that gpu-z helps: try running --listdevices in a new console window while the miner is running in an other.
So , do a :

SRBMiner-CN.exe --listdevices
This does some opencl queries, maybe some of those that help pumping the hashrate ?

[doktor83]

If started with Vegas miner does not create cached compiled kernels.
Each start it compiles kernels again. Only zero-sized file with name '687F' is created.

Anyone else got this problem with Vegas ?

[rodney2250]

Hi all,

I am the developer of the FREE rig-monitor - rig, pool, market data and power usage monitoring tool. I have just added support for SRBMiner to the app.

You can read about it here:https://bitcointalk.org/index.php?topic=2128602.0

The binaries can be found here: https://github.com/rodneymo/rig-monitorv2/releases/tag/2.1.d.3

[hesido]

Interesting, all that gpu-z does (or it should do ) is to run a few opencl queries, and some monitoring stuff. But who knows.
I tried that suggestion to fire up gpu-z and it should improve hash on 580 8g cards on heavy, but that is not the case here.

Here's an idea for you guys that gpu-z helps: try running --listdevices in a new console window while the miner is running in an other.
So , do a :

SRBMiner-CN.exe --listdevices
This does some opencl queries, maybe some of those that help pumping the hashrate ?

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!

[Kgonla]

How can I remove T: RPM: CC: MC: & bus after the H/s?
I use --adldisable & I see all sensors with 0 value.

[mutual.consent]

If started with Vegas miner does not create cached compiled kernels.
Each start it compiles kernels again. Only zero-sized file with name '687F' is created.

Anyone else got this problem with Vegas ?

Yes I have that issue as well - mentioned it a few pages back (couldn't see .srb files in miner directory with Vegas and blockchain drivers).

[Vince34]

If started with Vegas miner does not create cached compiled kernels.
Each start it compiles kernels again. Only zero-sized file with name '687F' is created.

Anyone else got this problem with Vegas ?

Yes,
Same here with 4 Vegas.
That's not an issue for me as I almost never restart the miner.
Best CN miner ever!
Keep up the good work

Edit: I use V7 algo and blockchain drivers

[istr]

Interesting, all that gpu-z does (or it should do ) is to run a few opencl queries, and some monitoring stuff. But who knows.
I tried that suggestion to fire up gpu-z and it should improve hash on 580 8g cards on heavy, but that is not the case here.

Here's an idea for you guys that gpu-z helps: try running --listdevices in a new console window while the miner is running in an other.
So , do a :

SRBMiner-CN.exe --listdevices
This does some opencl queries, maybe some of those that help pumping the hashrate ?

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!

Sorry Doktor,

but your suggestion doesn't work at least for me. It does nothing at all in hashrate improvement as does GPU-Z.
Sorry, but this is the case.

[ipe4enko]

I think it is wrong gpu numbers in warning message if using gpu reorder. In my case warning say that GPU1 hashing speed is 0, but statistic say that GPU3 speed is 0
https://ibb.co/mzczQd

[rednoW]

If started with Vegas miner does not create cached compiled kernels.
Each start it compiles kernels again. Only zero-sized file with name '687F' is created.

Anyone else got this problem with Vegas ?

Yes, have this issue with my 3 Vegas on aug blockchain drivers. Also your miner seems to be unstable with vega and blockchain and heavy-algo. V7 is running fine, better than cast-xmr

[istr]

Another problem I noticed is that there is no "total" hashrate line when disabling a gpu.
This reminded me previous post with its screenshot.

[doktor83]

Another problem I noticed is that there is no "total" hashrate line when disabling a gpu.
This reminded me previous post with its screenshot.

indeed, fix coming in next version

[doktor83]

I think it is wrong gpu numbers in warning message if using gpu reorder. In my case warning say that GPU1 hashing speed is 0, but statistic say that GPU3 speed is 0
https://ibb.co/mzczQd

eagle eye, thanks for noticing 

[istr]

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.