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

[Iamtutut]

DOKTOR83, there is a memory pill for AMD

Could you implement it on windows ? Right now it's linux only.

Here: https://bitcointalk.org/index.php?topic=5123724.0

[1566691377]

1566691377

[1566691377]

1566691377

[doktor83]

DOKTOR83, there is a memory pill for AMD

Could you implement it on windows ? Right now it's linux only.

Here: https://bitcointalk.org/index.php?topic=5123724.0

No, im not interested. Someone else will probably do it.

[JuanHungLo]

Using latest AMD driver, 19.3.3, win10, SRB 1.8.1, stock intensity, NO PPT, latest OverdriveNTool beta,
Vega 56@64 1552/852, 1100/900 getting H/s = 1994 average, stable for Monero.  Not sure of power draw.

[igotek]

i have just download the latest version.
It works well but there is a problem if i set gpus manually.

No problem on all 3 gpu

Code:

{
"cryptonight_type" : "stellitev8",
"intensity" : 0,
"double_threads" : true
}

mining not started and bat file close immediately.

Code:

{
"cryptonight_type" : "stellitev8",
"intensity" : 0,
"double_threads" : true

"gpu_conf" :
[
{ "id" : 0, "intensity" : 0 , "worksize" : 16, "threads" : 2},
{ "id" : 1, "intensity" : 0 , "worksize" : 16, "threads" : 2},
{ "id" : 2, "intensity" : 0 , "worksize" : 16, "threads" : 2}
]
}

Is there any chances to set gpus manually ?

[doktor83]

i have just download the latest version.
It works well but there is a problem if i set gpus manually.

No problem on all 3 gpu

Code:

{
"cryptonight_type" : "stellitev8",
"intensity" : 0,
"double_threads" : true
}

mining not started and bat file close immediately.

Code:

{
"cryptonight_type" : "stellitev8",
"intensity" : 0,
"double_threads" : true

"gpu_conf" :
[
{ "id" : 0, "intensity" : 0 , "worksize" : 16, "threads" : 2},
{ "id" : 1, "intensity" : 0 , "worksize" : 16, "threads" : 2},
{ "id" : 2, "intensity" : 0 , "worksize" : 16, "threads" : 2}
]
}

Is there any chances to set gpus manually ?

yes, put a comma after the double thread true line

[igotek]

Code:

{
"cryptonight_type" : "stellitev8",
"intensity" : 0,
"double_threads" : true,

"gpu_conf" :
[
{ "id" : 0, "intensity" : 0 , "worksize" : 16, "threads" : 2},
{ "id" : 1, "intensity" : 0 , "worksize" : 16, "threads" : 2},
{ "id" : 2, "intensity" : 0 , "worksize" : 16, "threads" : 2}
]
}

it is the same. not working. The strange thing is older versions work with same config.

[anvl]

 Some bug in the miner. On my systems with two CPUs one card is recognized as BUS: -125 by the miner whereas the system says it's 131.    Seems like not enough bits somewhere. As a result this card doesn't report ADL information.
 doktor83, could you please correct this error in your great miner?

[iRonNuke]

Why am I getting a lot of rejected shares? "Pool rejected result 0x000074E1 for job[2] [low difficulty share]" By a lot I mean some, most shares are ofcourse accepted but still, quite frequent.

Pool difficulty is set at 120000 by default. May I change it for better results?

The pool I'm using is nanopool.org btw.

[doktor83]

Why am I getting a lot of rejected shares? "Pool rejected result 0x000074E1 for job[2] [low difficulty share]" By a lot I mean some, most shares are ofcourse accepted but still, quite frequent.

Pool difficulty is set at 120000 by default. May I change it for better results?

The pool I'm using is nanopool.org btw.

You get low diff shares when your gpu returns a bad result. So loosen on your OC , or depending of your card, maybe you use 'bad' mem. straps.

[RuMiner]

DOKTOR83, there is a memory pill for AMD
Could you implement it on windows ? Right now it's linux only.

Cryptonights are not so sensitive to memory straps, it's good for ETH

[iRonNuke]

Why am I getting a lot of rejected shares? "Pool rejected result 0x000074E1 for job[2] [low difficulty share]" By a lot I mean some, most shares are ofcourse accepted but still, quite frequent.

Pool difficulty is set at 120000 by default. May I change it for better results?

The pool I'm using is nanopool.org btw.

You get low diff shares when your gpu returns a bad result. So loosen on your OC , or depending of your card, maybe you use 'bad' mem. straps.

Is there any way to see what GPU that is getting this error, if it's just one or all GPUs? I can see how many errors and frequency in %. It just says what job number it is?

95,5% accepted shares. Maybe not much to care about in about one hour?

[pbfarmer]

Testing now 19.3.2 and ONT 0.2.8, the timing level whatever i put isn't changing the hashrate for me on Vega56. Is it just me or .. ?

I've never seen any results from changing timing levels in wattman.  I get the sense they put in the functionality, maybe to provide actual timings at a later date.

[pbfarmer]

DOKTOR83, there is a memory pill for AMD
Could you implement it on windows ? Right now it's linux only.

Cryptonights are not so sensitive to memory straps, it's good for ETH

This is absolutely not true.  At least earlier versions of CN (haven't personally confirmed w/ cnv4) saw significant benefits from lower latencies.  ETH on the other hand, being bandwidth sensitive, does best w/ higher clocks, which in some cases requires higher latencies.  For example - the commonly available 'ubermix' straps for samsung were great for CN - they do not seem to be the best for ETH as the timings are so tight, clocks tend to be capped around 2K.

[AVP]

Is anyone experiencing crashes & freezes on GRAFT algo ?

I'm seeing this on RX 470 rigs & RX 560 rigs. (RX 570 rigs seem fine)

[MinermanNC]

I have SRB MINER CN 1.181 running perfectly on windows 7 pushing 2 AMD 7790's

Can not get it to run correctly on Windows 10 pushing 1 R9 270x. It starts and receives work from pool, but does not find any shares. Nor does it display any GPU readings "temp, fan speed etc.. shows all zeros there.
Thanks  

When you try out different drivers every time clear the cache directory. R9 270x cards work fine on W10 and 18.6.1 drivers.

Hey thanks will give that a try. I have not done that and will try 18.6.1 drivers  

[3MEHDI]

V1.8.1
- Fixed a bug that could crash miner if using CNV4 (R) algo
- Fixed a bug that crashed miner if doing fast algo switching from CNV4 to any algo
- Stales are not displayed anymore by default, added parameter --showstales which turns back on the display of stale shares
- Changed --maxnosharesent default value from 15 minutes to 30
- Logging is now disabled by default in the example start.bat
- Added parameter --preparedata, which could pontentially make a small speed increase on weak GPU's, but also could make it worse. All algos except webchain


+ If you are having ocassional crashes out of nowhere while mining the new V4 (R) algo, please update to version 1.8.1 as this issue is now (hopefully) fixed

+ The info miner displays and is called 'stale shares' is not displayed by default anymore, so if you miss it, and know what is it (it only displays the number of shares sent after a new job was received, it's not the real number of stale shares - that's something only the pool knows), then you can turn it back on by adding --showstales in start.bat

+ A new experimental (beta) parameter --preparedata added, and when enabled CPU will prepare some stuff for the GPU before it begins to work, so this *could* potentially lead to a small increase in hashrate on weaker, older GPU's. I tested on Vega56 and Rx58x series, and there was no gain, but i would like someone to test on weak cards that i don't have, older gcn1,2 series.


Please all of you having crashes on 1.7.9 and 1.8.0 on V4 algo , try out 1.8.1 as this issue should be fixed now.

Hi dear
i install version 1.8.1
After 8 to 9 hours, the temperature of my Gpu increases without reason.
Up to 80 ° C
I will have to re-run the Meining software
Again 8 to 9 hours later this happens
The problem is not the cooling system

3x sapphire  orginal  pack vega 56 upgrade bios to vega 64  samsung chip

[Piradoxlanieve]

Since the last versions, the SRBMiner-CN.exe stopped working, I have to close and re-run manually, the executable does not restart itself, I'm mining bittube, my rig is 6 rx480, 1 rx580 and 1 gtx1070, before it did not happen but now it happens 2 times or 3 a day.

Sorry my bad english.

Windows error report

Nombre de la aplicación con errores: SRBMiner-CN.exe, versión: 1.8.1.0, marca de tiempo: 0x00000000
Nombre del módulo con errores: SRBMiner-CN.exe, versión: 1.8.1.0, marca de tiempo: 0x00000000
Código de excepción: 0xc0000005
Desplazamiento de errores: 0x0000000000085db8
Identificador del proceso con errores: 0x165c
Hora de inicio de la aplicación con errores: 0x01d4e1f818cc07ae
Ruta de acceso de la aplicación con errores: C:\Users\RX480\Desktop\SRBMiner-CN\SRBMiner-CN.exe
Ruta de acceso del módulo con errores: C:\Users\RX480\Desktop\SRBMiner-CN\SRBMiner-CN.exe
Identificador del informe: 473c3244-8f9e-40f4-8ea6-5ed4271bbe3f
Nombre completo del paquete con errores:
Identificador de aplicación relativa del paquete con errores:

[ikicha]

V1.8.1
- Fixed a bug that could crash miner if using CNV4 (R) algo
- Fixed a bug that crashed miner if doing fast algo switching from CNV4 to any algo
- Stales are not displayed anymore by default, added parameter --showstales which turns back on the display of stale shares
- Changed --maxnosharesent default value from 15 minutes to 30
- Logging is now disabled by default in the example start.bat
- Added parameter --preparedata, which could pontentially make a small speed increase on weak GPU's, but also could make it worse. All algos except webchain


+ If you are having ocassional crashes out of nowhere while mining the new V4 (R) algo, please update to version 1.8.1 as this issue is now (hopefully) fixed

+ The info miner displays and is called 'stale shares' is not displayed by default anymore, so if you miss it, and know what is it (it only displays the number of shares sent after a new job was received, it's not the real number of stale shares - that's something only the pool knows), then you can turn it back on by adding --showstales in start.bat

+ A new experimental (beta) parameter --preparedata added, and when enabled CPU will prepare some stuff for the GPU before it begins to work, so this *could* potentially lead to a small increase in hashrate on weaker, older GPU's. I tested on Vega56 and Rx58x series, and there was no gain, but i would like someone to test on weak cards that i don't have, older gcn1,2 series.


Please all of you having crashes on 1.7.9 and 1.8.0 on V4 algo , try out 1.8.1 as this issue should be fixed now.

Hi dear
i install version 1.8.1
After 8 to 9 hours, the temperature of my Gpu increases without reason.
Up to 80 ° C
I will have to re-run the Meining software
Again 8 to 9 hours later this happens
The problem is not the cooling system

3x sapphire  orginal  pack vega 56 upgrade bios to vega 64  samsung chip

Try to disable automatic temp configuration or try extra conf :

"target_temperature" : 70,
"shutdown_temperature" : 80,

Goodluck

[babkaVkedax]

SRBMiner Cryptonight AMD GPU Miner All - rx 570 4gb problem
All drivers, except
Win10-64Bit-Crimson-ReLive-Beta-Blockchain-Workloads-Aug23
hash rate is 2 times lower than it should be
eg:
haven 750/780 --- 340/350
How to solve a problem?
Thank.

[iRonNuke]

SRBMiner Cryptonight AMD GPU Miner All - rx 570 4gb problem
All drivers, except
Win10-64Bit-Crimson-ReLive-Beta-Blockchain-Workloads-Aug23
hash rate is 2 times lower than it should be
eg:
haven 750/780 --- 340/350
How to solve a problem?
Thank.

Why are you using a soon 2 year old driver? Maybe that's the issue, don't know. But try atleast 1.8.6.1 or any newer and enable compute mode.