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

doktor83

hero member

Activity: 2548

Merit: 626

Quote from: UnclWish on June 24, 2018, 06:11:08 AM

Quote from: doktor83 on June 24, 2018, 05:12:26 AM

Quote from: UnclWish on June 24, 2018, 05:07:03 AM

Quote from: doktor83 on June 24, 2018, 03:16:45 AM

Quote from: UnclWish on June 23, 2018, 08:25:37 PM

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

UnclWish

sr. member

Activity: 1484

Merit: 253

Quote from: doktor83 on June 24, 2018, 05:12:26 AM

Quote from: UnclWish on June 24, 2018, 05:07:03 AM

Quote from: doktor83 on June 24, 2018, 03:16:45 AM

Quote from: UnclWish on June 23, 2018, 08:25:37 PM

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

Activity: 2548

Merit: 626

Quote from: UnclWish on June 24, 2018, 05:07:03 AM

Quote from: doktor83 on June 24, 2018, 03:16:45 AM

Quote from: UnclWish on June 23, 2018, 08:25:37 PM

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

UnclWish

sr. member

Activity: 1484

Merit: 253

Quote from: doktor83 on June 24, 2018, 03:16:45 AM

Quote from: UnclWish on June 23, 2018, 08:25:37 PM

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

lncm

member

Activity: 388

Merit: 13

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.

doktor83

hero member

Activity: 2548

Merit: 626

Quote from: UnclWish on June 23, 2018, 08:25:37 PM

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

UnclWish

sr. member

Activity: 1484

Merit: 253

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

hero member

Activity: 2548

Merit: 626

oh, haxors .. Grin

well, ok.

livada

newbie

Activity: 417

Merit: 0

Quote from: UnclWish on June 23, 2018, 02:11:25 PM

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.

UnclWish

sr. member

Activity: 1484

Merit: 253

Quote from: doktor83 on June 23, 2018, 03:35:54 PM

Quote from: UnclWish on June 23, 2018, 02:11:25 PM

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.

doktor83

hero member

Activity: 2548

Merit: 626

Quote from: UnclWish on June 23, 2018, 02:11:25 PM

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.

doktor83

hero member

Activity: 2548

Merit: 626

Quote from: Kgonla on June 23, 2018, 10:54:10 AM

Quote from: dingdongtobias on June 23, 2018, 01:30:17 AM

Quote from: hesido on June 22, 2018, 04:49:17 PM

Quote from: Kgonla on June 22, 2018, 08:23:56 AM

Same problem under Server 2008 R2:

[2018-06-22 15:05:58] CryptonightV7 mode enabled
[2018-06-22 15:06:40] DevFee pools loaded
[2018-06-22 15:06:40] DevFee pool SET
[2018-06-22 15:06:40] DevFee address SET

42 sec. to load devfee pools, not firewalled.

@doktor: Maybe you can make this call async? Until then, hardcoded fallback in the first run and "last known good" dev fee pool would be used, basically, you cache the good dev fee pools as soon as you receive them, and use that until the new one is set.

It is working fine on win7 & win8 & win10. Why do you use server edition anyway?

Because I only have one PC, others are laptops, I use as server & I don't want to use W10 because his spying policy.

I see I'm the only one with this issue, I'm using v1.5.8 without any problem, all my problems started when doktor added the pools loading through his web site.
I'm just reporting this issue, if doktor can fix easily & he wants to do it is welcome for me, if not, I understand if he don't want to spend his time with this.

Most of the time I use Awesome Miner, it often switches from one coin to another so the 42 seconds wait are not good.

Finally I'm curious why it takes exactly 42 seconds waiting. Something blocking or waiting that time for some reason?

By the way:
What happens if his website goes down or have any connection problem? The program takes several minutes to start or even do not start?

i am still sure there is something restricting website access in your server 2008 edition, but i will change the code to do the check async (as hesido suggested), that will probably help here.

Also if website goes down or connection problems, miner will use built in pools, but it will ocassionaly try to connect to get a list of pools while it is mining.

doktor83

hero member

Activity: 2548

Merit: 626

Quote from: UAGet on June 23, 2018, 02:13:34 PM

Hi!

V1.6.1 is not worked with stellitev4...
From logfile

Code:

[2018-06-23 22:03:12] Miner version: 1.6.1
[2018-06-23 22:03:13] AMD Platform ID: 0
[2018-06-23 22:03:13] AMD platform FOUND
[2018-06-23 22:03:13] Found 5 AMD devices
[2018-06-23 22:03:13] GPU0: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 8]
[2018-06-23 22:03:13] GPU1: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 2]
[2018-06-23 22:03:13] GPU2: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 7]
[2018-06-23 22:03:13] GPU3: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 10]
[2018-06-23 22:03:13] GPU4: Radeon RX 560 Series [Baffin] [4096 MB][Intensity 51.0][W: 8][T: 2][K: 1][BUS: 9]
[2018-06-23 22:03:13] ADL is enabled
[2018-06-23 22:03:13] Cryptonight StelliteV4 mode enabled
[2018-06-23 22:03:14] DevFee pools loaded
[2018-06-23 22:03:14] DevFee pool SET
[2018-06-23 22:03:14] DevFee address SET
[2018-06-23 22:03:14] Starting init of mining threads
[2018-06-23 22:03:15] Loading kernel for DEVICE BUS ID 8 ...
[2018-06-23 22:03:16] Loading kernel for DEVICE BUS ID 8 ...
[2018-06-23 22:03:18] Loading kernel for DEVICE BUS ID 2 ...
[2018-06-23 22:03:19] Loading kernel for DEVICE BUS ID 2 ...
[2018-06-23 22:03:21] Loading kernel for DEVICE BUS ID 7 ...
[2018-06-23 22:03:22] Loading kernel for DEVICE BUS ID 7 ...
[2018-06-23 22:03:24] Loading kernel for DEVICE BUS ID 10 ...
[2018-06-23 22:03:25] Loading kernel for DEVICE BUS ID 10 ...
[2018-06-23 22:03:27] Loading kernel for DEVICE BUS ID 9 ...
[2018-06-23 22:03:28] Loading kernel for DEVICE BUS ID 9 ...
[2018-06-23 22:03:29] ADL initialised successfully!
[2018-06-23 22:03:29] Finished init of mining threads
[2018-06-23 22:03:29] Main pool: communitypool.stellite.cash:6600
[2018-06-23 22:03:29] Gpu watchdog started
[2018-06-23 22:03:29] API enabled on port 21555
[2018-06-23 22:03:32] socket_ssl: SSL/TLS fingerprint: SHA256:d5VI8Z7Qj7fBSxQCFojNbCTgvXODtG3dEthetRj8oK0=
[2018-06-23 22:03:32] json_send: {"method":"login","params":{"login":"SEiStP7SMy1bvjkWc9dd1t2v1Et5q2DrmaqLqFTQQ9H7JKdZuATcPHUbUL3bRjxzxTDYitHsAPqF8EeCLw3bW8ARe8rYH6wukKR34YEPJjXv6","pass":"farm1","agent":"SRBMiner Cryptonight AMD GPU miner/1.6.1","rigid":""},"id":1}
[2018-06-23 22:03:32] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"id":"921c13c8-755c-46af-b17c-534c49b45fa3","job":{"blob":"0404f9b2bad9051e6d3c3d2c7e14df19292534ec31592f5d95685db5c0473a74fbb55395989c7400000000955923173e8b74a52e5a411bcd8bb3770457544294750a343ee7af2bcc4ea98501","job_id":"D10B0EuZ60In3VTKq/BHjY+hxByE","target":"c5a70000","id":"921c13c8-755c-46af-b17c-534c49b45fa3"},"status":"OK"}}
[2018-06-23 22:03:32] Connected to communitypool.stellite.cash:6600
[2018-06-23 22:03:32] sock_ready: User logged in
[2018-06-23 22:03:32] pool_have_job: Pool sent a new job (ID: D10B0EuZ60In3VTKq/BHjY+hxByE)
[2018-06-23 22:03:48] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"040493b3bad9054ebbad8c8c18b96e3075ed20d588279e8d0a096420d97fedf61fadf1e00ca695000000002a5f9a47d97dd62c6e8cdc79ef6664a4697df1de8be17bc7e2d2b982b107ad0802","job_id":"3vS3Tn8q6DSkcY6pjq6lkaPq8hC6","target":"c5a70000","id":"921c13c8-755c-46af-b17c-534c49b45fa3"}}
[2018-06-23 22:03:48] pool_have_job: Pool sent a new job (ID: 3vS3Tn8q6DSkcY6pjq6lkaPq8hC6)
[2018-06-23 22:03:57] Miner version: 1.6.1
[2018-06-23 22:04:00] AMD Platform ID: 0
[2018-06-23 22:04:00] AMD platform FOUND
[2018-06-23 22:04:00] Found 5 AMD devices
[2018-06-23 22:04:00] GPU0: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 8]
[2018-06-23 22:04:00] GPU1: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 2]
[2018-06-23 22:04:00] GPU2: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 7]
[2018-06-23 22:04:00] GPU3: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 10]
[2018-06-23 22:04:00] GPU4: Radeon RX 560 Series [Baffin] [4096 MB][Intensity 51.0][W: 8][T: 2][K: 1][BUS: 9]
[2018-06-23 22:04:00] ADL is enabled
[2018-06-23 22:04:00] Cryptonight StelliteV4 mode enabled
[2018-06-23 22:04:00] Stopping miner process

V1.6.0 all Ok.

It looks good here :

Code:

[2018-06-23 22:16:49] Miner version: 1.6.1
[2018-06-23 22:16:49] AMD Platform ID: 1
[2018-06-23 22:16:49] AMD platform FOUND
[2018-06-23 22:16:49] Found 1 AMD devices
[2018-06-23 22:16:49] GPU0: Radeon RX 580 Series [Ellesmere] [8192 MB][Intensity 124.0][W: 8][T: 1][K: 1][BUS: 1]
[2018-06-23 22:16:49] ADL is enabled
[2018-06-23 22:16:49] Cryptonight StelliteV4 mode enabled
[2018-06-23 22:16:49] DevFee pools loaded
[2018-06-23 22:16:49] DevFee pool SET
[2018-06-23 22:16:49] DevFee address SET
[2018-06-23 22:16:49] Starting init of mining threads
[2018-06-23 22:16:49] Loading kernel for DEVICE BUS ID 1 ...
[2018-06-23 22:16:50] ADL initialised successfully!
[2018-06-23 22:16:50] Finished init of mining threads
[2018-06-23 22:16:50] Main pool: communitypool.stellite.cash:6600
[2018-06-23 22:16:50] Gpu watchdog started
[2018-06-23 22:16:50] API disabled
[2018-06-23 22:16:51] socket_ssl: SSL/TLS fingerprint: SHA256:d5VI8Z7Qj7fBSxQCFojNbCTgvXODtG3dEthetRj8oK0=
[2018-06-23 22:16:51] json_send: {"method":"login","params":{"login":"SEiStP7SMy1bvjkWc9dd1t2v1Et5q2DrmaqLqFTQQ9H7JKdZuATcPHUbUL3bRjxzxTDYitHsAPqF8EeCLw3bW8ARe8rYH6wukKR34YEPJjXv6","pass":"x","agent":"SRBMiner Cryptonight AMD GPU miner/1.6.1","rigid":""},"id":1}
[2018-06-23 22:16:51] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"id":"00c8017c-5ca3-4915-b2d8-4d92b749c424","job":{"blob":"0404e3d4bad9053d6f5bf0d05243b512f735ae005a5637734d020123b57fa27496f7329444cd9f00000000bb141c9abf552d5bb76ff61902a1a164a5b239b7d301f9ebc00f6ba67d553a6d05","job_id":"3d33HhEGg2hIlAB98XGb+kCBS4HJ","target":"c5a70000","id":"00c8017c-5ca3-4915-b2d8-4d92b749c424"},"status":"OK"}}
[2018-06-23 22:16:51] Connected to communitypool.stellite.cash:6600
[2018-06-23 22:16:51] sock_ready: User logged in
[2018-06-23 22:16:51] pool_have_job: Pool sent a new job (ID: 3d33HhEGg2hIlAB98XGb+kCBS4HJ)
[2018-06-23 22:17:05] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"0404c4d5bad9051ade69f9e3b8e52620eae94a43ee956de19cd184b355bff2400ee97035bd9e350000000098b835335d671c9dd2f767deff15d1a95295c2f5cc80ba3b83e9eb3c1ff3142802","job_id":"264XfvDjPqrzUvZHaLCXThEC3Z4C","target":"c5a70000","id":"00c8017c-5ca3-4915-b2d8-4d92b749c424"}}
[2018-06-23 22:17:05] pool_have_job: Pool sent a new job (ID: 264XfvDjPqrzUvZHaLCXThEC3Z4C)
[2018-06-23 22:18:20] miner_result: Sending user result to pool
[2018-06-23 22:18:20] json_send: {"method":"submit","params":{"id":"00c8017c-5ca3-4915-b2d8-4d92b749c424","job_id":"264XfvDjPqrzUvZHaLCXThEC3Z4C","nonce":"21f30000","result":"852540eca664bde489453e1e159b0995a8d889eef7eb60c40dc9475df4a40000"},"id":1}
[2018-06-23 22:18:20] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}}
[2018-06-23 22:18:20] miner_result: Pool accepted result 0x0000A4F4
[2018-06-23 22:18:24] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"0404c4d5bad9051ade69f9e3b8e52620eae94a43ee956de19cd184b355bff2400ee97035bd9e3500000000794eca0cda34a73bb0ed920a815c4fdfe2f1098054fc1a74a3d4591060d67e7f02","job_id":"1Z6tUEDn/OaHeTPllTGFT8AW9Ixv","target":"f4020200","id":"00c8017c-5ca3-4915-b2d8-4d92b749c424"}}
[2018-06-23 22:18:24] pool_have_job: Pool sent a new job (ID: 1Z6tUEDn/OaHeTPllTGFT8AW9Ixv)
[2018-06-23 22:18:36] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"04049fd6bad9051957a65bbc91ba7197687096277b6f9baae6235721298b091885f2b90cbbd684000000008b4c7b519cdefe0a9977a220a412dffbf38e02d0bf285bd14455d930609eb0eb0d","job_id":"aO0mkw7+scwO4vbG3ipEtN5q/IiC","target":"f4020200","id":"00c8017c-5ca3-4915-b2d8-4d92b749c424"}}
[2018-06-23 22:18:36] pool_have_job: Pool sent a new job (ID: aO0mkw7+scwO4vbG3ipEtN5q/IiC)
[2018-06-23 22:18:50] hashrate: GPU0: 871 H/s [BUS:1]
[2018-06-23 22:18:50] hashrate: Total: 871 H/s
[2018-06-23 22:19:04] miner_result: Sending user result to pool
[2018-06-23 22:19:04] json_send: {"method":"submit","params":{"id":"00c8017c-5ca3-4915-b2d8-4d92b749c424","job_id":"aO0mkw7+scwO4vbG3ipEtN5q/IiC","nonce":"e1570000","result":"5c58aecb1b131b057021ea6435dbf4430adcb1b3c65efe25985cdf5ba3000000"},"id":1}
[2018-06-23 22:19:05] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}}
[2018-06-23 22:19:05] miner_result: Pool accepted result 0x000000A3
[2018-06-23 22:19:13] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"0404c4d6bad905131bedec5df569c05e20421d4952483dd027e96d58c0245ec3ed955e779e9cf100000000c899dd9ba56e78de067283d455e4e52c3c203864a880df798e5f354c7170d7e704","job_id":"/ZUmuZ4jsoOoYFbO9LNgAiAn3YPI","target":"f4020200","id":"00c8017c-5ca3-4915-b2d8-4d92b749c424"}}
[2018-06-23 22:19:13] pool_have_job: Pool sent a new job (ID: /ZUmuZ4jsoOoYFbO9LNgAiAn3YPI)

UAGet

newbie

Activity: 70

Merit: 0

Hi!

V1.6.1 is not worked with stellitev4...
From logfile

Code:

[2018-06-23 22:03:12] Miner version: 1.6.1
[2018-06-23 22:03:13] AMD Platform ID: 0
[2018-06-23 22:03:13] AMD platform FOUND
[2018-06-23 22:03:13] Found 5 AMD devices
[2018-06-23 22:03:13] GPU0: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 8]
[2018-06-23 22:03:13] GPU1: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 2]
[2018-06-23 22:03:13] GPU2: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 7]
[2018-06-23 22:03:13] GPU3: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 10]
[2018-06-23 22:03:13] GPU4: Radeon RX 560 Series [Baffin] [4096 MB][Intensity 51.0][W: 8][T: 2][K: 1][BUS: 9]
[2018-06-23 22:03:13] ADL is enabled
[2018-06-23 22:03:13] Cryptonight StelliteV4 mode enabled
[2018-06-23 22:03:14] DevFee pools loaded
[2018-06-23 22:03:14] DevFee pool SET
[2018-06-23 22:03:14] DevFee address SET
[2018-06-23 22:03:14] Starting init of mining threads
[2018-06-23 22:03:15] Loading kernel for DEVICE BUS ID 8 ...
[2018-06-23 22:03:16] Loading kernel for DEVICE BUS ID 8 ...
[2018-06-23 22:03:18] Loading kernel for DEVICE BUS ID 2 ...
[2018-06-23 22:03:19] Loading kernel for DEVICE BUS ID 2 ...
[2018-06-23 22:03:21] Loading kernel for DEVICE BUS ID 7 ...
[2018-06-23 22:03:22] Loading kernel for DEVICE BUS ID 7 ...
[2018-06-23 22:03:24] Loading kernel for DEVICE BUS ID 10 ...
[2018-06-23 22:03:25] Loading kernel for DEVICE BUS ID 10 ...
[2018-06-23 22:03:27] Loading kernel for DEVICE BUS ID 9 ...
[2018-06-23 22:03:28] Loading kernel for DEVICE BUS ID 9 ...
[2018-06-23 22:03:29] ADL initialised successfully!
[2018-06-23 22:03:29] Finished init of mining threads
[2018-06-23 22:03:29] Main pool: communitypool.stellite.cash:6600
[2018-06-23 22:03:29] Gpu watchdog started
[2018-06-23 22:03:29] API enabled on port 21555
[2018-06-23 22:03:32] socket_ssl: SSL/TLS fingerprint: SHA256:d5VI8Z7Qj7fBSxQCFojNbCTgvXODtG3dEthetRj8oK0=
[2018-06-23 22:03:32] json_send: {"method":"login","params":{"login":"SEiStP7SMy1bvjkWc9dd1t2v1Et5q2DrmaqLqFTQQ9H7JKdZuATcPHUbUL3bRjxzxTDYitHsAPqF8EeCLw3bW8ARe8rYH6wukKR34YEPJjXv6","pass":"farm1","agent":"SRBMiner Cryptonight AMD GPU miner/1.6.1","rigid":""},"id":1}
[2018-06-23 22:03:32] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"id":"921c13c8-755c-46af-b17c-534c49b45fa3","job":{"blob":"0404f9b2bad9051e6d3c3d2c7e14df19292534ec31592f5d95685db5c0473a74fbb55395989c7400000000955923173e8b74a52e5a411bcd8bb3770457544294750a343ee7af2bcc4ea98501","job_id":"D10B0EuZ60In3VTKq/BHjY+hxByE","target":"c5a70000","id":"921c13c8-755c-46af-b17c-534c49b45fa3"},"status":"OK"}}
[2018-06-23 22:03:32] Connected to communitypool.stellite.cash:6600
[2018-06-23 22:03:32] sock_ready: User logged in
[2018-06-23 22:03:32] pool_have_job: Pool sent a new job (ID: D10B0EuZ60In3VTKq/BHjY+hxByE)
[2018-06-23 22:03:48] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"040493b3bad9054ebbad8c8c18b96e3075ed20d588279e8d0a096420d97fedf61fadf1e00ca695000000002a5f9a47d97dd62c6e8cdc79ef6664a4697df1de8be17bc7e2d2b982b107ad0802","job_id":"3vS3Tn8q6DSkcY6pjq6lkaPq8hC6","target":"c5a70000","id":"921c13c8-755c-46af-b17c-534c49b45fa3"}}
[2018-06-23 22:03:48] pool_have_job: Pool sent a new job (ID: 3vS3Tn8q6DSkcY6pjq6lkaPq8hC6)
[2018-06-23 22:03:57] Miner version: 1.6.1
[2018-06-23 22:04:00] AMD Platform ID: 0
[2018-06-23 22:04:00] AMD platform FOUND
[2018-06-23 22:04:00] Found 5 AMD devices
[2018-06-23 22:04:00] GPU0: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 8]
[2018-06-23 22:04:00] GPU1: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 2]
[2018-06-23 22:04:00] GPU2: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 7]
[2018-06-23 22:04:00] GPU3: Radeon RX 560 Series [Baffin] [2048 MB][Intensity 19.0][W: 8][T: 2][K: 1][BUS: 10]
[2018-06-23 22:04:00] GPU4: Radeon RX 560 Series [Baffin] [4096 MB][Intensity 51.0][W: 8][T: 2][K: 1][BUS: 9]
[2018-06-23 22:04:00] ADL is enabled
[2018-06-23 22:04:00] Cryptonight StelliteV4 mode enabled
[2018-06-23 22:04:00] Stopping miner process

V1.6.0 all Ok.

UnclWish

sr. member

Activity: 1484

Merit: 253

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.

Kgonla

newbie

Activity: 129

Merit: 0

Quote from: dingdongtobias on June 23, 2018, 01:30:17 AM

Quote from: hesido on June 22, 2018, 04:49:17 PM

Quote from: Kgonla on June 22, 2018, 08:23:56 AM

Same problem under Server 2008 R2:

[2018-06-22 15:05:58] CryptonightV7 mode enabled
[2018-06-22 15:06:40] DevFee pools loaded
[2018-06-22 15:06:40] DevFee pool SET
[2018-06-22 15:06:40] DevFee address SET

42 sec. to load devfee pools, not firewalled.

@doktor: Maybe you can make this call async? Until then, hardcoded fallback in the first run and "last known good" dev fee pool would be used, basically, you cache the good dev fee pools as soon as you receive them, and use that until the new one is set.

It is working fine on win7 & win8 & win10. Why do you use server edition anyway?

Because I only have one PC, others are laptops, I use as server & I don't want to use W10 because his spying policy.

I see I'm the only one with this issue, I'm using v1.5.8 without any problem, all my problems started when doktor added the pools loading through his web site.
I'm just reporting this issue, if doktor can fix easily & he wants to do it is welcome for me, if not, I understand if he don't want to spend his time with this.

Most of the time I use Awesome Miner, it often switches from one coin to another so the 42 seconds wait are not good.

Finally I'm curious why it takes exactly 42 seconds waiting. Something blocking or waiting that time for some reason?

By the way:
What happens if his website goes down or have any connection problem? The program takes several minutes to start or even do not start?

zeef

newbie

Activity: 301

Merit: 0

Quote from: doktor83 on June 23, 2018, 02:32:43 AM

Quote from: zeef on June 22, 2018, 04:51:34 PM

Quote from: doktor83 on June 22, 2018, 08:11:17 AM

V1.6.1
- Changed IPBC/Bittube old algo to new BitTubeV2 algo (from block 110000)
- Max difficulty reconnecting mechanism is now triggering instantly
- Added 'worksize' option in config.txt, that is applied to every GPU (only if not set in gpu_conf)
- Hopefuly fixed a bug with job timeout reconnecting
- Hashrate watchdog now triggers even when user not connected to pool

+ BitTube (former IPBC) forks on block 110.000, and their new algo will be BitTube V2.
You can use the new algo only after they forked, use "cryptonight_type" : "bittubev2". The old IPBC algo has been removed, so until the fork please use the previous version of SRBMiner.

+ Added 'worksize' option in config.txt (use it on top of config.txt , where intensity and double_threads is). If set, it will be applied to every GPU that is found. Of course if you have a gpu_conf set, those settings will be used, insted of this global setting.

+ Some had app crash on job_timeout triggering, i hope i managed to fix it

+ Hashrate watchdog was set to trigger only if user is connected to the pool. Now this is changed, watchdog will monitor GPU'S all the time.

Doktor can you improve one problem that happen if miner crashes and when windows restart if for an reason one gpu is not recognized and if we have set in gpu_conf: (9 gpus, but when restaring only recognizes Cool

The miner wont start, and gives us an error. With that if happen in night when restart at least we hash with 8 gpus.

And when wake up we solve the problem. (restart again hehe)

"gpu_conf" :
[
   { "id" : 0, "intensity" : 61, "worksize" : 8, "threads" : 2}, // Máximo que dá é 63 de intensity no heavy!! a partir de 62 perde performance!!
   { "id" : 1, "intensity" : 56, "worksize" : 8, "threads" : 2}, // Maximo vega 56 é 57
   { "id" : 2, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 3, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 4, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 5, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 6, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 7, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 8, "intensity" : 61, "worksize" : 8, "threads" : 2},
]

Regards

could you provide me a log? Windows does not recognize a card on system restart? If so i can't do anything lol

Hi doktor,

Thanks for help.

I know, its not a miner problem. But sometime some gpu crash and when restart its not recognized (only if i restart again) and it was nice if your miner could ignore oneplus id.

For example if i have 9 gpus and put 10 in gpu_conf, your miner crashes. Could it ignore the +id if if this gpu doesnt exist?

This will avoid te situation i described..

Regards

Beruang123

newbie

Activity: 10

Merit: 0

Hi,

I have 2 mining rigs :
1. 4 RX 580 8 GB (MSI) and 2 RX Vega 56 (Power Color Red Devil)
2. 5 RX Vega 56 (Power Color Red Devil)

Both installed win 10 1709, AMD driver18.5.1 & mining normal_v7, but why in rig 1, I can set RX Vega with MC 920, but in Rig 2, the max MC I can set is 895 without any error??

1. Rig 1 SS:
GPU0 : 1131 H/s [T: 58c, RPM: 3105, CC: 1366 MHz, MC: 2050 MHz]
GPU1 : 1001 H/s [T: 58c, RPM: 3155, CC: 1366 MHz, MC: 2050 MHz]
GPU2 : 1123 H/s [T: 60c, RPM: 3091, CC: 1366 MHz, MC: 2050 MHz]
GPU3 : 1128 H/s [T: 60c, RPM: 3172, CC: 1366 MHz, MC: 2050 MHz]
GPU4 : 1878 H/s [T: 57c, RPM: 2368, CC: 1408 MHz, MC: 920 MHz]
GPU5 : 1885 H/s [T: 53c, RPM: 2349, CC: 1408 MHz, MC: 920 MHz]

2. Rig 2 SS:
GPU0 : 1838 H/s [T: 57c, RPM: 2368, CC: 1408 MHz, MC: 895 MHz]
GPU1 : 1824 H/s [T: 60c, RPM: 2358, CC: 1408 MHz, MC: 895 MHz]
GPU2 : 1836 H/s [T: 54c, RPM: 2402, CC: 1408 MHz, MC: 895 MHz]
GPU3 : 1835 H/s [T: 62c, RPM: 2391, CC: 1408 MHz, MC: 895 MHz]
GPU4 : 1841 H/s [T: 59c, RPM: 2652, CC: 1408 MHz, MC: 895 MHz]

Any ideas why this is happening??

Also, need help how to flash my Vegas from 56 to 64, already tried with the rom provided https://www.techpowerup.com/vgabios/196853/Powercolor.RXVega64.8192.171114.rom, but still cannot flash, if im not mistaken the error is different file size.

Any help appreciated.

Thanks

doktor83

hero member

Activity: 2548

Merit: 626

Quote from: zeef on June 22, 2018, 04:51:34 PM

Quote from: doktor83 on June 22, 2018, 08:11:17 AM

V1.6.1
- Changed IPBC/Bittube old algo to new BitTubeV2 algo (from block 110000)
- Max difficulty reconnecting mechanism is now triggering instantly
- Added 'worksize' option in config.txt, that is applied to every GPU (only if not set in gpu_conf)
- Hopefuly fixed a bug with job timeout reconnecting
- Hashrate watchdog now triggers even when user not connected to pool

+ BitTube (former IPBC) forks on block 110.000, and their new algo will be BitTube V2.
You can use the new algo only after they forked, use "cryptonight_type" : "bittubev2". The old IPBC algo has been removed, so until the fork please use the previous version of SRBMiner.

+ Added 'worksize' option in config.txt (use it on top of config.txt , where intensity and double_threads is). If set, it will be applied to every GPU that is found. Of course if you have a gpu_conf set, those settings will be used, insted of this global setting.

+ Some had app crash on job_timeout triggering, i hope i managed to fix it

+ Hashrate watchdog was set to trigger only if user is connected to the pool. Now this is changed, watchdog will monitor GPU'S all the time.

Doktor can you improve one problem that happen if miner crashes and when windows restart if for an reason one gpu is not recognized and if we have set in gpu_conf: (9 gpus, but when restaring only recognizes Cool

The miner wont start, and gives us an error. With that if happen in night when restart at least we hash with 8 gpus.

And when wake up we solve the problem. (restart again hehe)

"gpu_conf" :
[
   { "id" : 0, "intensity" : 61, "worksize" : 8, "threads" : 2}, // Máximo que dá é 63 de intensity no heavy!! a partir de 62 perde performance!!
   { "id" : 1, "intensity" : 56, "worksize" : 8, "threads" : 2}, // Maximo vega 56 é 57
   { "id" : 2, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 3, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 4, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 5, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 6, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 7, "intensity" : 61, "worksize" : 8, "threads" : 2},
   { "id" : 8, "intensity" : 61, "worksize" : 8, "threads" : 2},
]

Regards

could you provide me a log? Windows does not recognize a card on system restart? If so i can't do anything lol

dingdongtobias

newbie

Activity: 156

Merit: 0

Quote from: hesido on June 22, 2018, 04:49:17 PM

Quote from: Kgonla on June 22, 2018, 08:23:56 AM

Same problem under Server 2008 R2:

[2018-06-22 15:05:58] CryptonightV7 mode enabled
[2018-06-22 15:06:40] DevFee pools loaded
[2018-06-22 15:06:40] DevFee pool SET
[2018-06-22 15:06:40] DevFee address SET

42 sec. to load devfee pools, not firewalled.

@doktor: Maybe you can make this call async? Until then, hardcoded fallback in the first run and "last known good" dev fee pool would be used, basically, you cache the good dev fee pools as soon as you receive them, and use that until the new one is set.

It is working fine on win7 & win8 & win10. Why do you use server edition anyway?

Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching - page 215. (Read 237263 times)