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

[doktor83]

Maked many tries with 1.6.1 version on 580 cards heavy algo. Max I can get is about 10 h/s less than 1.6.0 with kernel created by 1.5.8 and the same speed as 1.6.0 with kernel created by 1.6.0.
The problem is in creating kernels. 1.5.8 makes kernel files every miner launch. And some of them was not good, but some - Excellent!
1.5.9, 1.6.0 and 1.6.1 can't make fastest kernel...

Normal v7 can't get any close result as 1.6.0 even with the kernel created by 1.6.0. In 1.6.1 intensity higher 100 couses speed to jump up and down, looks like new v7 kernel in 1.6.1 requires more video memory that's why 8Gb now not enough for optimal intensity for 8Gb 112-118.

you need to stop pushing the h key , and start looking at an average value of minimum 5 min, better 30 min.

1.6.1 does not require more vram.

[1714126959]

1714126959

[UnclWish]

Maked many tries with 1.6.1 version on 580 cards heavy algo. Max I can get is about 10 h/s less than 1.6.0 with kernel created by 1.5.8 and the same speed as 1.6.0 with kernel created by 1.6.0.
The problem is in creating kernels. 1.5.8 makes kernel files every miner launch. And some of them was not good, but some - Excellent!
1.5.9, 1.6.0 and 1.6.1 can't make fastest kernel...

Normal v7 can't get any close result as 1.6.0 even with the kernel created by 1.6.0. In 1.6.1 intensity higher 100 couses speed to jump up and down, looks like new v7 kernel in 1.6.1 requires more video memory that's why 8Gb now not enough for optimal intensity for 8Gb 112-118.

you need to stop pushing the h key , and start looking at an average value of minimum 5 min, better 30 min.

1.6.1 does not require more vram.

I waits up to 10 minutes every try. Max speed lower about 10 h/s than 1.6.0 with kernel from 1.5.8. Speed lower only with good kernel from 1.5.8. With kernel created by 1.6.0 speed on heavy with 1.6.1 and 1.6.0 is equal. This means that 1.5.8 can build better kernels than 1.6.0 and 1.6.1. But 1.6.1 can't work with old kernels...

And miner on CN-v7 didn't give stable speed on intensity 100+ like 1.6.0. Thats causes speed drop with intensity 112-118. 1.6.0 woks perfect with 112-118 intensity on 580 8Gb cards.

[livada]

The problem is in creating kernels. 1.5.8 makes kernel files every miner launch. And some of them was not good, but some - Excellent!
1.5.9, 1.6.0 and 1.6.1 can't make fastest kernel...

This is TRUE. For VEGA card use old 1.5.8 .srb file and rename in 1.6.0. srb file. Old srb file have 30/50+ HR beter per card.
Or use HEXEDITOR and change this in .SRB file:
DWORKSIZE=8 -DGPU_MAX_NONCES=255 -DCRYPTONIGHT_MASK=4194288 -DCRYPTONIGHT_ITERATIONS=262144 -DCRYPTONIGHT_MEMORY=4194304 -DMEMORY_CHUNK=43650010 -DCRYPTONIGHT_TYPE=3

This is PROBLEM. If you have this number DMEMORY_CHUNK=0 -or 16  this is BAD or
if you have this number DMEMORY_CHUNK=113650010 - this is _BAD

this is BEST size for vega DMEMORY_CHUNK=43650010- for 1.5.8 and 1.5.9 and 1.6.0 .
1.6.1 not work with old .srb file.

HEAVY ALGO with vega- samsung
4*vega 56 with orginal  .srb file = 5900HR
4*vega 56 with modify old -srb file = 6150HR
https://image.prntscr.com/image/DYsj7omDRHy5AIzy4htCTg.jpg
https://image.prntscr.com/image/SD8GbFN2QBq0WHPAp6AtlA.jpg


HEAVY aLGO with VEGA 56 NITRO- Hynix memory
6*vega with orginal 1.6.0 srb file = 8570HR
6*vega with old 1.5.8 .srb file = 8750HR
https://image.prntscr.com/image/lp7AhqG8TXmoo5nEzeEPUw.jpg


If you dont modify with hexeditor just use 1.5.8 and start miner 2-3-4- time and see HR - when you see BIGER HR just save this. srb file
This file have DMEMORY_CHUNK=43650010 or similar for BETTER HR. Renama this file in new 1.6.0 .srb file and overwrite . and this is it. NEW BEST HR is here.
1.6.1 never up to beter HR .i try 1.6.1 1-2 hour and 1.6.1 have bad HR.
1.6.0 with 1.5.8 .srb file is BEST srbminer ever. No compile kernel (only load) when started- only 1 .srb file per algo(in CACHE folder) .Best HR.

[doktor83]

oh, haxors .. 
well, ok.

[UnclWish]

Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166

1.5.9 and 1.6.0 always creates kernels with chunk 0...

Is there is some dependences? What max it can be? What best?

In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2

[doktor83]

Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166

1.5.9 and 1.6.0 always creates kernels with chunk 0...

Is there is some dependences? What max it can be? What best?

In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2

thats a bug, it's an int that wasn't mem allocated previously so it's just a random garbage value. I really don't know how these huge values can improve anything, but if its working for you im happy
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  

if you can confirm that its 'working good' every time ( and of course that it finds shares ) i can add it as a def value for rx 8gb cards

[lncm]

What's the matter with AMD drivers since 18.2.1 that one 560 of mine is recognized by every mining software as a 570, and all cryptonight miners crash the system on that rig within a few seconds??

I tried 18.6.1 and the bug is still there!

I would like to use newer drivers because 18.2.1 have a nasty bug with that system.

Is there a way around this using SRB config? Is is a matter of work size or intensity, I suppose the software treats it as a real 570 and it crashes? 

Thanks Doktor.

[UnclWish]

Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166

1.5.9 and 1.6.0 always creates kernels with chunk 0...

Is there is some dependences? What max it can be? What best?

In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2

thats a bug, it's an int that wasn't mem allocated previously so it's just a random garbage value. I really don't know how these huge values can improve anything, but if its working for you im happy
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  

if you can confirm that its 'working good' every time ( and of course that it finds shares ) i can add it as a def value for rx 8gb cards

Not every time. It's still needs to restarts miner several times. But max speed can be achieved.
About fragments - you mean that way:

{ "id" : 0, "intensity" : 51.1, "worksize" : 8, "threads" : 2, "persistent_memory" : false, "fragments" : 12345678},

And will it work for 1.6.1 ?

[doktor83]

Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166

1.5.9 and 1.6.0 always creates kernels with chunk 0...

Is there is some dependences? What max it can be? What best?

In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2

thats a bug, it's an int that wasn't mem allocated previously so it's just a random garbage value. I really don't know how these huge values can improve anything, but if its working for you im happy
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  

if you can confirm that its 'working good' every time ( and of course that it finds shares ) i can add it as a def value for rx 8gb cards

Not every time. It's still needs to restarts miner several times. But max speed can be achieved.
About fragments - you mean that way:

{ "id" : 0, "intensity" : 51.1, "worksize" : 8, "threads" : 2, "persistent_memory" : false, "fragments" : 12345678},

And will it work for 1.6.1 ?

yes, exactly that's how you can use it.

[UnclWish]

Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166

1.5.9 and 1.6.0 always creates kernels with chunk 0...

Is there is some dependences? What max it can be? What best?

In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2

thats a bug, it's an int that wasn't mem allocated previously so it's just a random garbage value. I really don't know how these huge values can improve anything, but if its working for you im happy
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  

if you can confirm that its 'working good' every time ( and of course that it finds shares ) i can add it as a def value for rx 8gb cards

Not every time. It's still needs to restarts miner several times. But max speed can be achieved.
About fragments - you mean that way:

{ "id" : 0, "intensity" : 51.1, "worksize" : 8, "threads" : 2, "persistent_memory" : false, "fragments" : 12345678},

And will it work for 1.6.1 ?

yes, exactly that's how you can use it.

Hmmm... Thanks I'll try it. Last question: does it means that with this parameter no matter what chunk size in kernel file?

[doktor83]

Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166

1.5.9 and 1.6.0 always creates kernels with chunk 0...

Is there is some dependences? What max it can be? What best?

In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2

thats a bug, it's an int that wasn't mem allocated previously so it's just a random garbage value. I really don't know how these huge values can improve anything, but if its working for you im happy
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  

if you can confirm that its 'working good' every time ( and of course that it finds shares ) i can add it as a def value for rx 8gb cards

Not every time. It's still needs to restarts miner several times. But max speed can be achieved.
About fragments - you mean that way:

{ "id" : 0, "intensity" : 51.1, "worksize" : 8, "threads" : 2, "persistent_memory" : false, "fragments" : 12345678},

And will it work for 1.6.1 ?

yes, exactly that's how you can use it.

Hmmm... Thanks I'll try it. Last question: does it means that with this parameter no matter what chunk size in kernel file?

it creates a new kernel file with the fragment value you defined

[UnclWish]

Hmmm, interesting... I'm take a look in my .srb RX 580 8Gb kernel files. Looks like bigger dmemory_chunk gives better speed for me. Best kernel for now with chunk 1873279048.
I have other variants of chunk:
0
786662967
-466720638
1296339105
126081469
-1540840166

1.5.9 and 1.6.0 always creates kernels with chunk 0...

Is there is some dependences? What max it can be? What best?

In 1.6.1 kernels there is no chunk size. But exists new -DCRYPTONIGHT_FRAGMENTS=2

thats a bug, it's an int that wasn't mem allocated previously so it's just a random garbage value. I really don't know how these huge values can improve anything, but if its working for you im happy
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  

if you can confirm that its 'working good' every time ( and of course that it finds shares ) i can add it as a def value for rx 8gb cards

Not every time. It's still needs to restarts miner several times. But max speed can be achieved.
About fragments - you mean that way:

{ "id" : 0, "intensity" : 51.1, "worksize" : 8, "threads" : 2, "persistent_memory" : false, "fragments" : 12345678},

And will it work for 1.6.1 ?

yes, exactly that's how you can use it.

Hmmm... Thanks I'll try it. Last question: does it means that with this parameter no matter what chunk size in kernel file?

it creates a new kernel file with the fragment value you defined

Thanks! I can build kernel with fragments 1873279048 and 1.6.1 gives the same speed as 1.6.0 with 1.5.8 kernel. Now we can build kernels with any chunk (fragments) size.
But I think you must determine why it's happens. I tried fragments 1396800320 and less step by 43650010, but always not get max speed...
Also tried variants 3, 4, 512, 1024, 4096, 4096000, 87654321, 12345678 and some more. Every time waits about 10 min.

[vmozara]

Although the srbminer was working usper stable with my Vega rigs and gave me amazing nominal hashrate, my adventure with srbminer comes to the end

After a lot of monitoring I figured out that srbminer and cast.xmr give me much less real hashrate than the miner hashrate. I have tried several pools and difference goes as much as 20%. I don't know why, one of the rigs is correct (12KH/s reported by miner and pool) and others vary from 11.5 to even 10KH/s real hashrate. I have 0 invalid shares, everything works beautiful, but my hashes are missing.

Although XMR STAK gives me less hashrate, it is spot on with what the pool reports. I have read few pages ago that older versions of srbminer do not have this issue, but I can't find them online anymore.

After long time, back to where I started, hello XMR STAK, sorry doc, your miner is awesome but difference is too high for me.

[nordmann666]

Although the srbminer was working usper stable with my Vega rigs and gave me amazing nominal hashrate, my adventure with srbminer comes to the end

After a lot of monitoring I figured out that srbminer and cast.xmr give me much less real hashrate than the miner hashrate. I have tried several pools and difference goes as much as 20%. I don't know why, one of the rigs is correct (12KH/s reported by miner and pool) and others vary from 11.5 to even 10KH/s real hashrate. I have 0 invalid shares, everything works beautiful, but my hashes are missing.

Although XMR STAK gives me less hashrate, it is spot on with what the pool reports. I have read few pages ago that older versions of srbminer do not have this issue, but I can't find them online anymore.

After long time, back to where I started, hello XMR STAK, sorry doc, your miner is awesome but difference is too high for me.

SRBMiner-CN-V1-5-0.zip
SRBMiner-CN-V1-5-1.zip
SRBMiner-CN-V1-5-2.zip
SRBMiner-CN-V1-5-3.zip
SRBMiner-CN-V1-5-5.zip
SRBMiner-CN-V1-5-6.zip
SRBMiner-CN-V1-5-8.zip
SRBMiner-CN-V1-5-9.zip
SRBMiner-CN-V1-6-0.zip

doc - if u dont want to share older versions...let me know

[dingdongtobias]

Although the srbminer was working usper stable with my Vega rigs and gave me amazing nominal hashrate, my adventure with srbminer comes to the end

After a lot of monitoring I figured out that srbminer and cast.xmr give me much less real hashrate than the miner hashrate. I have tried several pools and difference goes as much as 20%. I don't know why, one of the rigs is correct (12KH/s reported by miner and pool) and others vary from 11.5 to even 10KH/s real hashrate. I have 0 invalid shares, everything works beautiful, but my hashes are missing.

Although XMR STAK gives me less hashrate, it is spot on with what the pool reports. I have read few pages ago that older versions of srbminer do not have this issue, but I can't find them online anymore.

After long time, back to where I started, hello XMR STAK, sorry doc, your miner is awesome but difference is too high for me.

https://i.imgur.com/f9EzH8T.jpg

This is claymore eth miner, the one that the whole world uses.

Reported : ~595 MHS
Average : ~540 MHS

That's 10% difference. Sometimes is even more.
If you understand what i want to say.

[StarLordRammi]

Although the srbminer was working usper stable with my Vega rigs and gave me amazing nominal hashrate, my adventure with srbminer comes to the end

After a lot of monitoring I figured out that srbminer and cast.xmr give me much less real hashrate than the miner hashrate. I have tried several pools and difference goes as much as 20%. I don't know why, one of the rigs is correct (12KH/s reported by miner and pool) and others vary from 11.5 to even 10KH/s real hashrate. I have 0 invalid shares, everything works beautiful, but my hashes are missing.

Although XMR STAK gives me less hashrate, it is spot on with what the pool reports. I have read few pages ago that older versions of srbminer do not have this issue, but I can't find them online anymore.

After long time, back to where I started, hello XMR STAK, sorry doc, your miner is awesome but difference is too high for me.

ive noted something similar
my miner tells me my hashrate is 4.9Kh/s but on pool ive never reached over 4.4Kh/s

[vmozara]

This is claymore eth miner, the one that the whole world uses.

Reported : ~595 MHS
Average : ~540 MHS

That's 10% difference. Sometimes is even more.
If you understand what i want to say.

Yes, thanks for this

However, this is now what I am talking about

I am talking about that over several weeks period, where xmr stak shows 11.5kh/s for a vega rig and has exact that many hashes counted by the pool, and srb or cast have 12KH/s but 10 or even 20% less hashes counted by the pool. This is data over the days or weeks, not minutes or hours. I did not try claymore, i will just stick what works for me.

nordmann666 thanks for links for older versions. Maybe I will try 1.5 but if I remember correctly, I started using srbminer at about that version. few pages ago some people were already complaining about this, so I guess I am not the only "crazy" one. The hash difference is way to high for me to simply ignore, I prefer to go back to STAK where my rigs have 500 or 300 less hashing power but have 0 doubts about hashing.

[nordmann666]

This is claymore eth miner, the one that the whole world uses.

Reported : ~595 MHS
Average : ~540 MHS

That's 10% difference. Sometimes is even more.
If you understand what i want to say.

Yes, thanks for this

However, this is now what I am talking about

I am talking about that over several weeks period, where xmr stak shows 11.5kh/s for a vega rig and has exact that many hashes counted by the pool, and srb or cast have 12KH/s but 10 or even 20% less hashes counted by the pool. This is data over the days or weeks, not minutes or hours. I did not try claymore, i will just stick what works for me.

nordmann666 thanks for links for older versions. Maybe I will try 1.5 but if I remember correctly, I started using srbminer at about that version. few pages ago some people were already complaining about this, so I guess I am not the only "crazy" one. The hash difference is way to high for me to simply ignore, I prefer to go back to STAK where my rigs have 500 or 300 less hashing power but have 0 doubts about hashing.

i asked here and elsewhere but no one answered...your problem is 10%
i got waves an every pool....hashrate from 2000-5500hs up and down and up and down...with EVERY miner
BUT...average hash rate is 3,9 = what SRB shows me

so i dont care about reported hasrates - i want a stable miner without issues and SRB is stable (most time)

only thing i´m not happy about - more and more settings i dont know to handle (fragments?!!?) - SRB was easy to use...but gets more and more complicated (in my opinion)

[Mike Leone]

Hello, does not display the temperature and speed of the fan. Video cards R9 370 series ...

[smparo]

Hello, does not display the temperature and speed of the fan. Video cards R9 370 series ...

Try to change adl_type parameter, default is 1, try 2.
Put it on "gpu_conf" to get something like that (for intensity, worksize e threads use your stable config, this is only for example):

"gpu_conf" :
[
   { "id" : 0, "intensity" : 50, "worksize" : 4, "threads" : 1, "adl_type": 2},
]


"adl_type" : 1 or 2 , 1 - USE OVERDRIVEN , 2 - USE OVERDRIVE 5. Default is 1 if not set. Option 2 (Overdrive 5) is suitable for older cards