Bitcoin Forum
January 22, 2022, 01:52:45 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 [150] 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 ... 365 »
  Print  
Author Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching  (Read 235792 times)
UnclWish
Sr. Member
****
Offline Offline

Activity: 1470
Merit: 253


View Profile
June 24, 2018, 01:25:37 AM
 #2981

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
1642859565
Hero Member
*
Offline Offline

Posts: 1642859565

View Profile Personal Message (Offline)

Ignore
1642859565
Reply with quote  #2

1642859565
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1642859565
Hero Member
*
Offline Offline

Posts: 1642859565

View Profile Personal Message (Offline)

Ignore
1642859565
Reply with quote  #2

1642859565
Report to moderator
1642859565
Hero Member
*
Offline Offline

Posts: 1642859565

View Profile Personal Message (Offline)

Ignore
1642859565
Reply with quote  #2

1642859565
Report to moderator
1642859565
Hero Member
*
Offline Offline

Posts: 1642859565

View Profile Personal Message (Offline)

Ignore
1642859565
Reply with quote  #2

1642859565
Report to moderator
doktor83
Hero Member
*****
Offline Offline

Activity: 1890
Merit: 621


View Profile WWW
June 24, 2018, 08:16:45 AM
Last edit: June 24, 2018, 08:38:27 AM by doktor83
 #2982

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 Smiley
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  Tongue

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

SRBMiner-MULTI thread - HERE
http://www.srbminer.com
lncm
Member
**
Offline Offline

Activity: 384
Merit: 13


View Profile
June 24, 2018, 09:28:07 AM
 #2983

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
Sr. Member
****
Offline Offline

Activity: 1470
Merit: 253


View Profile
June 24, 2018, 10:07:03 AM
 #2984

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 Smiley
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  Tongue

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
Hero Member
*****
Offline Offline

Activity: 1890
Merit: 621


View Profile WWW
June 24, 2018, 10:12:26 AM
 #2985

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 Smiley
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  Tongue

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.

SRBMiner-MULTI thread - HERE
http://www.srbminer.com
UnclWish
Sr. Member
****
Offline Offline

Activity: 1470
Merit: 253


View Profile
June 24, 2018, 11:11:08 AM
 #2986

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 Smiley
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  Tongue

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
Hero Member
*****
Offline Offline

Activity: 1890
Merit: 621


View Profile WWW
June 24, 2018, 11:12:40 AM
 #2987

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 Smiley
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  Tongue

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

SRBMiner-MULTI thread - HERE
http://www.srbminer.com
UnclWish
Sr. Member
****
Offline Offline

Activity: 1470
Merit: 253


View Profile
June 24, 2018, 02:04:31 PM
 #2988

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 Smiley
you can experiment by adding "fragments" : your magic number in gpu_conf. This option is not 'public', cause im experimenting with it  Tongue

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
Member
**
Offline Offline

Activity: 190
Merit: 59


View Profile
June 24, 2018, 02:33:23 PM
 #2989

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
Member
**
Offline Offline

Activity: 345
Merit: 16


View Profile
June 24, 2018, 03:03:23 PM
 #2990

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
Newbie
*
Offline Offline

Activity: 156
Merit: 0


View Profile
June 24, 2018, 03:54:57 PM
 #2991

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
Newbie
*
Offline Offline

Activity: 38
Merit: 0


View Profile
June 24, 2018, 04:33:24 PM
 #2992

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
Member
**
Offline Offline

Activity: 190
Merit: 59


View Profile
June 24, 2018, 04:57:01 PM
 #2993



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
Member
**
Offline Offline

Activity: 345
Merit: 16


View Profile
June 24, 2018, 05:26:12 PM
 #2994



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
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
June 24, 2018, 05:44:52 PM
 #2995

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

Activity: 27
Merit: 0


View Profile
June 24, 2018, 06:32:44 PM
 #2996

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
doktor83
Hero Member
*****
Offline Offline

Activity: 1890
Merit: 621


View Profile WWW
June 24, 2018, 06:34:21 PM
 #2997



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)

There will always be differences in miner speed and what pool shows. Stale shares, hw errors, etc etc, lots of factors.
You said on one of your rigs is OK, pool showing approximately what miner shows. And you called that strange Smiley
I call strange those 20%, because that IS really much. Well, i'm not trying to convince anybody, you use what best works for you.

nordmann666, you don't have to worry about every setting and parameter, you probably don't need any of those.
It's still easy to use it, all you need is set intensity and turn on double_threads. Smiley

SRBMiner-MULTI thread - HERE
http://www.srbminer.com
Seruun91
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
June 24, 2018, 07:01:12 PM
 #2998

Good evenening guys,

i hope someone is able to help me.
Since 4 days the miner isn't showing me any hashrate and keeps crashing after 5 Minuts.

config.txt
{
"cryptonight_type" : "alloy",
"intensity" : 0,
"double_threads" : true
}

https://thumb.ibb.co/fmEjaT/SRBMiner_1_6_1_Fatal_Error2.png

Does anyone has an idea why that happens?
vmozara
Member
**
Offline Offline

Activity: 190
Merit: 59


View Profile
June 24, 2018, 10:08:26 PM
 #2999

If anybody actually read what I wrote you woukd see the problem is much deeper than normal hashrate fluctuations. And I am not the only one. How comes a miner with 12KHs (srbminer and cast) will have less hashes on the pool after 1 week, than the miner with 11.5KHs? (Stak)
Mashy81
Jr. Member
*
Offline Offline

Activity: 226
Merit: 1


View Profile
June 25, 2018, 12:42:05 AM
 #3000

If anybody actually read what I wrote you woukd see the problem is much deeper than normal hashrate fluctuations. And I am not the only one. How comes a miner with 12KHs (srbminer and cast) will have less hashes on the pool after 1 week, than the miner with 11.5KHs? (Stak)


It depends greatly on the pool and the day. Somedays I average above for the 24hrs and some days under.
Nanopool is far more stable and always the same or higher hashrate 24hr average.
Hashvault ok and cryptoknight.cc pool always less.
There are soo many factors. Look at the average over several days
Pages: « 1 ... 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 [150] 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 ... 365 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!