Bitcoin Forum
January 31, 2023, 09:13:17 PM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 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 ... 364 »
  Print  
Author Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching  (Read 236659 times)
OlegZ
Newbie
*
Offline Offline

Activity: 2
Merit: 0


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

version 1.6.6

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

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

Posts: 1675199597

View Profile Personal Message (Offline)

Ignore
1675199597
Reply with quote  #2

1675199597
Report to moderator
1675199597
Hero Member
*
Offline Offline

Posts: 1675199597

View Profile Personal Message (Offline)

Ignore
1675199597
Reply with quote  #2

1675199597
Report to moderator
1675199597
Hero Member
*
Offline Offline

Posts: 1675199597

View Profile Personal Message (Offline)

Ignore
1675199597
Reply with quote  #2

1675199597
Report to moderator
The network tries to produce one block per 10 minutes. It does this by automatically adjusting how difficult it is to produce blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1675199597
Hero Member
*
Offline Offline

Posts: 1675199597

View Profile Personal Message (Offline)

Ignore
1675199597
Reply with quote  #2

1675199597
Report to moderator
doktor83 (OP)
Hero Member
*****
Offline Offline

Activity: 2184
Merit: 625


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

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
 #4083

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

Activity: 2184
Merit: 625


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

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
 #4085

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

Activity: 2184
Merit: 625


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

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
 #4087

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

Activity: 2184
Merit: 625


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

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
 #4089

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

Activity: 2184
Merit: 625


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

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: 30
Merit: 0


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

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

Activity: 2184
Merit: 625


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

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
 #4093

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

Activity: 2184
Merit: 625


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

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: 30
Merit: 0


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

"
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 (OP)
Hero Member
*****
Offline Offline

Activity: 2184
Merit: 625


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

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: 30
Merit: 0


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

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

Activity: 2184
Merit: 625


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

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: 30
Merit: 0


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

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

Activity: 18
Merit: 0


View Profile
September 04, 2018, 01:51:56 PM
 #4100

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

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



If i put manually (--logfile log.txt) works, but if i let the star file creates it, it doesnt work.

This its my start.bat file

setx GPU_MAX_HEAP_SIZE 100
setx GPU_MAX_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_MAX_SINGLE_ALLOC_PERCENT 100
@echo off
cd %~dp0

cls
set LOGTIME=%date:~10,4%_%date:~4,2%_%date:~7,2%_%time:~0,2%_%time:~3,2%
set LOGTIME=%LOGTIME: =%
set LOGTIME=%LOGTIME:,=.%.txt

SRBMiner-CN.exe --config Config\config.txt --pools pools.txt --logfile %LOGTIME%
Pages: « 1 ... 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 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 ... 364 »
  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!