 Show Posts
|
|
Pages: [1] 2 »
|
Hello all I've started using SRBMiner exclusively, mining Monero, I get flawless performance on my Vega 56 at tweak profile 9 approx. 2020 H/S for approx. 36-48 Hrs with no invalid/bad shares, somewhere between that time it starts spitting all invalid/bad shares, any recommendations or ideas as to what may be causing this. Is there a way to configure the miner to automatically restart when it does start submitting invalid shares?
exactly the same on 1.9 with lower gpus and even WITH NO TWEAKS. 1.87 is also not perfect but works at least. restart on invalid shares is good idea as they go after few hours --gpuerrorrestart needed I have a similar issue. Everything works fine, and then after 16-20 hours I only get rejected shares. |
|
|
|
Hello,
I'm knew to SRB miner and I'm having some difficulty. I followed instructions in the guide and can only manage to get.
Enumerating OpenCL devices, please wait...
Restarting miner...
Enumerating OpenCL devices, please wait...
Restarting miner...
Enumerating OpenCL devices, please wait...
Restarting miner...
Times infinity. I'm using the generic guided set up with V1.8.9 and 8.6.1 for my vegas. I'm not sure what else to add, any advice?
Try reinstalling the drivers using DDU. Otherwise, it might be an indication of a faulty motherboard. |
|
|
|
|
Version 1.8.9 eventually crashes for me and ends up spitting only this :
[2019-05-26 10:25:49] miner_result: GPU0[BUS:1] result rejected for job[2] [invalid job id]
[2019-05-26 10:26:33] json_receive[269]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0ba9ffa8e70537e99fa7db36c5a4dde2f1ad1294fc7d53e17e50f1130701247f4ca8b9d5485c0 0000000799dc1c161b7d129985fd562330eefce621530ea39965683170a3fb3d6ca822503","job_id":"207536794639743","target":"8b4f0100","height":1842901}}
[2019-05-26 10:26:34] json_send[202]: {"id":139,"jsonrpc": "2.0","method":"submit","params":{"id":"536912071801769","job_id":"959042067134134","nonce":"011f6900","result":"5209d27598e2285070b5aee1b0916b1b27bc7c62e6d4789cc6ea379d93870000"}}
[2019-05-26 10:26:34] json_receive[73]: {"id":139,"jsonrpc":"2.0","error":{"code":-1,"message":"Invalid job id"}}
[2019-05-26 10:26:34] miner_result: Too many invalid job errors, connecting to next pool
[2019-05-26 10:27:05] json_send[202]: {"id":140,"jsonrpc": "2.0","method":"submit","params":{"id":"536912071801769","job_id":"959042067134134","nonce":"dd516900","result":"a64fbb05010809a06e1a0118e1ef2b4d76f0cc9b84de6ac7c3b00acddf230100"}}
[2019-05-26 10:27:05] json_receive[73]: {"id":140,"jsonrpc":"2.0","error":{"code":-1,"message":"Invalid job id"}}
[2019-05-26 10:27:05] miner_result: GPU0[BUS:1] result rejected for job[2] [invalid job id]
[2019-05-26 10:28:01] json_receive[269]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0b8180a9e7051daf5d91e61e074a63cc188ad34c8fb189808534be9ebf12df1eae1a6808b70a0 000000028740b2df6004a6e509c6d581f1ce5ac18dcc37e572128cb7320e20ae40dc79d17","job_id":"339747801201164","target":"8b4f0100","height":1842902}}
[2019-05-26 10:28:11] json_receive[269]: {"jsonrpc":"2.0","method":"job","params":{"blob":"0b0b8b80a9e705799ce479fc0c098816a99ebec48a2acdd9de1a0e28e802ae04492f11de4e80760 00000007c98b47f59706fe070a0d7c21e09a47b9c25efde346b48f3ab3cb40c373469e702","job_id":"635405887252134","target":"8b4f0100","height":1842903}}
|
|
|
|
Hi, I've solved the stability problems by installing the latest Adrenaline drivers. Since then, the rigs have been running flawlessly on monero. However, speed has also gone down, from 455 H/s on my ageing 280X to 430-445 H/s. The speed decrease is not so much of an issue, it's better to have the rig mining than to have them crash all the time and not mine anything. Though I would be much happier if they still worked at 450 H/s.
I wish I could, but I don't see any log files being created like in the previous versions.
If you open start.bat you will see this : REM LOGGING ENABLED
REM SRBMiner-CN.exe --config Config\config-normalv4.txt --pools pools.txt --logfile %LOGTIME%
REM LOGGING DISABLED
SRBMiner-CN.exe --config Config\config-normalv4.txt --pools pools.txt
if you remove the REM under the 'LOGGING ENABLED', and put a REM before the 'LOGGING DISABLED' part, you will get logging enabled. REM LOGGING ENABLED
SRBMiner-CN.exe --config Config\config-normalv4.txt --pools pools.txt --logfile %LOGTIME%
REM LOGGING DISABLED
REM SRBMiner-CN.exe --config Config\config-normalv4.txt --pools pools.txt
Or if you have a custom start script use the --logfile parameter. It's all the same as before, just it's not turned on by default. GOT it! Will report back with the logs. |
|
|
|
I wish I could, but I don't see any log files being created like in the previous versions.
If you open start.bat you will see this : REM LOGGING ENABLED
REM SRBMiner-CN.exe --config Config\config-normalv4.txt --pools pools.txt --logfile %LOGTIME%
REM LOGGING DISABLED
SRBMiner-CN.exe --config Config\config-normalv4.txt --pools pools.txt
if you remove the REM under the 'LOGGING ENABLED', and put a REM before the 'LOGGING DISABLED' part, you will get logging enabled. REM LOGGING ENABLED
SRBMiner-CN.exe --config Config\config-normalv4.txt --pools pools.txt --logfile %LOGTIME%
REM LOGGING DISABLED
REM SRBMiner-CN.exe --config Config\config-normalv4.txt --pools pools.txt
Or if you have a custom start script use the --logfile parameter. It's all the same as before, just it's not turned on by default. GOT it! Will report back with the logs. |
|
|
|
Ok, will look into it.
The last working version for me is V 1.8.7 .
With version 1.8.8 SRBminer seems to fail at compilation.
However, even on rigs with the same devices ( as in 2 cards of the same type), 1.8.8 will start and then fail after a few minutes. It will also have more rejected shares.
I'm mining Monero with the following settings:
{
"cryptonight_type" : "normalv4",
"intensity" : 0,
"double_threads" : true,
"adl_type" : 2,
"giveup_limit": 3,
"timeout": 10,
"gpu_conf" :
[
{ "id" : 0, "intensity" : 62, "worksize" : 16, "threads" : 1, "target_temperature" : 85, "target_fan_speed": 2000, "off_temperature":92, "adl_type": 2},
{ "id" : 1, "intensity" : 62, "worksize" : 16, "threads" : 1, "target_temperature" : 85, "target_fan_speed": 2000, "off_temperature":92, "adl_type": 2},
]
}
Can you upload a log file that SRB generates somewhere so i can take a look at it ? I wish I could, but I don't see any log files being created like in the previous versions. |
|
|
|
Ok, will look into it. The last working version for me is V 1.8.7 . With version 1.8.8 SRBminer seems to fail at compilation. However, even on rigs with the same devices ( as in 2 cards of the same type), 1.8.8 will start and then fail after a few minutes. It will also have more rejected shares. I'm mining Monero with the following settings: { "cryptonight_type" : "normalv4", "intensity" : 0, "double_threads" : true, "adl_type" : 2, "giveup_limit": 3, "timeout": 10, "gpu_conf" : [ { "id" : 0, "intensity" : 62, "worksize" : 16, "threads" : 1, "target_temperature" : 85, "target_fan_speed": 2000, "off_temperature":92, "adl_type": 2}, { "id" : 1, "intensity" : 62, "worksize" : 16, "threads" : 1, "target_temperature" : 85, "target_fan_speed": 2000, "off_temperature":92, "adl_type": 2}, ] } I've just upgraded from V 1.8.5 to V 1.8.8. The new version is completely unstable and crashes the computer on a regular basis. Sometimes is crashes itself.
Will need to revert.
If you are not using the auto settings, check that your gpu id's are set ok, because 1.8.8 uses different gpu ordering (by bus id). You can run --listdevices to see the which gpu is which id. From the release notes for 188: + The default (and only) device ordering mode from now on is ascending by bus id, as it is in OverdriveNTool. Parameter --gpureorder is removed.
NOTE: if you are using gpu_conf or --cgpuid, please run --listdevices to check if you are using the right deviceid!
[/quote] |
|
|
|
|
I've just upgraded from V 1.8.5 to V 1.8.8. The new version is completely unstable and crashes the computer on a regular basis. Sometimes is crashes itself.
Will need to revert.
|
|
|
|
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'. Feedback on V. 1.7.6 Hashrates have gone up for normal V8 algo: 280X 455 H/s 270X 400 H/s 290 650H/s Temperatures seem to be better on the 270X with this version, or maybe now they are read correctly. Feedback on V. 1.7.7 Hashrates have gone up by very little for normal V8 algo: 280X 460 H/s 270X 405 H/s 290 655H/s Fan rpm on the 270X is now correctly reported. Thank you! Feedback on V. 1.7.8 Hashrates have gone up by very little for normal V8 algo: 280X 460 H/s 270X 405 H/s 290 655H/s Basically no change. Miner has gotten a lot more stable in the past 2 months. Feedback on V. 1.8.1 Hashrates are similar to normal v8 with normal V4 algo: 280X 450 H/s 270X 400 H/s 290 750H/s Runs pretty stable for me. Ran for 1 week without any crash. Settings are almost the same as on normal v8 except that intensities need to be adjusted for optimal performance. |
|
|
|
|
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.
|
|
|
|
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'. Feedback on V. 1.7.6 Hashrates have gone up for normal V8 algo: 280X 455 H/s 270X 400 H/s 290 650H/s Temperatures seem to be better on the 270X with this version, or maybe now they are read correctly. Feedback on V. 1.7.7 Hashrates have gone up by very little for normal V8 algo: 280X 460 H/s 270X 405 H/s 290 655H/s Fan rpm on the 270X is now correctly reported. Thank you! Feedback on V. 1.7.8 Hashrates have gone up by very little for normal V8 algo: 280X 460 H/s 270X 405 H/s 290 655H/s Basically no change. Miner has gotten a lot more stable in the past 2 months. |
|
|
|
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'. Feedback on V. 1.7.6 Hashrates have gone up for normal V8 algo: 280X 455 H/s 270X 400 H/s 290 650H/s Temperatures seem to be better on the 270X with this version, or maybe now they are read correctly. Feedback on V. 1.7.7 Hashrates have gone up by very little for normal V8 algo: 280X 460 H/s 270X 405 H/s 290 655H/s Fan rpm on the 270X is now correctly reported. Thank you! |
|
|
|
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'. Feedback on V. 1.7.6 Hashrates have gone up for normal V8 algo: 280X 455 H/s 270X 400 H/s 290 650H/s Temperatures seem to be better on the 270X with this version, or maybe now they are read correctly. |
|
|
|
|
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!
|
|
|
|
Hi,
There is an issue with your miner.
The kernel cache created for the
Radeon 280X and Radeon 270X are created for monero with the same name: g9_CNV8_w16_f8_hm1_ha.srb
If you have a system which combines 280X and 270X cards, then you can't use both card, since the kernel generated for one type will fail on the other.
You should generate different kernels for the 280X and 270X. Thank you.
You are right, the whole GCN1 family is put under the same id (g9), i supposed that a pitcairn binary should work on a tahiti etc.it looks like it's not that way. I will separate them in the next version. Can you tell me how are speeds now with the Tahiti and Pitcairn, compared to other miners? It's a bit complicated with the speeds. I would say they definitely went up for most cards, the 270X has a massive boost, hashing now at 400H/s. The 280X is now hashing at around 440 H/s which is also an improvement. The 290 went down to 460H/s initially from 540H/s, but after some tweaking, it went up to 520 H/s. I only use R9 cards with your miner, the Vegas I have are mining ETH. There also seems to be an issue with the off-temperature this is a config example: { "id" : 0, "kernel": 1, "intensity" : 60, "worksize" : 16, "threads" : 1, "double_threads" : false, "target_temperature" : 90, "target_fan_speed": 2500, "off_temperature":90, "adl_type": 1}, But the miner still switches-off the video cards at 85C. Also, I'm not sure if the fan controls work well for Pitcairn cards, most of the time they read 0 rpm or somthing like 10000 rpm and don't seem to spin at all. |
|
|
|
|
Hi,
There is an issue with your miner.
The kernel cache created for the
Radeon 280X and Radeon 270X are created for monero with the same name: g9_CNV8_w16_f8_hm1_ha.srb
If you have a system which combines 280X and 270X cards, then you can't use both card, since the kernel generated for one type will fail on the other.
You should generate different kernels for the 280X and 270X. Thank you.
|
|
|
|
I can't seem to get this miner to work with 270X in combination with other 280X cards. So rig 1: 3 x R9 290 + 1 X 270X 2018-11-12 16:27:51] CPU AES-NI: TRUE
[2018-11-12 16:27:51] GPU0: AMD Radeon (TM) R9 200 Series [pitcairn] [2048 MB][I: 60.0][W: 8][T: 1][F: 4][A: 0][BUS: 6]
[2018-11-12 16:27:51] GPU1: AMD Radeon (TM) R9 200 Series [hawaii] [4096 MB][I: 60.0][W: 8][T: 1][F: 4][A: 0][BUS: 1]
[2018-11-12 16:27:51] GPU2: AMD Radeon (TM) R9 200 Series [hawaii] [4096 MB][I: 60.0][W: 8][T: 1][F: 4][A: 0][BUS: 2]
[2018-11-12 16:27:51] GPU3: AMD Radeon (TM) R9 200 Series [hawaii] [4096 MB][I: 60.0][W: 8][T: 1][F: 4][A: 0][BUS: 5]
[2018-11-12 16:27:51] ADL is enabled
[2018-11-12 16:27:51] Please use : Adrenalin 18.5.1, 18.5.2 or 18.6.1 drivers
[2018-11-12 16:27:51] CryptonightV8 mode enabled
[2018-11-12 16:27:51] Starting init of mining threads
[2018-11-12 16:27:51] Created OCL context
[2018-11-12 16:27:51] Using kernel 1 for DeviceID 0 (Thread 0)
[2018-11-12 16:27:51] Using AES 0 for DeviceID 0 (Thread 0)
[2018-11-12 16:27:51] Created OCL command queue for DeviceID 0 (Thread 0)
[2018-11-12 16:27:51] Created OCL input buffer for DeviceID 0 (Thread 0)
[2018-11-12 16:27:51] Created OCL output buffer for DeviceID 0 (Thread 0)
[2018-11-12 16:27:51] Loading normalv8 kernel for DEVICE BUS_ID[6] ...
[2018-11-12 16:27:51] ctx->Program for DeviceID 0 (Thread 0) loaded
[2018-11-12 16:27:51] Using kernel 1 for DeviceID 1 (Thread 1)
[2018-11-12 16:27:51] Using AES 0 for DeviceID 1 (Thread 1)
[2018-11-12 16:27:51] Created OCL command queue for DeviceID 1 (Thread 1)
[2018-11-12 16:27:51] Created OCL input buffer for DeviceID 1 (Thread 1)
[2018-11-12 16:27:51] Created OCL output buffer for DeviceID 1 (Thread 1)
[2018-11-12 16:27:51] Loading normalv8 kernel for DEVICE BUS_ID[1] ...
[2018-11-12 16:27:52] ctx->Program for DeviceID 1 (Thread 1) loaded
[2018-11-12 16:27:52] Using kernel 1 for DeviceID 2 (Thread 2)
[2018-11-12 16:27:52] Using AES 0 for DeviceID 2 (Thread 2)
[2018-11-12 16:27:52] Created OCL command queue for DeviceID 2 (Thread 2)
[2018-11-12 16:27:52] Created OCL input buffer for DeviceID 2 (Thread 2)
[2018-11-12 16:27:52] Created OCL output buffer for DeviceID 2 (Thread 2)
[2018-11-12 16:27:52] Loading normalv8 kernel for DEVICE BUS_ID[2] ...
[2018-11-12 16:27:52] ctx->Program for DeviceID 2 (Thread 2) loaded
[2018-11-12 16:27:52] Using kernel 1 for DeviceID 3 (Thread 3)
[2018-11-12 16:27:52] Using AES 0 for DeviceID 3 (Thread 3)
[2018-11-12 16:27:52] Created OCL command queue for DeviceID 3 (Thread 3)
[2018-11-12 16:27:52] Created OCL input buffer for DeviceID 3 (Thread 3)
[2018-11-12 16:27:52] Created OCL output buffer for DeviceID 3 (Thread 3)
[2018-11-12 16:27:52] Loading normalv8 kernel for DEVICE BUS_ID[5] ...
[2018-11-12 16:27:52] ctx->Program for DeviceID 3 (Thread 3) loaded
[2018-11-12 16:27:52] ADL initialised successfully!
So rig 2: 4 x 280X + 1 X 270X [2018-11-12 16:37:50] GPU0: AMD Radeon R9 200 Series [tahiti] [3072 MB][I: 60.0][W: 8][T: 1][F: 4][A: 0][BUS: 5]
[2018-11-12 16:37:50] GPU1: AMD Radeon R9 200 Series [tahiti] [3072 MB][I: 60.0][W: 8][T: 1][F: 4][A: 0][BUS: 7]
[2018-11-12 16:37:50] GPU2: AMD Radeon R9 200 Series [pitcairn] [2048 MB][I: 40.0][W: 8][T: 1][F: 4][A: 0][BUS: 2]
[2018-11-12 16:37:50] GPU3: AMD Radeon R9 200 Series [tahiti] [3072 MB][I: 60.0][W: 16][T: 1][F: 4][A: 0][BUS: 1]
[2018-11-12 16:37:50] GPU4: AMD Radeon R9 200 Series [tahiti] [3072 MB][I: 60.0][W: 16][T: 1][F: 4][A: 0][BUS: 6]
[2018-11-12 16:37:50] ADL is enabled
[2018-11-12 16:37:50] Please use : Adrenalin 18.5.1, 18.5.2 or 18.6.1 drivers
[2018-11-12 16:37:50] CryptonightV8 mode enabled
[2018-11-12 16:37:50] Starting init of mining threads
[2018-11-12 16:37:50] Created OCL context
[2018-11-12 16:37:50] Using kernel 1 for DeviceID 0 (Thread 0)
[2018-11-12 16:37:50] Using AES 0 for DeviceID 0 (Thread 0)
[2018-11-12 16:37:50] Created OCL command queue for DeviceID 0 (Thread 0)
[2018-11-12 16:37:50] Created OCL input buffer for DeviceID 0 (Thread 0)
[2018-11-12 16:37:50] Created OCL output buffer for DeviceID 0 (Thread 0)
[2018-11-12 16:37:50] Loading normalv8 kernel for DEVICE BUS_ID[5] ...
[2018-11-12 16:37:50] ctx->Program for DeviceID 0 (Thread 0) loaded
[2018-11-12 16:37:50] Using kernel 1 for DeviceID 1 (Thread 1)
[2018-11-12 16:37:50] Using AES 0 for DeviceID 1 (Thread 1)
[2018-11-12 16:37:50] Created OCL command queue for DeviceID 1 (Thread 1)
[2018-11-12 16:37:50] Created OCL input buffer for DeviceID 1 (Thread 1)
[2018-11-12 16:37:50] Created OCL output buffer for DeviceID 1 (Thread 1)
[2018-11-12 16:37:50] Loading normalv8 kernel for DEVICE BUS_ID[7] ...
[2018-11-12 16:37:50] ctx->Program for DeviceID 1 (Thread 1) loaded
[2018-11-12 16:37:50] Using kernel 1 for DeviceID 3 (Thread 2)
[2018-11-12 16:37:50] Using AES 0 for DeviceID 3 (Thread 2)
[2018-11-12 16:37:50] Created OCL command queue for DeviceID 3 (Thread 2)
[2018-11-12 16:37:50] Created OCL input buffer for DeviceID 3 (Thread 2)
[2018-11-12 16:37:50] Created OCL output buffer for DeviceID 3 (Thread 2)
[2018-11-12 16:37:50] Loading normalv8 kernel for DEVICE BUS_ID[2] ...
[2018-11-12 16:37:50] Error CL_BUILD_PROGRAM_FAILURE when calling clBuildProgram [ctx->Program] for DeviceID 3 (Thread 2)
[2018-11-12 16:37:50] Error initing GPU's. Stopping miner process
[2018-11-12 16:37:50] Stopping miner process
|
|
|
|
|
@Wolf0 and everyone else
Great work guys, I really thought the sgminer project was dead and I do remember Wolf saying it should be re-written from group-up (this was like 2 years ago).
We really need an open source miner like sgminer which can be easily adapted and modified with various kernels and features.
I tried the version you posted here and I got about 200 H/s from my 280X vs 295 HS/s with Claymore (Zcash) . Shame , I would have loved to use sgminer again, especially since I poked my nose in its original git as well.
|
|
|
|
Has anyone noticed that mining speed with the 380X is a lot lower than with the 280X ?
I get 200 on the 280X but only 140 on the 380X .
The 380X should be slower than the 280X. It only has 256 bit memory bus while the 280X has 384 bit. 280X was marketed as top end card. https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_unitsThat's very helpful! Thank you! |
|
|
|
|
