Bitcoin Forum
October 24, 2021, 03:43:23 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 201 202 203 204 205 [206] 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 ... 366 »
  Print  
Author Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching  (Read 235735 times)
Diuscom
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
September 03, 2018, 08:34:17 AM
 #4101

RX 470 4 Gb on heavy only 750-800 h/s?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
OlegZ
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
September 03, 2018, 09:43:01 AM
 #4102

version 1.6.6

https://s15.postimg.cc/5z6pefkjv/err.jpg

on version 1.6.5 there are no problems
doktor83
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 614


View Profile WWW
September 03, 2018, 09:59:17 AM
 #4103

on version 1.6.5 there are no problems

Neither on 1.6.6. This was just yesterday.

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

Activity: 270
Merit: 4


View Profile
September 03, 2018, 12:21:54 PM
 #4104

Hey Dok, love your miner but wanted to pass this along...

Been mining XTL with 8 card 480/580 rig using amd 18.6.1.  Tried new 1.6.7 version and was getting around 50hs less per card than on 1.6.4.  Might not sound like much, but x 8 cards adds up.  Changed back to older version...


Have you tried with the bundled binary kernel, or you let 1.6.7 miner compile the kernel, or you maybe used an older kernel from a previous miner version ? Smiley
I have a 6x580 8g rig and tested 1.6.7 before uploading it, i had the same hash as before on w10, 18.6.1.

Foing to check it out though.


I’m assuming it was bundled kernel because on first run, all miner said was loading kernel... didn’t get a compiling kernel message.  SRB 1.6.7 was installed in a completely separate folder than 1.6.4.
doktor83
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 614


View Profile WWW
September 03, 2018, 12:33:12 PM
 #4105

Hey Dok, love your miner but wanted to pass this along...

Been mining XTL with 8 card 480/580 rig using amd 18.6.1.  Tried new 1.6.7 version and was getting around 50hs less per card than on 1.6.4.  Might not sound like much, but x 8 cards adds up.  Changed back to older version...


Have you tried with the bundled binary kernel, or you let 1.6.7 miner compile the kernel, or you maybe used an older kernel from a previous miner version ? Smiley
I have a 6x580 8g rig and tested 1.6.7 before uploading it, i had the same hash as before on w10, 18.6.1.

Foing to check it out though.


I’m assuming it was bundled kernel because on first run, all miner said was loading kernel... didn’t get a compiling kernel message.  SRB 1.6.7 was installed in a completely separate folder than 1.6.4.


Did you use the same settings in 1.6.7 as in 1.6.4? Same intensity, worksize ?

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

Activity: 270
Merit: 4


View Profile
September 03, 2018, 01:22:13 PM
 #4106

Hey Dok, love your miner but wanted to pass this along...

Been mining XTL with 8 card 480/580 rig using amd 18.6.1.  Tried new 1.6.7 version and was getting around 50hs less per card than on 1.6.4.  Might not sound like much, but x 8 cards adds up.  Changed back to older version...


Have you tried with the bundled binary kernel, or you let 1.6.7 miner compile the kernel, or you maybe used an older kernel from a previous miner version ? Smiley
I have a 6x580 8g rig and tested 1.6.7 before uploading it, i had the same hash as before on w10, 18.6.1.

Foing to check it out though.


I’m assuming it was bundled kernel because on first run, all miner said was loading kernel... didn’t get a compiling kernel message.  SRB 1.6.7 was installed in a completely separate folder than 1.6.4.


Did you use the same settings in 1.6.7 as in 1.6.4? Same intensity, worksize ?

Same card settings but not sure in miner as I’ve always used auto intensity 0 and never messed with worksize.
doktor83
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 614


View Profile WWW
September 03, 2018, 01:34:00 PM
 #4107

Hey Dok, love your miner but wanted to pass this along...

Been mining XTL with 8 card 480/580 rig using amd 18.6.1.  Tried new 1.6.7 version and was getting around 50hs less per card than on 1.6.4.  Might not sound like much, but x 8 cards adds up.  Changed back to older version...


Have you tried with the bundled binary kernel, or you let 1.6.7 miner compile the kernel, or you maybe used an older kernel from a previous miner version ? Smiley
I have a 6x580 8g rig and tested 1.6.7 before uploading it, i had the same hash as before on w10, 18.6.1.

Foing to check it out though.


I’m assuming it was bundled kernel because on first run, all miner said was loading kernel... didn’t get a compiling kernel message.  SRB 1.6.7 was installed in a completely separate folder than 1.6.4.


Did you use the same settings in 1.6.7 as in 1.6.4? Same intensity, worksize ?

Same card settings but not sure in miner as I’ve always used auto intensity 0 and never messed with worksize.

It may be that the auto setting in 1.6.7 gave a lower value for intensity as in 1.6.4. It would be really good if you could test both miners with same intensity, for example 55 (580 can handle higher intensity, but for this test 55 should be ok).
And if still 1.6.4 wins by 50hs/card then i must re-work stuff, but if hash is same in both versions, then i don't have to chase ghosts Smiley

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

Activity: 270
Merit: 4


View Profile
September 03, 2018, 02:17:31 PM
 #4108

Hey Dok, love your miner but wanted to pass this along...

Been mining XTL with 8 card 480/580 rig using amd 18.6.1.  Tried new 1.6.7 version and was getting around 50hs less per card than on 1.6.4.  Might not sound like much, but x 8 cards adds up.  Changed back to older version...


Have you tried with the bundled binary kernel, or you let 1.6.7 miner compile the kernel, or you maybe used an older kernel from a previous miner version ? Smiley
I have a 6x580 8g rig and tested 1.6.7 before uploading it, i had the same hash as before on w10, 18.6.1.

Foing to check it out though.


I’m assuming it was bundled kernel because on first run, all miner said was loading kernel... didn’t get a compiling kernel message.  SRB 1.6.7 was installed in a completely separate folder than 1.6.4.


Did you use the same settings in 1.6.7 as in 1.6.4? Same intensity, worksize ?

Same card settings but not sure in miner as I’ve always used auto intensity 0 and never messed with worksize.

It may be that the auto setting in 1.6.7 gave a lower value for intensity as in 1.6.4. It would be really good if you could test both miners with same intensity, for example 55 (580 can handle higher intensity, but for this test 55 should be ok).
And if still 1.6.4 wins by 50hs/card then i must re-work stuff, but if hash is same in both versions, then i don't have to chase ghosts Smiley

I believe you are correct and it is a “me” problem and not a “you” problem... 😁
Auto intensity for 1.6.4 is 57 and 1.6.7 is 55, but a weird thing happened.  I was running .4 and immediately after quitting and starting .7, without a reboot, they have the almost the same hashrate.

Thanks for your support and work you do!

doktor83
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 614


View Profile WWW
September 03, 2018, 02:21:14 PM
 #4109

Hey Dok, love your miner but wanted to pass this along...

Been mining XTL with 8 card 480/580 rig using amd 18.6.1.  Tried new 1.6.7 version and was getting around 50hs less per card than on 1.6.4.  Might not sound like much, but x 8 cards adds up.  Changed back to older version...


Have you tried with the bundled binary kernel, or you let 1.6.7 miner compile the kernel, or you maybe used an older kernel from a previous miner version ? Smiley
I have a 6x580 8g rig and tested 1.6.7 before uploading it, i had the same hash as before on w10, 18.6.1.

Foing to check it out though.


I’m assuming it was bundled kernel because on first run, all miner said was loading kernel... didn’t get a compiling kernel message.  SRB 1.6.7 was installed in a completely separate folder than 1.6.4.


Did you use the same settings in 1.6.7 as in 1.6.4? Same intensity, worksize ?

Same card settings but not sure in miner as I’ve always used auto intensity 0 and never messed with worksize.

It may be that the auto setting in 1.6.7 gave a lower value for intensity as in 1.6.4. It would be really good if you could test both miners with same intensity, for example 55 (580 can handle higher intensity, but for this test 55 should be ok).
And if still 1.6.4 wins by 50hs/card then i must re-work stuff, but if hash is same in both versions, then i don't have to chase ghosts Smiley

I believe you are correct and it is a “me” problem and not a “you” problem... 😁
Auto intensity for 1.6.4 is 57 and 1.6.7 is 55, but a weird thing happened.  I was running .4 and immediately after quitting and starting .7, without a reboot, they have the almost the same hashrate.

Thanks for your support and work you do!



Nah im not sure its a "you" thing, i am trying to optimize for every card and sometimes an optim good for one card is not so good for another . Could you please test the same intensities as i wrote before?

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

Activity: 270
Merit: 4


View Profile
September 03, 2018, 02:31:54 PM
 #4110

Nah im not sure its a "you" thing, i am trying to optimize for every card and sometimes an optim good for one card is not so good for another . Could you please test the same intensities as i wrote before?

Sorry I forgot to add... yes, I tested both versions at 55 and hash is roughly the same.

doktor83
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 614


View Profile WWW
September 04, 2018, 04:02:37 AM
 #4111

I added your URL to hosts file per your PM directions, it ran for almost 24 hours before finally shutting down.  This is the end of the log file.


Quote
Pool accepted result 0x00000462
[2018-09-03 17:17:36] miner_result: Sending user result to pool
[2018-09-03 17:17:36] json_send: {"id":1,"jsonrpc": "2.0","method":"submit","params":{"id":"558725999482127","job_id":"113991396556743","nonce":"aa205755","result":"71f011861caa7d3f32d6333c34bb68f775d4e681d006eb087b0c7007e2290000"}}
[2018-09-03 17:17:36] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}}
[2018-09-03 17:17:36] miner_result: Pool accepted result 0x000029E2
[2018-09-03 17:17:56] devfee: Could not connect to a devfee pool for a long time!
[2018-09-03 17:17:56] devfee: Tried few pools, but none of them could be connected, so you are probably blocking them.
[2018-09-03 17:17:56] devfee: Don't be a dick.
[2018-09-03 17:17:56] Stopping miner process

So here is your log telling me, "Don't be a dick."


These are 2 separate things :

1. If miner can't contact srbminer.com for a long time (DFP online load: FAIL)
2. If miner can't mine devfee for a long time (devfee mining is on normal pools like nanopool, etc.)

So something is blocking different connection attempts there, not just srbminer.com but also various devfee pools.

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

Activity: 15
Merit: 0


View Profile
September 04, 2018, 07:21:23 AM
Last edit: September 04, 2018, 07:38:35 AM by symplink
 #4112

Hello
Wanted to be sure:
"reboot_script" : "reboot-windows.bat" this is the correct syntax or "reboot_script" : reboot-windows.bat or something else (like path to file) ?
Btw , @JuanHungLo those restarts w/o reason happens on starting mining again after devfee mining and happens because of too much memory (P3) on one of the cards. Try to low a little - for me worked. For allowing access to devfee you could establish outbound rule, but if you ask me, you already know this Smiley
@doktor83 - could you try to mine more minutes , but at at least 4-6 hours , not 2 like now, some of us are on Score pools and you are ruining our work every 2 hours. Anyway you mine after few minutes from start, so would be the same for you.Also, not the best ideea to hide the devfee mining, was more fair to see it for how long by our eyes.
doktor83
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 614


View Profile WWW
September 04, 2018, 07:23:25 AM
Last edit: September 04, 2018, 07:48:27 AM by doktor83
 #4113

Hello
I want to be sure:
"reboot_script" : "reboot-windows.bat" this is the correct syntax or "reboot_script" : reboot-windows.bat or something else (like path to file) ?


Put the parameter "reboot_script" : "scriptname.bat" in the config file, or just use the .bat i provided (reboot-windows.bat)
If you don't put the " it will complain Smiley

edit:

Code:
those restarts w/o reason happens on starting mining again after devfee mining

Totally wrong. Devfee is always same algo as users, so HW doesn't need different settings (voltage etc). So it cant produce restarts.
I don't know what are score pools, and how am i 'ruining' your work.
Miner is not disconnecting from user pool when switching to devfee mining, there are 2 open connections then, after devfee mining is done, job is switched back to the already active user pool connection.

I could set that your eyes see devfee mining of 5 seconds but in reality it mines for 30 minutes. So that is display only. You should look at the hashrate you get at your pool, it should be around "hashrate from miner - 2-3-4%" , or even more if you have compute errors.


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

Activity: 18
Merit: 0


View Profile
September 04, 2018, 07:41:49 AM
 #4114

It doesnt save the log file.... any ideas?
doktor83
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 614


View Profile WWW
September 04, 2018, 07:49:21 AM
 #4115

It doesnt save the log file.... any ideas?

Maybe there are no write permissions for the miner to work in its own folder?

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

Activity: 15
Merit: 0


View Profile
September 04, 2018, 08:24:57 AM
 #4116

"
Code:
those restarts w/o reason happens on starting mining again after devfee mining

Totally wrong. Devfee is always same algo as users, so HW doesn't need different settings (voltage etc). So it cant produce restarts."

It is happening at switch from devfee to normal , was looking into issue for many days on 1.6.5. Anyway, related to P3 overclocked too much, as I said. Enough that one is overclocked too much, the miner will close w/o reason at switch.Now at switch (with lower P3) the hashrate is only droping. If you have better idea about that stop w/o any logs or reason , let me know.


"I don't know what are score pools, and how am i 'ruining' your work.
Miner is not disconnecting from user pool when switching to devfee mining, there are 2 open connections then, after devfee mining is done, job is switched back to the already active user pool connection."
On score pools you get shares , but they are growing while you mine, if before reward you drop your mining, it was for nothing all the work (or better say will not worth much). It's sort of like prop, except instead of treating all shares equally, it gives more weight to later shares in the round (the drop-off is such that shares half an hour later are worth twice as much as shares half an hour before) The idea is to keep the miner as stable as possible, to get right reward. Switching for few minutes to another work will drop your shares.
The suggestion was to mine more minutes at bigger times, or maybe to give us this option. As i said , if I choose this, it is better for you, at every restart you will be mining more. If possible.

"I could set that your eyes see devfee mining of 5 seconds but in reality it mines for 30 minutes. So that is display only. You should look at the hashrate you get at your pool, it should be around "hashrate from miner - 2-3-4%" , or even more if you have compute errors."
And i could log your connection and see how much it stays connected to that pool , to not mention what you said to check my pool. The idea was to be open and fair, for this it was better 1.6.5. Don't get me wrong, but as long as I am fair and don't block your devfee, even there are dozens ways, you should be same.


[/quote]
doktor83
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 614


View Profile WWW
September 04, 2018, 08:51:07 AM
 #4117

Switching for few minutes to another work will drop your shares.
The suggestion was to mine more minutes at bigger times, or maybe to give us this option.

Now i understand, but devfee is never mined for minutes, max time per devfee is less than a minute.
But i like your idea so i will implement it, a simple parameter in the bat will do it.
How often would you like the devfee to be mined?


Quote
And i could log your connection and see how much it stays connected to that pool , to not mention what you said to check my pool. The idea was to be open and fair, for this it was better 1.6.5. Don't get me wrong, but as long as I am fair and don't block your devfee, even there are dozens ways, you should be same.

You can wireshark the connection, and see for yourself if you don't trust me when i say it's ~0.85%. There are a few combinations of devfee periods, randomly chosen on every miner start, but always ~0.85% / 24h . I had to go this route because of the guys who 'know that devfee is mined every 2 hours' so they simply kill/start the process.

Just because it's not shown WHEN EXACTLY is the devfee mined, it doesn't mean it is more than the advertised ~0.85%. That is why i mentioned the pool hashrate, as long as you have the hashrate you should have on the pool side (because this is only what matters on payout), you know the miner is not stealing anything.


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

Activity: 15
Merit: 0


View Profile
September 04, 2018, 09:05:37 AM
 #4118

Smiley I am glad you understand me.
For me 6-12 hours will be perfect, but i suggest to put some parameters , like 4 , 6, 8, 12 hours or 2,4,6,8 devfee mining times/24 hours. Of course, if my rig restarts , will be your bigger fee Smiley , but if not , I prefer you to devfee mine for 5 minutes 2 times a day then 1 minutes 10 times a day

About devfee mining, now I understand. I did not checked the percentile, as I consider this way of working more like a gentleman's agreement. I will never block your fee, as it permits you to keep working on improving. I thought you are hiding it for other reasons, now I get the idea why. I think you are right.

Cannot wait to have this time parameter feature.Even if you keep the time of mining hidden, basically will be 2-4 times every 24 hours, which looks great for me.
doktor83
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 614


View Profile WWW
September 04, 2018, 09:28:36 AM
 #4119

Smiley I am glad you understand me.
For me 6-12 hours will be perfect, but i suggest to put some parameters , like 4 , 6, 8, 12 hours or 2,4,6,8 devfee mining times/24 hours. Of course, if my rig restarts , will be your bigger fee Smiley , but if not , I prefer you to devfee mine for 5 minutes 2 times a day then 1 minutes 10 times a day

About devfee mining, now I understand. I did not checked the percentile, as I consider this way of working more like a gentleman's agreement. I will never block your fee, as it permits you to keep working on improving. I thought you are hiding it for other reasons, now I get the idea why. I think you are right.

Cannot wait to have this time parameter feature.Even if you keep the time of mining hidden, basically will be 2-4 times every 24 hours, which looks great for me.


I won't make the user choose how often (4 , 6, 8, 12h), because .. you already know why ('the kill/start thing').
But i will think out something Smiley

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

Activity: 15
Merit: 0


View Profile
September 04, 2018, 10:20:29 AM
 #4120

Then put how many/24 hours and then do your algo for devfee.
Will not be a problem if you mine at 2  times at  1 hour interval even if i set 2/day , the rest of the day will be uninterrupted.
Just to not have reboots on my rigs, then you will get a lot of devfee Smiley , but this is my work to do.
Pages: « 1 ... 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 201 202 203 204 205 [206] 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 ... 366 »
  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!