doktor83 (OP)
|
|
May 11, 2018, 05:56:41 AM |
|
doktor version 1.4.9 7 did not migrate from the backup pool to the main pool. 7 hours worked on the reserve.
where did you read that it's supposed to do that ?
|
|
|
|
popow_sergei
Newbie
Offline
Activity: 26
Merit: 0
|
|
May 11, 2018, 05:59:20 AM |
|
doktor version 1.4.9 7 did not migrate from the backup pool to the main pool. 7 hours worked on the reserve.
where did you read that it's supposed to do that ? transfer in manual mode? meaning then ?
|
|
|
|
doktor83 (OP)
|
|
May 11, 2018, 06:07:03 AM |
|
doktor version 1.4.9 7 did not migrate from the backup pool to the main pool. 7 hours worked on the reserve.
where did you read that it's supposed to do that ? transfer in manual mode? meaning then ? If it can't connect to first specified pool, after 2 retries it goes to the second one, and so on.. When reached the last pool, it goes back to the first one. Pressing 'p' will switch manually to the next pool.
|
|
|
|
popow_sergei
Newbie
Offline
Activity: 26
Merit: 0
|
|
May 11, 2018, 06:15:50 AM |
|
doktor version 1.4.9 7 did not migrate from the backup pool to the main pool. 7 hours worked on the reserve.
where did you read that it's supposed to do that ? transfer in manual mode? meaning then ? If it can't connect to first specified pool, after 2 retries it goes to the second one, and so on.. When reached the last pool, it goes back to the first one. Pressing 'p' will switch manually to the next pool. [2018-05-11 09:03:30] stats: Average time to find share: 9 seconds [2018-05-11 09:03:33] miner_result: Sending user result to pool [2018-05-11 09:03:33] json_send: {"method":"submit","params":{"id":"75597012-29ec-44a4-90e1-fe8e8f19c728","job_id":"cX8eJtwEizLbuhJJ78wlevDX9ELp","nonce":"d69e0080","result":"5815276d2b2ff4deb0bba1f97a53c9f79989352b129bf7d9e600a77e28160000"},"id":1} [2018-05-11 09:03:33] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}} [2018-05-11 09:03:33] miner_result: Pool accepted result 0x00001628 [2018-05-11 09:03:37] User initiated pool switching [2018-05-11 09:03:37] on_reconnect: Connecting to pool.miners.pro:3335 [2018-05-11 09:03:37] Connection to pool lost. Reconnecting in 5 seconds. [2018-05-11 09:03:38] socket_error: Ҥ欠௯ 㼯שּׂ鳼 ﰥ𠶨 櫲嬠 [2018-05-11 09:03:38] Connection to pool lost. Reconnecting in 5 seconds. [2018-05-11 09:03:43] on_reconnect: Connecting to pool.miners.pro:3335 [2018-05-11 09:03:43] json_send: {"method":"login","params":{"login":"41hMpaW77Eh1bmT1DdDngicHcA34toXdeH9SJHd291QRPCyMscFmScw3ZZXnNYQfUtgfGMbomMWSvVuY141Nupu","pass":"VEGA1","agent":"SRBMiner Cryptonight AMD GPU miner/1.4.9"},"id":1} [2018-05-11 09:03:43] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"id":"267504822812043","job":{"blob":"07078ee7d4d705c82ffe75ed004307b58d39effbcf15592644f80af30be7ab318c53e037b7cafc0000000087b340cd6608e335ef0c94363c7e8140570fc3c29863de6a085a66af126f0e0e02","job_id":"778978075762279","target":"b2df0000","id":"267504822812043"},"status":"OK"}} [2018-05-11 09:03:43] sock_ready: User logged in [2018-05-11 09:03:43] pool_have_job: Pool difficulty: 75000 [2018-05-11 09:03:43] pool_have_job: Pool sent a new job (ID: 778978075762279) [2018-05-11 09:03:43] on_reconnect: Connecting to pool.miners.pro:3335 [2018-05-11 09:03:43] json_send: {"method":"login","params":{"login":"41hMpaW77Eh1bmT1DdDngicHcA34toXdAAWPtwqeH9SJHd291QRPCyMscFmScw3ZZXnNYQfUtgfGMWSvVuY141Nupu","pass":"VEGA1","agent":"SRBMiner Cryptonight AMD GPU miner/1.4.9"},"id":1} [2018-05-11 09:03:44] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"id":"606420595408417","job":{"blob":"07078ee7d4d705c82ffe75ed004307b58d39effbcf15592644f80af30be7ab318c53e037b7cafc00000000b552e265af6bb80cc8ceb52af1ff93d3669335eb2ef3d5874fbdab245bacddd302","job_id":"463760118954815","target":"b2df0000","id":"606420595408417"},"status":"OK"}} [2018-05-11 09:03:44] sock_ready: User logged in [2018-05-11 09:03:44] pool_have_job: Pool difficulty: 75000 [2018-05-11 09:03:44] pool_have_job: Pool sent a new job (ID: 463760118954815) [2018-05-11 09:03:49] stats: Mining time: 0 days, 0 hours, 0 minutes, 58 seconds [2018-05-11 09:03:49] stats: Pool: pool.miners.pro:3335 [2018-05-11 09:03:49] stats: Connected since: 2018-05-11 09:03:44 [2018-05-11 09:03:49] stats: GPU Target Temperature: 75 [2018-05-11 09:03:49] stats: Accepted/Total shares: 5/5
[2018-05-11 09:03:58] miner_result: Sending user result to pool [2018-05-11 09:03:58] json_send: {"method":"submit","params":{"id":"606420595408417","job_id":"463760118954815","nonce":"a12d0040","result":"6d154e3dc89384933bdc50547d823dcaed30824eead6f8e343f9222cf18c0000"},"id":1} [2018-05-11 09:03:58] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}} [2018-05-11 09:03:58] miner_result: Pool accepted result 0x00008CF1 [2018-05-11 09:04:15] User initiated pool switching [2018-05-11 09:04:15] on_reconnect: Connecting to pool.monero.hashvault.pro:7777 [2018-05-11 09:04:15] Connection to pool lost. Reconnecting in 5 seconds. [2018-05-11 09:04:16] socket_error: Ҥ欠௯ 㼯שּׂ鳼 ﰥ𠶨 櫲嬠 [2018-05-11 09:04:16] Connection to pool lost. Reconnecting in 5 seconds. [2018-05-11 09:04:21] on_reconnect: Connecting to pool.monero.hashvault.pro:7777 [2018-05-11 09:04:21] on_reconnect: Connecting to pool.monero.hashvault.pro:7777 [2018-05-11 09:04:21] json_send: {"method":"login","params":{"login":"41nujo2JithhQHT4yQMDaf3iSJtuHfkrodNXwvki7dxCXqiqBQTsy6i4TRkrkARAFAaoCsUs5DK5xoC34PFw7D6ExWMbp+100000","pass":"VEGA1","agent":"SRBMiner Cryptonight AMD GPU miner/1.4.9"},"id":1} [2018-05-11 09:04:21] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"id":"f275ada7-2f33-4f63-85cd-56da47c9d452","job":{"blob":"07078ee7d4d705c82ffe75ed004307b58d39effbcf15592644f80af30be7ab318c53e037b7cafc000000008e279d80fcbb75c7bc75d71171592f6092409919f1d712096c180fdc5891dbf902","job_id":"QUirVbuOnv+u3a+py3d7tFrrkBuZ","target":"c5a70000","id":"f275ada7-2f33-4f63-85cd-56da47c9d452","algo":"cn","variant":1},"extensions":["algo"],"status":"OK"}} [2018-05-11 09:04:21] sock_ready: User logged in [2018-05-11 09:04:21] json_send: {"method":"login","params":{"login":"41nujo2JithhQHT4yQMDaf3iSJtuHfkrodNXwvki7dxCXqiqBQTsy6i4TRkrkGARAFAaoV5DK5xoC34PFw7D6ExWMbp+100000","pass":"VEGA1","agent":"SRBMiner Cryptonight AMD GPU miner/1.4.9"},"id":1} [2018-05-11 09:04:21] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"id":"521f3445-cc02-4c30-9653-4208b0934ab9","job":{"blob":"07078ee7d4d705c82ffe75ed004307b58d39effbcf15592644f80af30be7ab318c53e037b7cafc0000000034888e2495328b7513c8420a1662725d93bf5617c0378328648b0de0b564897c02","job_id":"y3CyyumqvTuJAHmw7ydcSeEB8XR2","target":"c5a70000","id":"521f3445-cc02-4c30-9653-4208b0934ab9","algo":"cn","variant":1},"extensions":["algo"],"status":"OK"}} [2018-05-11 09:04:21] sock_ready: User logged in [2018-05-11 09:04:21] pool_have_job: Pool difficulty: 100001 [2018-05-11 09:04:21] pool_have_job: Pool sent a new job (ID: QUirVbuOnv+u3a+py3d7tFrrkBuZ) [2018-05-11 09:04:21] pool_have_job: Pool sent a new job (ID: y3CyyumqvTuJAHmw7ydcSeEB8XR2)
socket_error ?
|
|
|
|
dragonmike
|
|
May 11, 2018, 07:31:23 AM Last edit: May 11, 2018, 08:20:27 AM by dragonmike |
|
How much juice do you give the core to run it at 1525?? That's pretty high...
925mV on core. HWInfo64 reports 894-906mV fluctuating. Ok that's not too bad actually. Will have a go at it and check power draw. I suspect it's not going to be worth it (I'm getting 1350h/s at 1428@905 core & 1140 mem.
|
|
|
|
hesido
Jr. Member
Offline
Activity: 158
Merit: 5
|
|
May 11, 2018, 07:32:36 AM |
|
If it can't connect to first specified pool, after 2 retries it goes to the second one, and so on.. When reached the last pool, it goes back to the first one. Pressing 'p' will switch manually to the next pool.
Doktor, can you make "fast pool switch" not so fast? If you can add a 3-4 second delay ("switching to pool: xxxxx in 3 seconds") while allowing the user to press p again to switch to the next pool, this would allow us to switch pools without connecting and disconnecting many times if we have many pools in pools txt, so I'd be able to press p three times to switch to the 4th in list, without connecting and disconnecting the first three, and the switch would be more graceful (without having to dispose the current job, connect, fire up the next job, only to dispose it again because I'm trying to connect to the other pool). Every key press would cancel the previous timeout, and add a new 3-4 seconds timeout.
|
|
|
|
douketrue
Newbie
Offline
Activity: 84
Merit: 0
|
|
May 11, 2018, 08:57:24 AM |
|
I have three riggs for 5 gpu rx 550, in SRB the miner speed of each rig is 2400 mh\s, on the pool the speed of each rig is 2300 m\hs, is it normal that the srb miner shows inflated values?
|
|
|
|
Amigo9881
Newbie
Offline
Activity: 14
Merit: 0
|
|
May 11, 2018, 10:53:55 AM |
|
How can i setup API to monitor my rig through url.
Super noob here, please provide step by step guide anyone.
btw great job Dok!, super stable miner.
thanks
in your config.txt file make sure you have something like this: "api_enabled" : true, "api_rig_name" : "RX4708GB", "api_port" : 4444,
of course you can change the rig name and port number. from another workstation in your LAN you use the IP address of your rig followed by the port, so something like this: where 192.168.1.100 is the address of your miner. If you want to access from the internet you may have to open up the port 4444 on your router. I dont see any line in config text file for api setup, you mean i have to type is my self at the end of text file? if you can share how to do it in context file . that will great. thanks in advance
|
|
|
|
Temo_inc
Newbie
Offline
Activity: 4
Merit: 0
|
|
May 11, 2018, 01:02:28 PM |
|
How can i setup API to monitor my rig through url.
Super noob here, please provide step by step guide anyone.
btw great job Dok!, super stable miner.
thanks
in your config.txt file make sure you have something like this: "api_enabled" : true, "api_rig_name" : "RX4708GB", "api_port" : 4444,
of course you can change the rig name and port number. from another workstation in your LAN you use the IP address of your rig followed by the port, so something like this: where 192.168.1.100 is the address of your miner. If you want to access from the internet you may have to open up the port 4444 on your router. I dont see any line in config text file for api setup, you mean i have to type is my self at the end of text file? if you can share how to do it in context file . that will great. thanks in advance Im using like this and its working { /* Type can be : normal, normalv7, lite, litev7, heavy, ipbc, artocash, alloy */ "cryptonight_type" : "heavy", /* Intensity 0-> auto intensity, or value from 1-300 */ "intensity" : 0, "api_enabled" : true, "api_rig_name" : "RX570", "api_port" : 4444,
|
|
|
|
heavyarms1912
|
|
May 11, 2018, 01:48:39 PM |
|
How much juice do you give the core to run it at 1525?? That's pretty high...
925mV on core. HWInfo64 reports 894-906mV fluctuating. Ok that's not too bad actually. Will have a go at it and check power draw. I suspect it's not going to be worth it (I'm getting 1350h/s at 1428@905 core & 1140 mem. Power draw seems to be 15-20w higher (from wall). Also I can't keep it sustained for a long time.
|
|
|
|
hesido
Jr. Member
Offline
Activity: 158
Merit: 5
|
|
May 11, 2018, 06:51:41 PM |
|
To follow up my own post about pool switching, currently, pool switching causes hashrate fluctuations (at least for Cryptonight Heavy), although technically it shouldn't be much different from getting a new job from the same pool as far as performance is concerned. The fact that there are fluctuations after switching could lead you to find the problem that causes the fluctuations to begin with, maybe it will make it easier to debug that.
Just half an hour ago SRB did an auto switch and the hasrate dropped by 500 mh/s, and it's very slowly recovering. A manual switch also causes hashrate drops.
|
|
|
|
Sx5000
Jr. Member
Offline
Activity: 31
Merit: 5
|
|
May 11, 2018, 07:57:14 PM Last edit: May 11, 2018, 08:10:06 PM by Sx5000 |
|
To follow up my own post about pool switching, currently, pool switching causes hashrate fluctuations (at least for Cryptonight Heavy), although technically it shouldn't be much different from getting a new job from the same pool as far as performance is concerned. The fact that there are fluctuations after switching could lead you to find the problem that causes the fluctuations to begin with, maybe it will make it easier to debug that.
Just half an hour ago SRB did an auto switch and the hasrate dropped by 500 mh/s, and it's very slowly recovering. A manual switch also causes hashrate drops.
Same problem. When you run the miner on a heavy algorithm, a hasht is random. The maximum can go out after 5 minutes and after 6 hours. After switching to another pool or developer pool, the hash may also decrease, or it may remain the same. Videocards radeon 588, if it helps to establish the cause.
|
|
|
|
a7med918
Newbie
Offline
Activity: 33
Merit: 0
|
|
May 11, 2018, 08:12:25 PM |
|
dears i have about 1000h/s in 1.4.6 version
this hash decrease to800 on new version with same config
any help
|
|
|
|
rbrcpa
Copper Member
Jr. Member
Offline
Activity: 62
Merit: 1
|
|
May 12, 2018, 02:26:29 AM |
|
Is there any way to specify a variable (such as password) from the command line?
I use awesome miner which just recently added support for srbminer.
The only problem is it updates the pool info from the pools you setup in awesome miner, where I can’t put a password because then each of my rigs would be named the same thing. This also means I can’t manually update the config file on my rigs because awesome miner then overwrites that file with the pool info when I start the miner.
Most of the pools I use seem to use the password field for worker name. With Cast XMR I could get around this by adding a -p switch in the CLI field & then the appropriate worker name behind it. This would start the miner with a bat file that overwrote the pool info with the switches entered in the CLI field.
Is there any way to do something similar with srbminer?
|
|
|
|
rusman2
Newbie
Offline
Activity: 21
Merit: 0
|
|
May 12, 2018, 05:34:25 AM |
|
Have you tried other drivers , or lowering the intensity ? There was a bug that made random app crashes, but that was fixed, that's why i asked if a crash window appears.
Been running the Hynix cards as I usually do (1350/2000) and no issues. The Samsung card is running at 1281/1750 and has been running for 2 days 22 hours +. I think it's just on me being too aggressive with OC. Sorry about that. I'm also noticing that after coming out of devfee it sometimes has a few hashes of [2018-05-11 22:48:07] miner_result: Duplicate share protection kicked in! Sometimes it's a few, sometimes none, and a couple of times over the ~2 weeks using it I've noticed it ran for a good couple of hours with duplicate shares. I'm not too concerned at this point but wanted to let you know.
|
|
|
|
inv1s1bl3
Newbie
Offline
Activity: 65
Merit: 0
|
|
May 12, 2018, 06:41:01 AM |
|
I am running 5x580+ at 1240/2200 with intensity 53 and I'm getting 1k per card! Been mining for the past couple of days like that and it has been a very pleasant and stable experience! I see that from time to time one or two card have a lower hashrate, but the results at the pool are always a bit higher like 5.3kh/s!
|
|
|
|
dingdongtobias
Newbie
Offline
Activity: 156
Merit: 0
|
|
May 12, 2018, 06:41:59 AM |
|
To follow up my own post about pool switching, currently, pool switching causes hashrate fluctuations (at least for Cryptonight Heavy), although technically it shouldn't be much different from getting a new job from the same pool as far as performance is concerned. The fact that there are fluctuations after switching could lead you to find the problem that causes the fluctuations to begin with, maybe it will make it easier to debug that.
Just half an hour ago SRB did an auto switch and the hasrate dropped by 500 mh/s, and it's very slowly recovering. A manual switch also causes hashrate drops.
Same problem. When you run the miner on a heavy algorithm, a hasht is random. The maximum can go out after 5 minutes and after 6 hours. After switching to another pool or developer pool, the hash may also decrease, or it may remain the same. Videocards radeon 588, if it helps to establish the cause. https://i.imgur.com/5nikog1.jpgno hashrate drop on pool switch
|
|
|
|
Sx5000
Jr. Member
Offline
Activity: 31
Merit: 5
|
|
May 12, 2018, 07:04:36 AM Last edit: May 12, 2018, 07:17:11 AM by Sx5000 |
|
http://prntscr.com/jgvj1nI did not make screenshots until this moment, I tried to overcome the problem myself. I changed the riser, power supplies, added RAM, changed the priorities of the processes, intensity, voltage, timings, danced around the computer and so on. But nothing helps Hash changes to the heavy algorithm for + -100 and nothing can be done about it
|
|
|
|
istr
Newbie
Offline
Activity: 24
Merit: 0
|
|
May 12, 2018, 10:25:01 AM |
|
@doktor83 I'm pretty sure that you are aware of all these occasions, I mean with the hashdrop. Cards with 4gb memory dont have this issue, at least to me. They reach maximum hashspeed immediately. The problem is with the 8gb cards. Whenever I start your miner one of them, sometimes more, can go up to maximum, others no and they stay low all the time even after 2,3,4 hours of mining. Next time I'm starting your miner some other cards or card do the opposite thing. It's a random situation. To help things out, you of course the developer of a great miner to me, I found out that running GPU-Z at the time your miner runs and passing throu all cards one by one and then exiting, voula all cards running full speed. Problem solved. But of course this is not a solution!!! Maybe something with the interrupts? I'm trying to help!
|
|
|
|
dingdongtobias
Newbie
Offline
Activity: 156
Merit: 0
|
|
May 12, 2018, 11:48:22 AM |
|
@doktor83 I'm pretty sure that you are aware of all these occasions, I mean with the hashdrop. Cards with 4gb memory dont have this issue, at least to me. They reach maximum hashspeed immediately. The problem is with the 8gb cards. Whenever I start your miner one of them, sometimes more, can go up to maximum, others no and they stay low all the time even after 2,3,4 hours of mining. Next time I'm starting your miner some other cards or card do the opposite thing. It's a random situation. To help things out, you of course the developer of a great miner to me, I found out that running GPU-Z at the time your miner runs and passing throu all cards one by one and then exiting, voula all cards running full speed. Problem solved. But of course this is not a solution!!! Maybe something with the interrupts? I'm trying to help!
let me try this with gpu-z maybe i get more hash when pool send new job it is normal that hashrate drops and slowly goes up.
|
|
|
|
|