It looks like newer drivers (adrenaline 2019) slow down the crashing issue that occurs because the memory or page file grows too much. Anyone else can confirm this? Testing now 19.3.2 and ONT 0.2.8, the timing level whatever i put isn't changing the hashrate for me on Vega56. Is it just me or .. ?  First tests show that hashrate is worse than on 18.6.1 - tested on bittube and v4. If you use the compiled kernels from 18.6.1 on 19.3.2 then the hashrate will be also good. |
|
|
|
I use it too with overdriventool and very good stability and more hashes than 18.6.1 U should consider look at it doktor xD I will try it, maybe there is even room for some small optimisations too |
|
|
|
I think it is v4 problem. 1.8.1 is better than 1.8.0 but still not 100% stable. It was no problem on other algos in srbminer, eth rock stable, mined beam for weaks rock stable, everything i was trowing at vegas just worked. Then it came v4 and it came problems. I just love srbminer cause it is best miner for vega cards, but when v4 cam and it was unstable, i tried other miners for v4, you have at lleast 4 of them, and they crash even faster, teamredminer crashed under 10min on same settings as srbminer. Tried to underclock gpu,mem for stability and same. Problem is only on v4, other algos are fine  Something is very bad with new algo, just put loop in bat file and it will at least run again when it crashes The whole concept of how v4 works is bad on gpu's. Compiling code on every new block, then need to release that memory, but it is known that the amd cl_release api is buggy and it wont always work as it should. For cpu's this concept of create code + compile is not a problem , but for gpu's it is. I am trying out various things, hope for the best  hi doc v4 algor , designed for cpu not gpu. do you test new amd driver ? it's very good. it's work for few day just few crash .  Haha, no, i test only on 18.6.1 and blockchain. Which new version do you refer to? |
|
|
|
I think it is v4 problem. 1.8.1 is better than 1.8.0 but still not 100% stable. It was no problem on other algos in srbminer, eth rock stable, mined beam for weaks rock stable, everything i was trowing at vegas just worked. Then it came v4 and it came problems. I just love srbminer cause it is best miner for vega cards, but when v4 cam and it was unstable, i tried other miners for v4, you have at lleast 4 of them, and they crash even faster, teamredminer crashed under 10min on same settings as srbminer. Tried to underclock gpu,mem for stability and same. Problem is only on v4, other algos are fine Something is very bad with new algo, just put loop in bat file and it will at least run again when it crashes The whole concept of how v4 works is bad on gpu's. Compiling code on every new block, then need to release that memory, but it is known that the amd cl_release api is buggy and it wont always work as it should. For cpu's this concept of create code + compile is not a problem , but for gpu's it is. I am trying out various things, hope for the best |
|
|
|
On my 280X video cards I keep getting these warnings with V4:
WARNING: Linking two modules of different data layouts!
WARNING: Linking two modules of different target triples: input.bc: 'amdil64-pc-unknown-amdopencl' and 'amdil-pc-unknown-amdopencl'
WARNING: Linking two modules of different data layouts!
WARNING: Linking two modules of different target triples: input.bc: 'amdil64-pc-unknown-amdopencl' and 'amdil-pc-unknown-amdopencl'
WARNING: Linking two modules of different data layouts!
WARNING: Linking two modules of different target triples: input.bc: 'amdil64-pc-unknown-amdopencl' and 'amdil-pc-unknown-amdopencl'
WARNING: Linking two modules of different data layouts!
WARNING: Linking two modules of different target triples: input.bc: 'amdil64-pc-unknown-amdopencl' and 'amdil-pc-unknown-amdopencl'
Apart from that, it seems to be working.
I will need to figure out the best settings next.
These warnings are harmless, nothing to worry about |
|
|
|
can you see your windows event viewer and see what log save there ? last crash (and all the previous). source: Application error, event code: 1000, category: (100), and full path to SRBMiner exe file. Nothing else near. I'm catching error 1000 event via scheduler and run reboot.bat in case of it. Rig reboots and goes well for next 6 or more hours Are you mining V4 ? Im curious are the crashes happening only on V4 ? If so, im probably not releasing some of the CL resources as i should.. |
|
|
|
it's page file I don't have same event regarding swap file. also it is set to 70Gb for 8 cards, so it's not the main reason My guess is that i have a bug somwhere in my net code, so i am fully rewriting it, it's going to take some time, but i hope it will fix these annoying random crashes  |
|
|
|
hi doc. i got this before stop again. [2019-03-19 06:35:04] json_send[200]: {"id":1,"jsonrpc": "2.0","method":"submit","params":{"id":"384626154776718","job_id":"379878018372315","nonce":"63d96f57","result":"30663415f3114aa9e8a801cf612f83ebc252d60e3ccdc77a37a82791bb190000"}}
[2019-03-19 06:35:04] json_receive[62]: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}}
[2019-03-19 06:35:04] miner_result: Pool accepted result 0x000019BB for job[143] [171ms]
[2019-03-19 06:35:28] DevFee pool NOT SET!
[2019-03-19 06:35:28] DevFee pool NOT SET! i use V 1.8.0. Miner won't stop if devfee pool can't be set/connected ONCE, it will do something only after few hours of trying. Also why still using 1.8.0 ? |
|
|
|
anybody tuned intensity param for CNv4 on Vegas?
112 for vega56, 123 for vega64, also try playing with the thread delay parameter doctor, I have 2 RX 588. On 1st all right, but on 2nd speed max can i get on SRB miner is 1001-1002 h/s on cnr. But on TeamRed miner on this card i have 1045 h/s. Tried different intensities, tried to change thread delay, but can't increase max speed. Windows 10, Drivers is last 19.3.2. Yes you wrote this already, how can i help you ? You are in this a long time ago, you know same cards with same straps & settings won't always give same hashrate.. Someone told me that if he compiles the kernel on 18.6.1 and uses it on 19.2.3, he got better hashrate. Maybe try that. |
|
|
|
anybody tuned intensity param for CNv4 on Vegas?
112 for vega56, 123 for vega64, also try playing with the thread delay parameter |
|
|
|
Sup guys.
Long time i dont mine cryptonight, i used SRB to mine heavy algo good time ago and stoped.
Now i am gonna help a friend of myne to mine Monero with SRB miner, monero uses V4 right?
Can some1 tell me what is the intensity that is normaly used in a RX 580 in v4?
You could try out the auto setup , just leave intensity at 0 |
|
|
|
json_receive[264]: {"id": null, "method": "job", "params": {"id": "me", "blob": "0b0bd69fbfe4054b8a11a88c0c438a9e53e3c6e87ca6de209472a24369e9d979db7822fb5031c70000000024b1e0da2381f3400d9f1ee2bfeb54884eea0e1209270f9d2b772b0429aaf5ae02", "job_id": "19c4b03", "target": "8b4f0100"}}
But that pool is crazy, when no block height is sent SRB uses block height 0, and pool accepted that result, which shouldn't happen. this is how a good job should look : json_receive[259]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bf1a5bfe405a17745ceba1ac56db8353be64c3ac900b042217bd528c0a8fd4859b9f25ae7d3000000006b67bdffaf379ef71a75d2fe532b646742a92e3d77f0f2ca774cfdc1053b295612","job_id":"15551","target":"cf8b0000","height":1793523}}
See the "height":1793523 at the end Yeah, is a crazy pool. But all winking fine? no need re-programming?) Well if you get hashrate poolside and accepted shares, yeah it's ok |
|
|
|
That is not a CN V4/R pool or if it is, it's not working good. The accepted messages are false.
No. It's also CN V4/R pool. TMR working well. Hashing withouts errors. It cant work when the pool does not send block height, you can see in the log in the json if the pool sent block height or not can you paste a part of the log where this error is? [2019-03-18 20:09:11] json_send[160]: {"id":1,"jsonrpc": "2.0","method":"login","params":{"login":"me","pass":"d=50000 n=rx570-2","agent":"SRBMiner Cryptonight AMD GPU miner/1.8.1","rigid":""}}
[2019-03-18 20:09:11] json_receive[304]: {"id": 1, "result": {"id": "me", "job": {"blob": "0707abd8d8dd05163e813771fb7483305927dade29b0fa724081141a3406c5d9fa9eb52df484e3000000007d808a953ce6747a97ef273356bc917759a763b78c28251c6fc63334b39019db07", "job_id": "initial_job", "target": "10000000", "id": "me"}, "status": "OK"}, "error": null}
[2019-03-18 20:09:11] json_receive[264]: {"id": null, "method": "job", "params": {"id": "me", "blob": "0b0bd69fbfe4054b8a11a88c0c438a9e53e3c6e87ca6de209472a24369e9d979db7822fb5031c7000000009c5312c8a671b9dc57c233c0e5d3d1f78a27741f8c933a4068f03f16231d949f02", "job_id": "19c2f88", "target": "8b4f0100"}}
[2019-03-18 20:09:11] Connected to prohashing.com:3347
[2019-03-18 20:09:11] sock_ready: User logged in
[2019-03-18 20:09:11] pool_have_job: Pool sent a new job [ID: 19c2f88]
[2019-03-18 20:09:12] Block height = 0 for V4 job - DeviceID 0 (Thread 0) [report to pool]
[2019-03-18 20:09:12] Block height = 0 for V4 job - DeviceID 0 (Thread 1) [report to pool]
[2019-03-18 20:09:43] hashrate: GPU0: 992 H/s [T:51c][BUS:1]
[2019-03-18 20:09:43] hashrate: Total: 992 H/s
[2019-03-18 20:10:06] json_receive[264]: {"id": null, "method": "job", "params": {"id": "me", "blob": "0b0bd69fbfe4054b8a11a88c0c438a9e53e3c6e87ca6de209472a24369e9d979db7822fb5031c700000000ea1c0b4a4a934288f7f07510c86747108ee956ebd769968ee9c91421ad68828b02", "job_id": "19c3a3e", "target": "8b4f0100"}}
[2019-03-18 20:10:06] pool_have_job: Pool sent a new job [ID: 19c3a3e]
[2019-03-18 20:10:06] Block height = 0 for V4 job - DeviceID 0 (Thread 1) [report to pool]
[2019-03-18 20:10:07] Block height = 0 for V4 job - DeviceID 0 (Thread 0) [report to pool]
[2019-03-18 20:10:08] pool_ping: Sent keepalive message to pool
[2019-03-18 20:10:08] json_receive[52]: {"id": 1, "result": {"status": "OK"}, "error": null}
[2019-03-18 20:10:17] hashrate: GPU0: 991 H/s [T:52c][BUS:1]
[2019-03-18 20:10:17] hashrate: Total: 991 H/s
[2019-03-18 20:10:17] stats: Algo: normalv4
[2019-03-18 20:10:17] stats: Mining time: 0 days, 0 hours, 1 minutes, 7 seconds
[2019-03-18 20:10:17] stats: Pool: prohashing.com:3347
[2019-03-18 20:10:17] stats: Connected since: 2019-03-18 20:09:11
[2019-03-18 20:10:17] stats: Last job received : 11 seconds ago
[2019-03-18 20:10:51] miner_result: Sending user result to pool
[2019-03-18 20:10:51] json_send[183]: {"id":1,"jsonrpc": "2.0","method":"submit","params":{"id":"me","job_id":"19c3a3e","nonce":"74520000","result":"f9083efa07dba9e102c03af04ee762ff88a84db7999c337bc398cbb793ba0000"}}
[2019-03-18 20:10:51] json_receive[52]: {"id": 1, "result": {"status": "OK"}, "error": null}
[2019-03-18 20:10:51] miner_result: Pool accepted result 0x0000BA93 for job[2] [125ms]
[2019-03-18 20:10:56] json_receive[264]: {"id": null, "method": "job", "params": {"id": "me", "blob": "0b0bd69fbfe4054b8a11a88c0c438a9e53e3c6e87ca6de209472a24369e9d979db7822fb5031c70000000024b1e0da2381f3400d9f1ee2bfeb54884eea0e1209270f9d2b772b0429aaf5ae02", "job_id": "19c4b03", "target": "8b4f0100"}}
[2019-03-18 20:10:56] pool_have_job: Pool sent a new job [ID: 19c4b03]
Just as i thought, jobs don't have the needed height parameter : json_receive[264]: {"id": null, "method": "job", "params": {"id": "me", "blob": "0b0bd69fbfe4054b8a11a88c0c438a9e53e3c6e87ca6de209472a24369e9d979db7822fb5031c700000000ea1c0b4a4a934288f7f07510c86747108ee956ebd769968ee9c91421ad68828b02", "job_id": "19c3a3e", "target": "8b4f0100"}}json_receive[264]: {"id": null, "method": "job", "params": {"id": "me", "blob": "0b0bd69fbfe4054b8a11a88c0c438a9e53e3c6e87ca6de209472a24369e9d979db7822fb5031c70000000024b1e0da2381f3400d9f1ee2bfeb54884eea0e1209270f9d2b772b0429aaf5ae02", "job_id": "19c4b03", "target": "8b4f0100"}}
But that pool is crazy, when no block height is sent SRB uses block height 0, and pool accepted that result, which shouldn't happen. this is how a good job should look : json_receive[259]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bf1a5bfe405a17745ceba1ac56db8353be64c3ac900b042217bd528c0a8fd4859b9f25ae7d3000000006b67bdffaf379ef71a75d2fe532b646742a92e3d77f0f2ca774cfdc1053b295612","job_id":"15551","target":"cf8b0000","height":1793523}}
See the "height":1793523 at the end |
|
|
|
That is not a CN V4/R pool or if it is, it's not working good. The accepted messages are false.
No. It's also CN V4/R pool. TMR working well. Hashing withouts errors. It cant work when the pool does not send block height, you can see in the log in the json if the pool sent block height or not can you paste a part of the log where this error is? |
|
|
|
Pool prohashing.com, v4 algo. 18.6.1, rx570.
[2019-03-18 19:12:19] Connected to prohashing.com:3347
[2019-03-18 19:12:19] User logged in
[2019-03-18 19:12:19] Pool difficulty: 50000
[2019-03-18 19:12:19] Pool sent a new job [ID: 1985c64]
[2019-03-18 19:12:19] Block height = 0 for V4 job - DeviceID 0 (Thread 0) [report to pool]
[2019-03-18 19:12:19] Block height = 0 for V4 job - DeviceID 0 (Thread 1) [report to pool]
[2019-03-18 19:12:30] Pool accepted result 0x00007624 for job[1] [124ms]
[2019-03-18 19:12:52] GPU0 : 994 H/s [T: 52c, RPM: 1800, CC: 1250 MHz, MC: 2265 MHz][BUS:1]
[2019-03-18 19:12:52] Total: 994 H/s
[2019-03-18 19:13:13] Pool sent a new job [ID: 1986970]
[2019-03-18 19:13:14] Block height = 0 for V4 job - DeviceID 0 (Thread 0) [report to pool]
[2019-03-18 19:13:15] Block height = 0 for V4 job - DeviceID 0 (Thread 1) [report to pool]
[2019-03-18 19:13:15] Pool sent a new job [ID: 1986989]
[2019-03-18 19:13:16] Block height = 0 for V4 job - DeviceID 0 (Thread 0) [report to pool]
[2019-03-18 19:13:16] ERROR : PARSE error: Malformed data received!
[2019-03-18 19:13:16] Pool accepted result 0x000027C9 for job[3] [130ms]
[2019-03-18 19:13:16] Reconnecting to prohashing.com:3347 in 10 seconds
[2019-03-18 19:13:17] Block height = 0 for V4 job - DeviceID 0 (Thread 1) [report to pool]
[2019-03-18 19:13:27] Connected to prohashing.com:3347
[2019-03-18 19:13:28] User logged in
[2019-03-18 19:13:28] Pool difficulty: 50000
[2019-03-18 19:13:28] Pool sent a new job [ID: 1986efa]
[2019-03-18 19:13:28] Block height = 0 for V4 job - DeviceID 0 (Thread 1) [report to pool]
[2019-03-18 19:13:28] Block height = 0 for V4 job - DeviceID 0 (Thread 0) [report to pool]
[2019-03-18 19:13:43] GPU0 : 990 H/s [T: 50c, RPM: 1960, CC: 1250 MHz, MC: 2265 MHz][BUS:1]
[2019-03-18 19:13:43] Total: 990 H/s
[2019-03-18 19:13:49] Pool accepted result 0x00001E27 for job[4] [130ms]
That is not a CN V4/R pool or if it is, it's not working good. The accepted messages are false. |
|
|
|
no, didn't connect to a rig before it crashed
i just tested and clicked in the window and paused for 10 minutes, it looks exactly as your log, all jobs arrive at the same time same second. But leave the miner running and lets see if it will crash the same way again. |
|
|
|
video driver crashed or miner ? miner. started again without rebooting, continues hashing... strange log ending before crash, like something has stuck [2019-03-18 17:03:17] miner_result: Sending user result to pool
[2019-03-18 17:03:17] json_send[175]: {"id":1,"jsonrpc": "2.0","method":"submit","params":{"id":"1","job_id":"8452","nonce":"d5c900a0","result":"74fa3eceef9687c0886ea81b69558d62367d748918267714d10b1b288a4b0000"}}
[2019-03-18 17:03:17] json_receive[62]: {"id":1,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}
[2019-03-18 17:03:17] miner_result: Pool accepted result 0x00004B8A for job[353] [199ms]
[2019-03-18 17:03:17] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0ba5cabee40522a6424a9648a5db67d0e6ca31555a2b82ca2e37f93920eb200cebf8cc3b342c00000000716ac6402c0ff5ad53e09376992ec48701286d1242e77e287ba6e03b783aa0510b","job_id":"8453","target":"cf8b0000","height":1793456}}
[2019-03-18 17:03:17] pool_have_job: Pool sent a new job, block height 1793456 [ID: 8453]
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0be1cabee40522a6424a9648a5db67d0e6ca31555a2b82ca2e37f93920eb200cebf8cc3b342c00000000a2419812ec5e207a3dd46b44f7bc91d1219e3dc97058a1ea5c19cbe8085bcf9a0c","job_id":"8454","target":"cf8b0000","height":1793456}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0b9dcbbee40522a6424a9648a5db67d0e6ca31555a2b82ca2e37f93920eb200cebf8cc3b342c000000008dafd1b64ab2e0bfc649c953abf7596f272fb8ef20485fcc082336113528aaeb0e","job_id":"8455","target":"cf8b0000","height":1793456}}
[2019-03-18 17:17:56] pool_have_job: Pool sent a new job, block height 1793456 [ID: 8454]
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bd9cbbee40522a6424a9648a5db67d0e6ca31555a2b82ca2e37f93920eb200cebf8cc3b342c00000000eb2be741ba7af48f758583f5b73b97e96911819df4c044a8996b41f1b90b5d2d0f","job_id":"8456","target":"cf8b0000","height":1793456}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bebcbbee4057696cf1085851e78c22c79038b63f1d092c411b4fdb6c3268ba95da44e2ffa17000000000241e3ffe681ab6cc9b11740bed55411ca1fab2a1478a7323c14fc55dd1ef20302","job_id":"8457","target":"cf8b0000","height":1793457}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bf3cbbee40596a751f4b79715018fd6db85f0de3e97ae7ba08b6bc16b1203f23ef78590701a0000000020e00cfb9d22834e6769a6d68f19a1bbaa3c6a562408bfd355a0e8adda1185aa07","job_id":"8458","target":"cf8b0000","height":1793458}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bafccbee40596a751f4b79715018fd6db85f0de3e97ae7ba08b6bc16b1203f23ef78590701a00000000985d4d4a2bd3835751a26a5359eb1ecda524f709dd26c998d999ef7368beb35918","job_id":"8459","target":"cf8b0000","height":1793458}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bebccbee40596a751f4b79715018fd6db85f0de3e97ae7ba08b6bc16b1203f23ef78590701a000000007c73c9a7bfa46b2d53805864595f28fe98fe184d5a2a54274506c84d922531031a","job_id":"8460","target":"cf8b0000","height":1793458}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0befccbee40576158e1e85c5c75cf912a6d96b3d2dd9522cf76d0899a7150571fbad226401e900000000160b6f8d4f06db791d65680a2bdc10b25e983fa72183763b1550b26ce506e72614","job_id":"8461","target":"cf8b0000","height":1793459}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0babcdbee40576158e1e85c5c75cf912a6d96b3d2dd9522cf76d0899a7150571fbad226401e900000000acc934903269570e24f634166e874d11918ad318e644c9dd08fc669debb728f417","job_id":"8462","target":"cf8b0000","height":1793459}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bd8cdbee40528350e7b0d6bf19714917fc95793e6076dfc4c9df595c91e5ada8059f980e02c0000000012ade42170b6100987ffcd13c62e95bace516e71d032e06d92d5b072e5af2c8d05","job_id":"8463","target":"cf8b0000","height":1793460}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0be9cdbee405bf64c9d26d7ef64b24b448c1318b5dbb71dcf626f822463c78c2877e7a3a0315000000007d10b6262b47cd54deb79d122f2c4c135f1ce65e8ea4e48d6233e9784ee45a1d02","job_id":"8464","target":"cf8b0000","height":1793461}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0ba5cebee405bf64c9d26d7ef64b24b448c1318b5dbb71dcf626f822463c78c2877e7a3a031500000000f2b5ed7fa7f877136597c2e33592fbddf01d2782942afdb556ded9442c22348f07","job_id":"8465","target":"cf8b0000","height":1793461}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bcdcebee4059ecdea070dac9526b428265e4f506bd359073d2b3eecdc0f8bbd1c91d59a6676000000002ae46b0ec4d50a3881476249534ecc59f4e0c7f0cd5612aead01dbe726a442f001","job_id":"8466","target":"cf8b0000","height":1793462}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0b84cfbee405eba0a2acb18d7ff755a8a89742397a45efd1f80b9d7f96c92ea2b888f7aa5b9500000000a37ecf5f933c7a4f06f24289d6b435c9d8f42a83562044d94e454cf1cb02fb7c05","job_id":"8467","target":"cf8b0000","height":1793463}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0b9fcfbee405b4d2511437f803436a87f13cb9497acd0a0cdb702daf6107a7b040fd95b677ff00000000e7abe5585a7ee763fb994873f5bdcca52b051ec7f9a759f0506db4007411346504","job_id":"8468","target":"cf8b0000","height":1793464}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bdbcfbee405b4d2511437f803436a87f13cb9497acd0a0cdb702daf6107a7b040fd95b677ff0000000081f38ff954b4d46cee02b84ba190c6c2ca7f6dc92c637e2cab52248cf698fedd07","job_id":"8469","target":"cf8b0000","height":1793464}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0b98d0bee405b4d2511437f803436a87f13cb9497acd0a0cdb702daf6107a7b040fd95b677ff000000004d7847770b757e661757f7e648e57da7e783fdd3efd7710a360b76d71c1964070b","job_id":"8470","target":"cf8b0000","height":1793464}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0bd4d0bee405b4d2511437f803436a87f13cb9497acd0a0cdb702daf6107a7b040fd95b677ff0000000053c319ecbe0a36531ce71b9b61c8d361b687a5f4e395f9cb75f80a717ae1ac0e0b","job_id":"8471","target":"cf8b0000","height":1793464}}
[2019-03-18 17:17:56] json_receive[258]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0b90d1bee405b4d2511437f803436a87f13cb9497acd0a0cdb702daf6107a7b040fd95b677ff000000008ea63555ad7b0248303c86a0c4aacee4cd1043106590c9979d90fff89cf23e160c","job_id":"8472","target":"cf8b0000","height":1793464}} Looks like you clicked in the window and paused the miner |
|
|
|
testing 1.8.1 on v4 on 8xVegas-rig, crashed after several hours  "old" Monero and Ethereum were weeks-stable video driver crashed or miner ? |
|
|
|
This is the problem I keep having:
After reboot, display GPU or first GPU / GPU 0 will always crash after miner is started immediately as pool sends 1st job. Other GPU's are fine, but only the one connected to display, or GPU 0 has this issue and its reproducible on 2 identical rigs so I know its not a hardware issue. Then after I close the miner and start it second time, everything is fine.
Steps to reproduce:
- Reboot PC
- Start miner, wait till received job from pool, observe crash, hit H and GPU overclock is reset to default clock
- Close miner, restart miner, works fine after that
Using RX 470s, GRAFT algo.
Anyone else having similar issue? Dok is this something that could be fixed ?
Hi Dok - any idea why this would be happening? Also I have 2 rigs with RX 470s, and on 1.8 GRAFT algo they're not stable for more than a day, crash and reboot on both. I reduced OC and increased voltage but still not stable for more than a day. Previously both rigs ran SRBMiner v1.6.8 and very stable for 30-40 days non stop - any ideas what would cause this instability on v1.8? Thanks in advance! About the gpu that is connected to the display, try to set a lower intensity on that one, it is using more memory than the other cards, and it probably fails because of that the first time. It's hard to tell what could cause video driver crashes, what i recommend always is to do driver cleaning with DDU, and use 18.6.1 drivers because they are proven to be good and stable. Then start with a lower intensity and build up slowly. |
|
|
|
hi .
it's work for 6 H and crash again. i don't test new one
I really hope 1.8.1 will work good for you |
|
|
|
|
Show Posts
