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

[doktor83]

Everyone with this problem uses 18.5.1 drivers ?

I use dag fix beta drivers, and have same issue...

Only with V1.5.8 ?

[livada]

Everyone with this problem uses 18.5.1 drivers ?

i have Win10-64Bit-Crimson-ReLive-Beta-Blockchain-Workloads-Aug23 driver

PS. Misli mda si prije koristio samo prva cetri slova za kompilaciju i on je prepoznao to a sad koristi  10 slova pa stalno radi nanovo compiliranje.

687f. prije
687f********** - 1.5.8 verzija

mozda i grijesim

[UnclWish]

Everyone with this problem uses 18.5.1 drivers ?

I use dag fix beta drivers, and have same issue...

Only with V1.5.8 ?

I have this issue with 18.5.1 and 18.5.2 on 1.5.7 and 1.5.8 versions. Windows 10 1803 x64. And wrong names of cards. 1st 2 RX 580 cards detects as R9 200 series. I have 3rd card r9 270X.

[killfrenzy]

Everyone with this problem uses 18.5.1 drivers ?

I use dag fix beta drivers, and have same issue...

Only with V1.5.8 ?

1.5.6
1.5.7
1.5.8 - not tested yet

[vmozara]

My vega win 10 1803 rigs don´t do this. However, I downloaded 1.5.8. 14 hours ago, run the miner and it was running ever since.
I took a look inside 1.5.7 folder but only on one of the rigs I found 2 files. So I guess it is not miner related, more some issue with driver or setup..

Anyway, I am using this miner since 1.5.7 version. 1.5.8. has even better hashrate. Working very stable. I dumped xmr stak that was working fine for me and the hashrate difference is incredible.

Doktor83, I assume you are Serbian, right? Pozdrav iz HR
Please, can you try to explain this.
XMR stak on supportxmr pool shows exactly the same 24 hour hashrate both the pool and software, yet the CAST and SRB show mush bigger miner hashrate, but supportxmr hashrate reports almost 20% less. (I counted and calculated hashrate)

I tried some other pool and hashrate was reported correctly. What could be the cause of this? The miner and the pool both report all good shares

Attention Vega owners
SRBMINER 1.5.8 + Adrenalin 18.5.2 rig vega64x6 = 12200H/s, rig vega56x6=12000h/s
this with power tables from vega mining guide and 1408/800 and 1100/800
awesome!

[hesido]

Doktor, a temporary fix would be to allow gpu config to point to SRB files (Only for power users...) so users can tell SRBMiner to use specific file per gpu. (Same if all cards are identical, of course)

[nordmann666]

My vega win 10 1803 rigs don´t do this. However, I downloaded 1.5.8. 14 hours ago, run the miner and it was running ever since.
I took a look inside 1.5.7 folder but only on one of the rigs I found 2 files. So I guess it is not miner related, more some issue with driver or setup..

Anyway, I am using this miner since 1.5.7 version. 1.5.8. has even better hashrate. Working very stable. I dumped xmr stak that was working fine for me and the hashrate difference is incredible.

Doktor83, I assume you are Serbian, right? Pozdrav iz HR
Please, can you try to explain this.
XMR stak on supportxmr pool shows exactly the same 24 hour hashrate both the pool and software, yet the CAST and SRB show mush bigger miner hashrate, but supportxmr hashrate reports almost 20% less. (I counted and calculated hashrate)

I tried some other pool and hashrate was reported correctly. What could be the cause of this? The miner and the pool both report all good shares

Attention Vega owners
SRBMINER 1.5.8 + Adrenalin 18.5.2 rig vega64x6 = 12200H/s, rig vega56x6=12000h/s
this with power tables from vega mining guide and 1408/800 and 1100/800
awesome!

1408 and 1100 with only 800??? which power play tables?!?!
everything under 875v and all miners crash instant

[livada]

Attention Vega owners
SRBMINER 1.5.8 + Adrenalin 18.5.2 rig vega64x6 = 12200H/s, rig vega56x6=12000h/s
this with power tables from vega mining guide and 1408/800 and 1100/800
awesome!

2000 hr in v7 with 800mv?
pls SS ofr miner and overdirive setup

your vega 56  use 64 bios?

vhat vega u have? samsung-hynix  memory?

soft powertable?

12000hr in v7 and use ?? power from wall?

[RuMiner]

XMR stak on supportxmr pool shows exactly the same 24 hour hashrate both the pool and software, yet the CAST and SRB show mush bigger miner hashrate, but supportxmr hashrate reports almost 20% less. (I counted and calculated hashrate)

I'm digging XMR on Nanopool and usually it shows higher average hashrate than miner gives. For example, right now pool's average for 6 hours is 7910 while miner shows stable 7750 (4xVega56).

[lebuawu2]

Hi Dok,

Is it possible to add feature when miner get diff from pool more than 1,000,000 or any other diff that we specify it will reconnect to pool again?
Because nicehash will always increase diff until miner take time to solve that. After that because miner take time to submit share nicehash server will disconnected. So instead after sometimes miner reconnect I think better after miner get diff above diff we specify in miner it will auto reconnect.

Thanks.

can you please added this feature in the next release? really need it for nicehash and fairpool also because sometimes pool send job that have diff more than miner can handle.

[doktor83]

But I think that doctor must update miner to support latest AMD drivers without issues.

Serious miners don't always update their drivers when a new one comes out, they use ones that are proven to be good and stable.
A driver that isn't capable of recognising its own GPU is a trash, and shouldn't be used at all. Altough no one else except you reported this issue, so i guess it's something on your side.

I really can't check out every new driver and re-work miner every time when a new driver comes out.
You should stick to a driver that is working stable and good for you.

[doktor83]

My vega win 10 1803 rigs don´t do this. However, I downloaded 1.5.8. 14 hours ago, run the miner and it was running ever since.
I took a look inside 1.5.7 folder but only on one of the rigs I found 2 files. So I guess it is not miner related, more some issue with driver or setup..

On my win10 rigs , NOT updated to 1803, and the good old blockchain driver, i can't reproduce the new cache file on every run bug..
But i will ofc look into it.

[UnclWish]

I notice on 1.5.8 often appears duplicate shares on nicehash heavy algo. If it's some way to reduce amount of duplicate shares or fix that?

[doktor83]

before u have 1 file : 687f.   without extension and this is it. now you co,mpile  every time when start .before you compile only 1 time for 1 algo.

That's because on earlier versions there was a bug preventing creation of cached files for VEGA gpu's, so they were compiled every time, but 1 empty file was created
Those numbers all have a meaning, like worksize, num of CU's etc etc, thats how the miner knows which kernel to use.

Im just curious does it really every time , even if you did not change ANYTHING in config file like algo, or anything in gpu_conf, create a new file ?

[doktor83]

Hi Dok,

Is it possible to add feature when miner get diff from pool more than 1,000,000 or any other diff that we specify it will reconnect to pool again?
Because nicehash will always increase diff until miner take time to solve that. After that because miner take time to submit share nicehash server will disconnected. So instead after sometimes miner reconnect I think better after miner get diff above diff we specify in miner it will auto reconnect.

Thanks.

can you please added this feature in the next release? really need it for nicehash and fairpool also because sometimes pool send job that have diff more than miner can handle.

you are probably the only person on this earth who needs this, but ok i will add it

[doktor83]

I notice on 1.5.8 often appears duplicate shares on nicehash heavy algo. If it's some way to reduce amount of duplicate shares or fix that?

Are you sure those are duplicate shares? There is a mechanism that does not allow sending of the same result twice.
Also for nicehash there is a protection for stale shares, cause nicehash does not like them.

[UnclWish]

But I think that doctor must update miner to support latest AMD drivers without issues.

Serious miners don't always update their drivers when a new one comes out, they use ones that are proven to be good and stable.
A driver that isn't capable of recognising its own GPU is a trash, and shouldn't be used at all. Altough no one else except you reported this issue, so i guess it's something on your side.

I really can't check out every new driver and re-work miner every time when a new driver comes out.
You should stick to a driver that is working stable and good for you.

I know it all. But I was forced to change drivers because of Windows 1803 update. Only on 18.4.1 driver was added WDDM 2.4 support, but it was too buggy. I used sometime 18.3.4 on 1803, but sometimes I encountered bugs on Windows start and work. When 18.5.1 driver was released I installed him and it work in all miners. But on some of them it's wrong GPU detection. All other mining functions work.

And you as serious developer of miner with devfee! must update your miner to modern conditions in wich miners are placed. Creating .srb files on each start - it's the problem, isn't it?
Unstable speed of mining is second problem as I know. Many of users of your miner finds different methods to force miner to mine with max speed. Anyone used GPU-Z launching during mining, others just relaunch miner many times, untill miner gives max speed.

[UnclWish]

I notice on 1.5.8 often appears duplicate shares on nicehash heavy algo. If it's some way to reduce amount of duplicate shares or fix that?

Are you sure those are duplicate shares? There is a mechanism that does not allow sending of the same result twice.
Also for nicehash there is a protection for stale shares, cause nicehash does not like them.

Your miner show that it was finded rejected duplicate share. And on statistic report on "s" key it start to show:

Errors:
Duplicate share.: 1

[livada]

before u have 1 file : 687f.   without extension and this is it. now you co,mpile  every time when start .before you compile only 1 time for 1 algo.

That's because on earlier versions there was a bug preventing creation of cached files for VEGA gpu's, so they were compiled every time, but 1 empty file was created
Those numbers all have a meaning, like worksize, num of CU's etc etc, thats how the miner knows which kernel to use.

Im just curious does it really every time , even if you did not change ANYTHING in config file like algo, or anything in gpu_conf, create a new file ?

Every time. i not chg any. i go on loki back to hevy and go on new RYO. i try triton and  go on saronite and back again to heavy,
now i have 60 more file and 160mb lose space on disc. this is not good. version 1.5.1 work fine. -
https://image.prntscr.com/image/1ARAkS-vSbGo-vLw3inWHw.jpg

and first compile is to long. and start again miner  again i must wait so long for compile.

1.5.1 - first start wait long time. but  second miner  start in 2 sec.

Miner ti jednostavno ne prepoznaje fileke koje sam proizvodi. i stalno iznova mora napravit compajliranje koje traje li traje. iritira. i mislim d ase vracam na staru verziju jer ja mjenjam koinove po dificultu a to je barem 20 puta dnevno i taj veci HR mi ne znaci tolko kolko mi znaci da miner krene odma a ne nakon minute. barem stavi da se fileki brisu kad izadjem iz minera da ne mora mjos i t orucno radit dok ne nadjes gdje je greska prepoznavanja...sto se veceg HR tice. Moram barem 3-4 put apokrenut minera da krene s tim vecim HR-om. znaci nista ne diram samo palim i gasim minera. i to stvara fileke...

[doktor83]

But I think that doctor must update miner to support latest AMD drivers without issues.

Serious miners don't always update their drivers when a new one comes out, they use ones that are proven to be good and stable.
A driver that isn't capable of recognising its own GPU is a trash, and shouldn't be used at all. Altough no one else except you reported this issue, so i guess it's something on your side.

I really can't check out every new driver and re-work miner every time when a new driver comes out.
You should stick to a driver that is working stable and good for you.

I know it all. But I was forced to change drivers because of Windows 1803 update. Only on 18.4.1 driver was added WDDM 2.4 support, but it was too buggy. I used sometime 18.3.4 on 1803, but sometimes I encountered bugs on Windows start and work. When 18.5.1 driver was released I installed him and it work in all miners. But on some of them it's wrong GPU detection. All other mining functions work.

And you as serious developer of miner with devfee! must update your miner to modern conditions in wich miners are placed. Creating .srb files on each start - it's the problem, isn't it?
Unstable speed of mining is second problem as I know. Many of users of your miner finds different methods to force miner to mine with max speed. Anyone used GPU-Z launching during mining, others just relaunch miner many times, untill miner gives max speed.

Im doing the best i can.
There will always be users who have some kind of problems with the software, there will always be bugs..etc
Just go into the allmighty claymore threads, every third post is some problem reporting.

There are hundreds of SRBMiner users without any problems, where the miner works flawlessly.