V1.7.6- New tuning parameter 'thread_delay', can be used in cmd (--cgputhreaddelay), config, gpu_conf - Even faster kernel compilation - Added HTML statistics page, can be accessed if API is enabled via /stats - Added 3 new API parameters: --apirigrestarturl, --apirigshutdownurl, --apiminerrestarturl - Added share 'trip' time from miner->pool->miner on share sending - Added SSL in interactive configurator - Removed --runbenchmark, --benchmarkduration parameters - Fixed algo benchmarking - Webchain sending stale shares again - Startup monitor now restarts whole machine on fail, instead of miner - Fixed a bug with shutdown temperature and false ADL temperature reporting + Oh, a new parameter that can impact your hashing speed : thread_delay (or --cgputhreaddelay in start.bat) It's value goes from 1-1000. It is used only when 2 or more threads are used per SAME GPU. Simply said, this value controls the timing between thread starting on the same gpu. The default is 319, this is something i found acceptable across multiple gpu platforms. + Added a GUI statistics page, where you can see basic info about your mining session. First you must enable API, by using the --apienable parameter in start.bat Set your rig (computer) name with --apirigname myrigname also in start.bat After you have started the miner, you can access the stats page in your browser : http://127.0.0.1:21555/statsThere are also three other parameters that can help you to restart miner, reboot or shutdown your machine remotely : --apirigrestarturl This should be a unique string, which accessed in browser results in a computer restart. Miner needs to have admin privileges. --apirigshutdownurl This should be a unique string, which accessed in browser results in a computer shutdown. Miner needs to have admin privileges. --apiminerrestarturl This should be a unique string, which accessed in browser restart SRBMiner. Example start.bat: SRBMiner-CN.exe --config Config\config-normalv8.txt --pools Pools\pools-normalv8.txt --apienable --apirigrestarturl 12345fff --apirigshutdownurl 54321fff --apiminerrestarturl restart_my_srb Visiting this url restarts your machine: http://127.0.0.1:21555/12345fffVisiting this url turns off your machine: http://127.0.0.1:21555/54321fffVisiting this url restarts SRBMiner: http://127.0.0.1:21555/restart_my_srbOf course if you are going to 'open' this HTTP interface to the world, you better use complex urls so nobody can guess them easilly and turn off your rig Smiley + Now showing time in ms for shares. This is the time needed for: - your miner sent the share to the pool - pool accepted the share, did some validation and returned a result - your miner accepted the result + Removed the benchmarking per algo, there is the --benchmarkalgos parameter which benches all you got in algos.txt
|
|
|
Feedback on V. 1.7.5
Now it finally works when I have mix of 270X and 280X video cards. Hashrates are very good for normal V8 algo: 280X 450 H/s 270X 345 H/s 290 530H/s
I do not OC. I also sometimes get lots of STALE shares.
Good job!
Awesome, thanks for reporting. Also stales shown in miner are not a problem because those are accepted shares. Its just more a 'cosmetical thing'.
|
|
|
I tried to reduce cc to 1150 mc 1950, got same errors I am mining uplex algo.
also with another miner, clocks are ok at 1200 and 1950 with Vcc 940/900 with 800 Watts, getting around 21kh/s
so I wanted to test this miner to see if I can get more.
Strange thing is that one of the RX580 is a 4 Gb card, other 6 are 8Gb, and it's getting 3.3kh/s while the others are around 10% less.
I have something like you with V8. I was using 1.7.0 working fine, after switching to 1.7.4-5 my RX 580 4GB is giving about 12 H/s more than before but full of compute errors. The 8GB 580 are same hash rate & I think they work fine but not tested carefully. Try to disable the 4GB card pressing the number where it is placed, if compute errors disappear it is a miner problem. I don't know if 1.7.0 have the uplex algo, if it have try with this version. Also I have better H/s with 4GB than with 8GB but it is a very old miner problem, I think is better optimized for 4GB cards. Just tested UPX on : 470 4g 570 4g 580 4g Driver 18.6.1 Ran it for 30 minutes, no compute errors. Also 3.3khs is low for 580 4gb, it should do 3.7khs without any crazy overclocking.
|
|
|
Does anyone know how to disable miner restart?
If any GPU crashes, miner automatically will restart itself, this makes it hard to catch problems with GPUs when tuning settings.
I would like to know to disable restart and just have miner close itself or exit out when one of the GPUs crash.
Thanks in advance.
try with --disablegpuwatchdog (disable gpu crash detection watchdog) in start.bat Thanks for reply - but I think that will just allow the miner to continue mining if 1 GPU crashed and others are OK. Is there any way to have the miner quit / terminate itself when 1 of the GPUs crashes? You could use this : "reboot_script_gpu_watchdog" : filename to a batch file in miner directory, if set it turns off built in miner reset procedure on gpu failure, and instead runs this script
basically make a script that does what you want (nothing)
|
|
|
Can someone tell me if srbminer works on old GPUs like gtx6*** and gtx5*** series ,I've tried it out but the hashrates seems so lower than xmrstack and xmrig How have you tried it out when those are Nvidias and SRBMiner is AMD only?
|
|
|
Hi All, Please somebody tell me how to set worker id to mine at pool.webchain.network. Thanks!
Modify pools.txt like this: { "pools" : [ { "pool" : "pool.webchain.network:3333", "wallet" : "0xab5ab2607e801356f13978f04e4ad2909ce6c5c3", "worker" : "rig1", "password" : "x" } ] } But SRB does not work well with this algorithm. Live hashrate and hashrate pool very different is less than 3 times. LOUD miner shows much better. use srbminer 1.7.4. work perfect, but you can`t configure "worker" : "rig1", pool doesent recognize it I cant use 1.7.4 with my 7 rigs. More duplicate shares without worker id statistic. SRB-developer cannot repair his miner. Most likely the webchain coin is too complicated for this. LOUD miner working fine. Yes you already said this a few times, thank you It is too complicated for me , use LOUD miner it is working much better that's what i heard.
|
|
|
regarding webchain next version will send all shares, stales and not stales and im done with webchain. no more webchain.
|
|
|
Nista, vraticu onako kao sto je bilo u 174, s tim da necu prikazati da li je share stale ili ne, posto vidim da stale shareovi uzrujavaju ljude pa nemres na svaku primjedbu reagirat micanjem neceg iz statistike minera. covjel ne napisao 3 posta do sada i to je tebe jako uzrujalo ma smaraju me na discordu ti za to i ne znas Ja se stvarno izvinjavam ako sam nekog svojim porukama bilo koga uznemiravao, iz najbolje namere sam ostavio postove, SRBMINER je ubedljivo najbolji miner za cryptonote algo svojim postovima smatram da pomazem autoru da resi bagove svog softver-a konkretnim cinjenicama i predlozima nista drugo, ako je drugacije ja se stvarno izvinjavam Ma nisam na tebe mislio druze, ne brini Hi doc, Have you seen my log last post, of the vega rig freeze after v 1.7.0? i can confirm that 1.7.0 work good four hours. Have you look into somethig? Thanks and happy new year Problem is i don't know what to look for because numerous users with vega rigs dont have any problems with stability on newer miner versions..
|
|
|
Nista, vraticu onako kao sto je bilo u 174, s tim da necu prikazati da li je share stale ili ne, posto vidim da stale shareovi uzrujavaju ljude pa nemres na svaku primjedbu reagirat micanjem neceg iz statistike minera. covjel ne napisao 3 posta do sada i to je tebe jako uzrujalo ma smaraju me na discordu ti za to i ne znas Ja se stvarno izvinjavam ako sam nekog svojim porukama bilo koga uznemiravao, iz najbolje namere sam ostavio postove, SRBMINER je ubedljivo najbolji miner za cryptonote algo svojim postovima smatram da pomazem autoru da resi bagove svog softver-a konkretnim cinjenicama i predlozima nista drugo, ako je drugacije ja se stvarno izvinjavam Ma nisam na tebe mislio druze, ne brini
|
|
|
Nista, vraticu onako kao sto je bilo u 174, s tim da necu prikazati da li je share stale ili ne, posto vidim da stale shareovi uzrujavaju ljude pa nemres na svaku primjedbu reagirat micanjem neceg iz statistike minera. covjel ne napisao 3 posta do sada i to je tebe jako uzrujalo ma smaraju me na discordu ti za to i ne znas
|
|
|
za doktor83
V 1.7.4
v 1.7.5 levo u konzoli je pool log
Nista, vraticu onako kao sto je bilo u 174, s tim da necu prikazati da li je share stale ili ne, posto vidim da stale shareovi uzrujavaju ljude
|
|
|
jedino drajveri ako nisu u redu, koristim Win10-64Bit-Radeon-Software-Adrenalin-Edition-18.6.1-June13, do sada radilo na svemu, "alternativni" miner za webchain radi bez problema, srb V8 takodje radi extra proveri kako se ponasa na oficijalnom pool-u pool.webchain.network:3333
Driver 18.6.1 nemoj da gledas verziju 1.7.6, sve je isto kao 1.7.5
|
|
|
Does anyone know how to disable miner restart?
If any GPU crashes, miner automatically will restart itself, this makes it hard to catch problems with GPUs when tuning settings.
I would like to know to disable restart and just have miner close itself or exit out when one of the GPUs crash.
Thanks in advance.
try with --disablegpuwatchdog (disable gpu crash detection watchdog) in start.bat
|
|
|
Right, webchain implementation screwed the benchmarking.. Will be fixed.
tried srbminer 1.7.5 webchain on rx470 work ok rx570 work ok rx580 work ok vega 64 not ok tried srbminer 1.7.4 webchain on rx470 work ok (pool reject stale, no worker id) rx570 work ok (pool reject stale, no worker id) rx580 work ok (pool reject stale, no worker id) vega 64 work ok (pool reject stale, no worker id) Describe 'not ok' ne promalazi i ne salje share, testirao sam na vise pulova, dok 1.7.4 sem worker-a i stale share nema zamerke, stale share moze da se podesi na pool-u da ne kida miner, nego samo da odbije share, u sustini, treba samo json da se promeni za login: json_send: {"id":1,"jsonrpc": "2.0","method":"login","worker":"SRB","params":{"login":"","pass":"x","agent":"SRBMiner Cryptonight AMD GPU miner/1.7.5"}} za send share: json_send: {"id":1,"jsonrpc":"2.0","method":"submit","worker":"SRB","params":{"id":"0","job_id":"e676425e98f96eca13f840ca257ea73e","nonce":"0e0200a0bd010000","result":"0000405e8de648cb84562234d61b39c1771edaa54759030c819a58dd87f23fda"}}
|
|
|
Same problem reported here since v1.7.1 or more the vega rig became unstable. My rx580 rig have no problems with v1.7.4. Vega 64 rig with v 1.7.4 get ramdom restarts, and i increase the mv in all gpus, lower intensity , and same problem!!
Driver version, algo, config file? Does the miner restart, and work ok after that, or system freezes? Can you describe ? Maybe i can find out what is happening It was all ok on 1.7.0 ? Also how often is this happening? Is there any specific case you maybe noticed? For me I get some card hashing speed at 0h/s ( sometimes all together ), then miners restart by itself but failed to start , the system freeze ( restart needed) . I get that error more often after 1.7.0. I post the log just above. Windows 10 , Xmr ( V8) , 1.6.1. PS : I tried to increase mV and lower clock speed and mem speed a lot but I still get this error since srb 1.7.1 on all rigs. ( No computing error before the crash , 1/24h for some) Same problem here. exactly. Sometimes some card have 0 hash/s or all together. And now one have a strange pump in hashes. Tried to lower clocks an d increase all mv and intensity and same problem. Check this dok: [2018-12-30 14:32:17] hashrate: GPU0: 1752 H/s [T:54c][BUS:29] [2018-12-30 14:32:17] hashrate: GPU1: 1774 H/s [T:54c][BUS:32] [2018-12-30 14:32:17] hashrate: GPU2: 1778 H/s [T:54c][BUS:26] [2018-12-30 14:32:17] hashrate: GPU3: 1770 H/s [T:47c][BUS:12] [2018-12-30 14:32:17] hashrate: GPU4: 1734 H/s [T:54c][BUS:3] [2018-12-30 14:32:17] hashrate: GPU5: 1769 H/s [T:54c][BUS:6] [2018-12-30 14:32:17] hashrate: GPU6: 1766 H/s [T:54c][BUS:18] [2018-12-30 14:32:17] hashrate: GPU7: 1770 H/s [T:55c][BUS:23] [2018-12-30 14:32:17] hashrate: GPU8: 1949 H/s [T:53c][BUS:9][2018-12-30 14:32:17] hashrate: Total: 16062 H/s [2018-12-30 14:32:28] miner_result: Sending user result to pool [2018-12-30 14:32:28] json_send: {"id":1,"jsonrpc": "2.0","method":"submit","params":{"id":"662863462746484","job_id":"426769207075645","nonce":"4ebd8e63","result":"13f2f7ccdf1fed3ae46fece860886d864388a6177e2bf998136e9537d4070000"}} [2018-12-30 14:32:28] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}} [2018-12-30 14:32:28] miner_result: Pool accepted result 0x000007D4 [2018-12-30 14:33:04] miner_result: Sending user result to pool [2018-12-30 14:33:04] json_send: {"id":1,"jsonrpc": "2.0","method":"submit","params":{"id":"662863462746484","job_id":"426769207075645","nonce":"b1dd398e","result":"5d5e2db0b56fb9057dbc809eb1fdca6253d5c8bc37e7d1b2ead7d1204a050000"}} [2018-12-30 14:33:04] json_receive: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}} [2018-12-30 14:33:04] miner_result: Pool accepted result 0x0000054A [2018-12-30 14:34:17] hashrate: GPU0: 1751 H/s [T:55c][BUS:29] [2018-12-30 14:34:17] hashrate: GPU1: 1774 H/s [T:55c][BUS:32] [2018-12-30 14:34:17] hashrate: GPU2: 1778 H/s [T:54c][BUS:26] [2018-12-30 14:34:17] hashrate: GPU3: 1770 H/s [T:47c][BUS:12] [2018-12-30 14:34:17] hashrate: GPU4: 1734 H/s [T:55c][BUS:3] [2018-12-30 14:34:17] hashrate: GPU5: 1768 H/s [T:54c][BUS:6] [2018-12-30 14:34:17] hashrate: GPU6: 1766 H/s [T:54c][BUS:18] [2018-12-30 14:34:17] hashrate: GPU7: 1770 H/s [T:54c][BUS:23] [2018-12-30 14:34:17] hashrate: GPU8: 1092 H/s [T:54c][BUS:9] [2018-12-30 14:34:17] hashrate: Total: 15203 H/s [2018-12-30 14:34:27] json_receive: {"jsonrpc":"2.0","method":"job","params":{"blob":"0505f3aea3e10597f109ce1b467661284633cfba9922cbdfea25ea1acce6a87ec8b63146a386bf0 000000053294ec0c8d92887bd6f6d4e4cf9686a31ebab0e8327c9521d0886fb007c51490b","job_id":"309129661896354","target":"2f0b0000"}} [2018-12-30 14:35:12] watchdog: GPU0 [BUS: 29] hashing speed is 0 H/S [2018-12-30 14:35:12] watchdog: GPU1 [BUS: 32] hashing speed is 0 H/S [2018-12-30 14:35:12] watchdog: GPU2 [BUS: 26] hashing speed is 0 H/S [2018-12-30 14:35:12] watchdog: GPU3 [BUS: 12] hashing speed is 0 H/S [2018-12-30 14:35:12] watchdog: GPU4 [BUS: 3] hashing speed is 0 H/S [2018-12-30 14:35:12] watchdog: GPU5 [BUS: 6] hashing speed is 0 H/S [2018-12-30 14:35:12] watchdog: GPU6 [BUS: 18] hashing speed is 0 H/S [2018-12-30 14:35:12] watchdog: GPU7 [BUS: 23] hashing speed is 0 H/S [2018-12-30 14:35:12] watchdog: GPU8 [BUS: 9] hashing speed is 0 H/S [2018-12-30 14:35:23] watchdog: GPU0 [BUS: 29] hashing speed is 0 H/S [2018-12-30 14:35:23] watchdog: GPU1 [BUS: 32] hashing speed is 0 H/S [2018-12-30 14:35:23] watchdog: GPU2 [BUS: 26] hashing speed is 0 H/S [2018-12-30 14:35:23] watchdog: GPU3 [BUS: 12] hashing speed is 0 H/S [2018-12-30 14:35:23] watchdog: GPU4 [BUS: 3] hashing speed is 0 H/S [2018-12-30 14:35:23] watchdog: GPU5 [BUS: 6] hashing speed is 0 H/S [2018-12-30 14:35:23] watchdog: GPU6 [BUS: 18] hashing speed is 0 H/S [2018-12-30 14:35:23] watchdog: GPU7 [BUS: 23] hashing speed is 0 H/S [2018-12-30 14:35:23] watchdog: GPU8 [BUS: 9] hashing speed is 0 H/S[2018-12-30 14:35:34] Starting reboot script reboot-windows.bat... Sometimes when restart its ok, but when freezes i have to locally restart the rig.. In v 1.7.0 its ok. Dok see what i highlight in bold in the log. Its strange. Gpu 8 jump to 1949 h/S, almost impossible in my vega 64 mining bittube. Regards It looks to me that GPU8 killed/restarted the video driver, that's why all the others stopped hashing. Interesting that users report this only on Vegas. I will check what changed after 1.7.0 that could cause this. Are you sure 1.7.0 still works ok for you ? Can you test it a day or two ? Also im curious, can you try out --gpuwatchdogdisablemode on 1.7.5 ?
|
|
|
Right, webchain implementation screwed the benchmarking.. Will be fixed.
tried srbminer 1.7.5 webchain on rx470 work ok rx570 work ok rx580 work ok vega 64 not ok tried srbminer 1.7.4 webchain on rx470 work ok (pool reject stale, no worker id) rx570 work ok (pool reject stale, no worker id) rx580 work ok (pool reject stale, no worker id) vega 64 work ok (pool reject stale, no worker id) Describe 'not ok'
|
|
|
Right, webchain implementation screwed the benchmarking.. Will be fixed.
|
|
|
Webchain is a screwed coin, your pool reported hashrate will be much lower than miners local hashing speed, so don't be surprised. Just sayin
|
|
|
Hi guys, anyone has problems with benchmark options in 1.7.5 ? Here it simply doesn't work.
Just running benchmark-algos.bat
[2018-12-30 13:13:04] Miner version: 1.7.5 [2018-12-30 13:13:04] Windows version: 10.0 build 17134 [2018-12-30 13:13:04] Video driver version: 24.20.11021.1000 [2018-12-30 13:13:04] AMD Platform ID: 0 [2018-12-30 13:13:04] Created OCL context [2018-12-30 13:13:04] Using fragments 1 for DeviceID 0 (Thread 0) [2018-12-30 13:13:04] Using heavy_mode 1 for DeviceID 0 (Thread 0) [2018-12-30 13:13:05] Created OCL command queue for DeviceID 0 (Thread 0) [2018-12-30 13:13:05] Created OCL input buffer for DeviceID 0 (Thread 0) [2018-12-30 13:13:05] Loading [haven] kernel for DEVICE BUS_ID[3] ... [2018-12-30 13:13:05] ctx->Program for DeviceID 0 (Thread 0) loaded [2018-12-30 13:13:05] Using fragments 1 for DeviceID 0 (Thread 1) [2018-12-30 13:13:05] Using heavy_mode 1 for DeviceID 0 (Thread 1) [2018-12-30 13:13:05] Created OCL command queue for DeviceID 0 (Thread 1) [2018-12-30 13:13:05] Created OCL input buffer for DeviceID 0 (Thread 1) [2018-12-30 13:13:05] Loading [haven] kernel for DEVICE BUS_ID[3] ... [2018-12-30 13:13:05] ctx->Program for DeviceID 0 (Thread 1) loaded [2018-12-30 13:13:05] ADL initialised successfully!
And then it stops.
Same result on my single VEGA or on a 12 RX570 rig.
No problem with 1.7.2
--runbenchmark seems to do the same not working result
Tested on various algos, it compiles kernels then stops.
Any idea ? Thanks
I will check it, maybe i screwed something
|
|
|
Dok - if we have all our stuff setup through the config-heavy, config-normalv8, config-mox, etc -- will we need to do anything new?
I have all my config files and pool files setup etc.
Well you need to have a start.bat for every config you have. Or what are you asking ?
|
|
|
|