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

[livada]

1.8.8.2 driver

all card use GPU and MEM 900mv
3/vega56(64bios)+1vega64LE - All samsung mem.

all work -v7 and heavy/tube haven
must disable/enable and first start with 60int 1 min and start again with 56 int.

i try v7- stelite - tube- loki - haven - fast(msr)- aloy and arto

all give better HR

TUBE
https://image.prntscr.com/image/Jp-k48THT9yIn7yFKRhgTg.jpg
Heavy-LOKI
https://image.prntscr.com/image/bOaOOgeiSc6jxyvPQo8Ajg.jpg
FAST-MSR
https://image.prntscr.com/image/Ib70HEHXSLm23-6hMBuGcw.jpg
V7-graft and STL Arto give a little less
https://image.prntscr.com/image/U4hCUapySoC5sb7e9V4o4w.jpg
Alooy give 4300Hr

You tried v.1.6.4 that compiles .srb files on 18.8.2 ?
Or used .srb files compiled on older drivers on 18.8.2 ?

srbmienr not work with new driver and old .srb file.(some algo block miner - other not share with pool)
i del cache folder and 1.6.4 compile new .srb file with 18.8.2 driver.

Other rig with  nitro vega card(hynix) not work with heavy-tube algo. why? i dont now. i use identical  miner-driver and try all but haven-tube-heavy not up HBC mem.

[OlegZ]

I have one problem with miner. I am using latest version 1.6.7 with and 18.4.1.Mining rig is 4 x Vega 56 (flashed with Vega 64 bios).

Problem is that I get same error 3 time today:
Could not contact htt://srbminer.com for a long time!

http://mail.dir.bg/~proba0/problem_conection.jpg

I had the same issue today.
version 1.6.6

[Diuscom]

RX 470 4 Gb on heavy only 750-800 h/s?

[OlegZ]

version 1.6.6

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

on version 1.6.5 there are no problems

[doktor83]

on version 1.6.5 there are no problems

Neither on 1.6.6. This was just yesterday.

[SpceGhst]

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 ?
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]

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 ?
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 ?

[SpceGhst]

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 ?
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]

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 ?
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

[SpceGhst]

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 ?
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

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]

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 ?
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

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?

[SpceGhst]

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]

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.

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.

[symplink]

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
@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]

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

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.

[puntodecontrol]

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

[doktor83]

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

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

[symplink]

"

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]

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?

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.

[symplink]

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 , 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.