Bitcoin Forum
January 28, 2020, 10:00:39 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 [81] 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 »
  Print  
Author Topic: [ANN] TeamRedMiner 0.6.1 - Ethash/Cryptonight/Chukwa Thread  (Read 96581 times)
migo77
Newbie
*
Offline Offline

Activity: 23
Merit: 1


View Profile
June 13, 2019, 07:21:54 AM
Last edit: June 13, 2019, 09:15:42 AM by migo77
 #1601

I have the same problem on 4 rigs with 4 various Vega 56 cards (ref with samsun g and asus/powercolor with hynix, with timings and without timings ). The card runs for an hour or two and then the hash rate drops to zero or to 1400 h/s with a DEAD message. I have observed in several rigs, but for some reason problems always with the first PCI slot (PCIe 3:0.0). If you do not stick the card into the first PCI slot (PCI 16x), then the problem disappears. Now I just do not use 16x pci slot   Sad

Hi, interesting... for me it is GPU4 and it is located at PCIex16 slot too.

LnkSta:   Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
1580248839
Hero Member
*
Offline Offline

Posts: 1580248839

View Profile Personal Message (Offline)

Ignore
1580248839
Reply with quote  #2

1580248839
Report to moderator
1580248839
Hero Member
*
Offline Offline

Posts: 1580248839

View Profile Personal Message (Offline)

Ignore
1580248839
Reply with quote  #2

1580248839
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1580248839
Hero Member
*
Offline Offline

Posts: 1580248839

View Profile Personal Message (Offline)

Ignore
1580248839
Reply with quote  #2

1580248839
Report to moderator
lebuawu2
Jr. Member
*
Offline Offline

Activity: 176
Merit: 2


View Profile
June 13, 2019, 01:41:48 PM
 #1602

Hi Dev,

Why I often got this message :
Quote
Dev pool connection was closed due to an error.
Mining will proceed at reduced rate while not connected to dev pool.

but after sometime it will connect to dev pool :
Quote
Dev pool connected and ready.

is there any solution for this message?



Thanks.
kerney666
Member
**
Offline Offline

Activity: 532
Merit: 84


View Profile
June 13, 2019, 04:06:15 PM
 #1603

Hi Dev,

Why I often got this message :
Quote
Dev pool connection was closed due to an error.
Mining will proceed at reduced rate while not connected to dev pool.

but after sometime it will connect to dev pool :
Quote
Dev pool connected and ready.

is there any solution for this message?



Thanks.

Well, it should really only happen when we restart our servers, which isn't often at all. So, there's something else cutting the connection for you. In some cases there are home routers that cut connections, in other cases many countries/jurisdictions don't like neither SSL traffic nor mining traffic. May I ask where you're located? You can PM me if you want to. Also, I'd love to know what version of TRM you're running? We have noticed a higher degree of short-lived inbound connections lately, but can't explain why.

Rakly3
Newbie
*
Offline Offline

Activity: 44
Merit: 0


View Profile
June 13, 2019, 11:08:24 PM
 #1604

Well, it should really only happen when we restart our servers, which isn't often at all. So, there's something else cutting the connection for you. In some cases there are home routers that cut connections, in other cases many countries/jurisdictions don't like neither SSL traffic nor mining traffic. May I ask where you're located? You can PM me if you want to. Also, I'd love to know what version of TRM you're running? We have noticed a higher degree of short-lived inbound connections lately, but can't explain why.
people start autotune, notice they didn't set their own wallet and stop the miner? Just a thought.
There's an easy way to test if this is the case. set a minername in the batchfiles that come with the miner.
If they forgot to change the wallet, likely they didn't change the miner id either.
Rakly3
Newbie
*
Offline Offline

Activity: 44
Merit: 0


View Profile
June 13, 2019, 11:37:35 PM
 #1605

I have the same problem on 4 rigs with 4 various Vega 56 cards (ref with samsun g and asus/powercolor with hynix, with timings and without timings ). The card runs for an hour or two and then the hash rate drops to zero or to 1400 h/s with a DEAD message. I have observed in several rigs, but for some reason problems always with the first PCI slot (PCIe 3:0.0). If you do not stick the card into the first PCI slot (PCI 16x), then the problem disappears. Now I just do not use 16x pci slot   Sad

Hi, interesting... for me it is GPU4 and it is located at PCIex16 slot too.

LnkSta:   Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
I have the same problem on 4 rigs with 4 various Vega 56 cards (ref with samsun g and asus/powercolor with hynix, with timings and without timings ). The card runs for an hour or two and then the hash rate drops to zero or to 1400 h/s with a DEAD message. I have observed in several rigs, but for some reason problems always with the first PCI slot (PCIe 3:0.0). If you do not stick the card into the first PCI slot (PCI 16x), then the problem disappears. Now I just do not use 16x pci slot   Sad
All primary x16 slots on any motherboard always are uplink.
What hardware do you guys have? (only for the vega rigs)
H110 3da with latest bios (F25), Celeron G3900 (Skylake) all (2) cores enabled. igfx enabled as primary. and a vega 56 in every pcie slot (stock bios, but we've already established bios, settings and algo don't matter). Single channel & single bank 4Gb memstick Crucial.

For most of us TRM 4.4 seems to work normally although a teeny tiny bit slower, but it's still better than a whole card not running Smiley . 5.2 only just released, so can't say yet.
kamisama233
Newbie
*
Offline Offline

Activity: 34
Merit: 0


View Profile
June 14, 2019, 12:09:39 AM
 #1606

GPU 2: detected DEAD (13:00.0)

completely different card & bus now :/

I'm still using the stock bios btw. Different clockspeeds or voltages don't seem to impact it.
Timing level don't seem to matter either (driver setting, no mod) But I havn't tested for that specifically yet.

Hi! Even though I’m not replying to every message I’m always reading everything. I’m currently testing a few things and have gone through our full commit history from 0.4.4 and forward.

We have a few small bug fixes on the way out, but it’s impossible to tell if any of those are the underlying issue here. I’ll reach out to a few of you in pm to see if you can run some test builds. Would love to nail this, if possible.

hi, Dev, the network connection problem always cause the rig crash,

[2019-06-13 21:52:22] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 172.105.205.58.
[2019-06-13 21:52:30] Stats Uptime: 0 days, 05:58:08
[2019-06-13 21:52:30] GPU 0 [48C, fan 49%] cnr: 533.0 h/s, avg 530.7 h/s, pool 504.0 h/s a:203 r:0 hw:0
[2019-06-13 21:52:30] GPU 1 [49C, fan 39%] cnr: 539.2 h/s, avg 536.6 h/s, pool 525.9 h/s a:216 r:0 hw:0
[2019-06-13 21:52:30] GPU 2 [47C, fan 39%] cnr: 538.3 h/s, avg 533.8 h/s, pool 527.7 h/s a:212 r:0 hw:0
[2019-06-13 21:52:30] GPU 3 [52C, fan 39%] cnr: 543.6 h/s, avg 540.3 h/s, pool 551.6 h/s a:225 r:0 hw:0
[2019-06-13 21:52:30] GPU 4 [53C, fan 49%] cnr: 516.1 h/s, avg 513.2 h/s, pool 456.6 h/s a:182 r:0 hw:0
[2019-06-13 21:52:30] GPU 5 [45C, fan  0%] cnr: 520.5 h/s, avg 517.9 h/s, pool 542.8 h/s a:215 r:0 hw:0
[2019-06-13 21:52:30] Total                cnr: 3.191kh/s, avg 3.173kh/s, pool 3.109kh/s a:1253 r:0 hw:0
[2019-06-13 21:52:32] Pool asia.cryptonight-hub.miningpoolhub.com connect timed-out to address 172.105.205.58.
[2019-06-13 21:52:32] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 172.105.210.117.
[2019-06-13 21:52:42] Pool asia.cryptonight-hub.miningpoolhub.com connect timed-out to address 172.105.210.117.
[2019-06-13 21:52:42] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 139.162.46.14.
[2019-06-13 21:52:52] Pool asia.cryptonight-hub.miningpoolhub.com connect timed-out to address 139.162.46.14.

after several retries, success connect to the pool again

[2019-06-13 21:52:52] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 172.105.197.212.
[2019-06-13 21:52:52] Pool asia.cryptonight-hub.miningpoolhub.com successfully connected to address 172.105.197.212.
[2019-06-13 21:52:53] Pool asia.cryptonight-hub.miningpoolhub.com login succeeded.(1106 ms)
[2019-06-13 21:52:53] Pool asia.cryptonight-hub.miningpoolhub.com received new job. (job_id: 212828560336492)
[2019-06-13 21:52:53] Pool asia.cryptonight-hub.miningpoolhub.com set difficulty to 54564

but this make the rig crash, and restart,  is there any way to prevent this, thanks

[2019-06-13 21:55:44] Initializing GPU 0.
[2019-06-13 21:55:44] Watchdog thread starting.
[2019-06-13 21:55:44] API initialized on 0.0.0.0:522
[2019-06-13 21:55:44] Runtime Command Keys: h - help, s - stats, e - enable gpu, d - disable gpu, q - quit
[2019-06-13 21:55:44] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 172.105.210.117.
[2019-06-13 21:55:44] Dev pool connected and ready.
[2019-06-13 21:55:44] Initializing GPU 1.
[2019-06-13 21:55:45] Initializing GPU 2.
[2019-06-13 21:55:46] Initializing GPU 3.
[2019-06-13 21:55:47] Miner load at 0%, hashrates are not at max speed yet.
[2019-06-13 21:55:47] Initializing GPU 4.
[2019-06-13 21:55:48] Initializing GPU 5.
lebuawu2
Jr. Member
*
Offline Offline

Activity: 176
Merit: 2


View Profile
June 14, 2019, 12:31:13 AM
 #1607


Well, it should really only happen when we restart our servers, which isn't often at all. So, there's something else cutting the connection for you. In some cases there are home routers that cut connections, in other cases many countries/jurisdictions don't like neither SSL traffic nor mining traffic. May I ask where you're located? You can PM me if you want to. Also, I'd love to know what version of TRM you're running? We have noticed a higher degree of short-lived inbound connections lately, but can't explain why.


Hi Kerney,

I already PM you, please check your message.

Thanks.
netgeek3
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
June 14, 2019, 02:20:52 PM
Last edit: June 14, 2019, 02:44:05 PM by netgeek3
 #1608

I have the same problem on 4 rigs with 4 various Vega 56 cards (ref with samsun g and asus/powercolor with hynix, with timings and without timings ). The card runs for an hour or two and then the hash rate drops to zero or to 1400 h/s with a DEAD message. I have observed in several rigs, but for some reason problems always with the first PCI slot (PCIe 3:0.0). If you do not stick the card into the first PCI slot (PCI 16x), then the problem disappears. Now I just do not use 16x pci slot   Sad

I am using all 1x slots and am having the same behavior. I am seriously thinking that this is a driver compatibility issue with Win10 for a couple of reasons:

1) It is always (in my case) the first card enumerated on the PCIe bus
2) It doesn't matter what motherboard I'm using (have tried on 7 different)
3) Starting ANY other applications on the same system slows down ONLY the affected GPU, and it shouldn't affect anything, historically.
4) In digging through logs and in the rare cases of a BSOD, there are consistently "stuck thread" issues
5) This phenomenon is not isolated to TRM - I am having the same issue with SRB, Phoenix, Claymore and others

I did not have this problem with earlier builds, but since the latest Windows and AMD updates, I can't get rid of it. I have tried rolling back through every iteration all the way back to Blockchain drivers without success.

I should mention that I am using a mix of V64 and V56 cards in my rigs, but all have Samsung memory.
SigiSinatra
Newbie
*
Offline Offline

Activity: 44
Merit: 0


View Profile
June 14, 2019, 02:30:24 PM
 #1609

The best, the fastest and most stable AMD miner ever.
It works perfect on all supported algos.
kerney666
Member
**
Offline Offline

Activity: 532
Merit: 84


View Profile
June 14, 2019, 06:07:58 PM
 #1610

I have the same problem on 4 rigs with 4 various Vega 56 cards (ref with samsun g and asus/powercolor with hynix, with timings and without timings ). The card runs for an hour or two and then the hash rate drops to zero or to 1400 h/s with a DEAD message. I have observed in several rigs, but for some reason problems always with the first PCI slot (PCIe 3:0.0). If you do not stick the card into the first PCI slot (PCI 16x), then the problem disappears. Now I just do not use 16x pci slot   Sad

I am using all 1x slots and am having the same behavior. I am seriously thinking that this is a driver compatibility issue with Win10 for a couple of reasons:

1) It is always (in my case) the first card enumerated on the PCIe bus
2) It doesn't matter what motherboard I'm using (have tried on 7 different)
3) Starting ANY other applications on the same system slows down ONLY the affected GPU, and it shouldn't affect anything, historically.
4) In digging through logs and in the rare cases of a BSOD, there are consistently "stuck thread" issues
5) This phenomenon is not isolated to TRM - I am having the same issue with SRB, Phoenix, Claymore and others

I did not have this problem with earlier builds, but since the latest Windows and AMD updates, I can't get rid of it. I have tried rolling back through every iteration all the way back to Blockchain drivers without success.

I should mention that I am using a mix of V64 and V56 cards in my rigs, but all have Samsung memory.


Hi! Just curious, did you have time to test 0.5.2 yet? It has a first wave of changes that only aim to stabilize the miner. No real guarantees, only some changes that theoretically should be nicer to the hardware. Otherwise, I agree, we’re dealing with some very delicate issues, and the software/driver/hardware interaction here is not all hunky dory.
kerney666
Member
**
Offline Offline

Activity: 532
Merit: 84


View Profile
June 14, 2019, 06:08:44 PM
 #1611

The best, the fastest and most stable AMD miner ever.
It works perfect on all supported algos.

Thanks for the kind words, much appreciated!
kerney666
Member
**
Offline Offline

Activity: 532
Merit: 84


View Profile
June 14, 2019, 06:17:02 PM
 #1612

GPU 2: detected DEAD (13:00.0)

completely different card & bus now :/

I'm still using the stock bios btw. Different clockspeeds or voltages don't seem to impact it.
Timing level don't seem to matter either (driver setting, no mod) But I havn't tested for that specifically yet.

Hi! Even though I’m not replying to every message I’m always reading everything. I’m currently testing a few things and have gone through our full commit history from 0.4.4 and forward.

We have a few small bug fixes on the way out, but it’s impossible to tell if any of those are the underlying issue here. I’ll reach out to a few of you in pm to see if you can run some test builds. Would love to nail this, if possible.

hi, Dev, the network connection problem always cause the rig crash,

[2019-06-13 21:52:22] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 172.105.205.58.
[2019-06-13 21:52:30] Stats Uptime: 0 days, 05:58:08
[2019-06-13 21:52:30] GPU 0 [48C, fan 49%] cnr: 533.0 h/s, avg 530.7 h/s, pool 504.0 h/s a:203 r:0 hw:0
[2019-06-13 21:52:30] GPU 1 [49C, fan 39%] cnr: 539.2 h/s, avg 536.6 h/s, pool 525.9 h/s a:216 r:0 hw:0
[2019-06-13 21:52:30] GPU 2 [47C, fan 39%] cnr: 538.3 h/s, avg 533.8 h/s, pool 527.7 h/s a:212 r:0 hw:0
[2019-06-13 21:52:30] GPU 3 [52C, fan 39%] cnr: 543.6 h/s, avg 540.3 h/s, pool 551.6 h/s a:225 r:0 hw:0
[2019-06-13 21:52:30] GPU 4 [53C, fan 49%] cnr: 516.1 h/s, avg 513.2 h/s, pool 456.6 h/s a:182 r:0 hw:0
[2019-06-13 21:52:30] GPU 5 [45C, fan  0%] cnr: 520.5 h/s, avg 517.9 h/s, pool 542.8 h/s a:215 r:0 hw:0
[2019-06-13 21:52:30] Total                cnr: 3.191kh/s, avg 3.173kh/s, pool 3.109kh/s a:1253 r:0 hw:0
[2019-06-13 21:52:32] Pool asia.cryptonight-hub.miningpoolhub.com connect timed-out to address 172.105.205.58.
[2019-06-13 21:52:32] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 172.105.210.117.
[2019-06-13 21:52:42] Pool asia.cryptonight-hub.miningpoolhub.com connect timed-out to address 172.105.210.117.
[2019-06-13 21:52:42] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 139.162.46.14.
[2019-06-13 21:52:52] Pool asia.cryptonight-hub.miningpoolhub.com connect timed-out to address 139.162.46.14.

after several retries, success connect to the pool again

[2019-06-13 21:52:52] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 172.105.197.212.
[2019-06-13 21:52:52] Pool asia.cryptonight-hub.miningpoolhub.com successfully connected to address 172.105.197.212.
[2019-06-13 21:52:53] Pool asia.cryptonight-hub.miningpoolhub.com login succeeded.(1106 ms)
[2019-06-13 21:52:53] Pool asia.cryptonight-hub.miningpoolhub.com received new job. (job_id: 212828560336492)
[2019-06-13 21:52:53] Pool asia.cryptonight-hub.miningpoolhub.com set difficulty to 54564

but this make the rig crash, and restart,  is there any way to prevent this, thanks

[2019-06-13 21:55:44] Initializing GPU 0.
[2019-06-13 21:55:44] Watchdog thread starting.
[2019-06-13 21:55:44] API initialized on 0.0.0.0:522
[2019-06-13 21:55:44] Runtime Command Keys: h - help, s - stats, e - enable gpu, d - disable gpu, q - quit
[2019-06-13 21:55:44] Pool asia.cryptonight-hub.miningpoolhub.com connecting to address 172.105.210.117.
[2019-06-13 21:55:44] Dev pool connected and ready.
[2019-06-13 21:55:44] Initializing GPU 1.
[2019-06-13 21:55:45] Initializing GPU 2.
[2019-06-13 21:55:46] Initializing GPU 3.
[2019-06-13 21:55:47] Miner load at 0%, hashrates are not at max speed yet.
[2019-06-13 21:55:47] Initializing GPU 4.
[2019-06-13 21:55:48] Initializing GPU 5.

Hmm, the intention is that the miner should use the same ramp-up logic as we use at start-up when a pool has been disconnected, this in order to not kill the PSU by going from 0-100% load on all GPUs at the same time. I can't say I have tested it lately though, and I can't say for sure that this is the issue here. It's a good guess though, no real reason why the rig would croak otherwise. I will do some tests.
Rakly3
Newbie
*
Offline Offline

Activity: 44
Merit: 0


View Profile
June 14, 2019, 06:40:13 PM
Last edit: June 15, 2019, 02:31:41 AM by Rakly3
 #1613

Hi! Just curious, did you have time to test 0.5.2 yet? It has a first wave of changes that only aim to stabilize the miner. No real guarantees, only some changes that theoretically should be nicer to the hardware. Otherwise, I agree, we’re dealing with some very delicate issues, and the software/driver/hardware interaction here is not all hunky dory.
Still running! Smiley
https://i.ibb.co/FgjLTWJ/Untitled.png

edit: 1d 4hours on 5.2 and still no dead GPU. I guess we can call it fixed! (?)
HughHashner
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
June 15, 2019, 02:36:01 AM
 #1614

I have 1 Vega 56 that was previously crashing 2-3x per day while my other Vegas chugged along. Since flipping to 0.5.2 yesterday I have not had a single crash.
No changes to OC or mem timings.
Cheers toddxx!!
Beruang123
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
June 15, 2019, 04:54:21 AM
 #1615

I have the same problem on 4 rigs with 4 various Vega 56 cards (ref with samsun g and asus/powercolor with hynix, with timings and without timings ). The card runs for an hour or two and then the hash rate drops to zero or to 1400 h/s with a DEAD message. I have observed in several rigs, but for some reason problems always with the first PCI slot (PCIe 3:0.0). If you do not stick the card into the first PCI slot (PCI 16x), then the problem disappears. Now I just do not use 16x pci slot   Sad

I am using all 1x slots and am having the same behavior. I am seriously thinking that this is a driver compatibility issue with Win10 for a couple of reasons:

1) It is always (in my case) the first card enumerated on the PCIe bus
2) It doesn't matter what motherboard I'm using (have tried on 7 different)
3) Starting ANY other applications on the same system slows down ONLY the affected GPU, and it shouldn't affect anything, historically.
4) In digging through logs and in the rare cases of a BSOD, there are consistently "stuck thread" issues
5) This phenomenon is not isolated to TRM - I am having the same issue with SRB, Phoenix, Claymore and others

I did not have this problem with earlier builds, but since the latest Windows and AMD updates, I can't get rid of it. I have tried rolling back through every iteration all the way back to Blockchain drivers without success.

I should mention that I am using a mix of V64 and V56 cards in my rigs, but all have Samsung memory.


Hi! Just curious, did you have time to test 0.5.2 yet? It has a first wave of changes that only aim to stabilize the miner. No real guarantees, only some changes that theoretically should be nicer to the hardware. Otherwise, I agree, we’re dealing with some very delicate issues, and the software/driver/hardware interaction here is not all hunky dory.

Apparently the new release didnot fix the issue.. still have the same error

https://imgur.com/a/GraVN7H?desktop=1
kerney666
Member
**
Offline Offline

Activity: 532
Merit: 84


View Profile
June 15, 2019, 07:46:45 AM
 #1616

I have the same problem on 4 rigs with 4 various Vega 56 cards (ref with samsun g and asus/powercolor with hynix, with timings and without timings ). The card runs for an hour or two and then the hash rate drops to zero or to 1400 h/s with a DEAD message. I have observed in several rigs, but for some reason problems always with the first PCI slot (PCIe 3:0.0). If you do not stick the card into the first PCI slot (PCI 16x), then the problem disappears. Now I just do not use 16x pci slot   Sad

I am using all 1x slots and am having the same behavior. I am seriously thinking that this is a driver compatibility issue with Win10 for a couple of reasons:

1) It is always (in my case) the first card enumerated on the PCIe bus
2) It doesn't matter what motherboard I'm using (have tried on 7 different)
3) Starting ANY other applications on the same system slows down ONLY the affected GPU, and it shouldn't affect anything, historically.
4) In digging through logs and in the rare cases of a BSOD, there are consistently "stuck thread" issues
5) This phenomenon is not isolated to TRM - I am having the same issue with SRB, Phoenix, Claymore and others

I did not have this problem with earlier builds, but since the latest Windows and AMD updates, I can't get rid of it. I have tried rolling back through every iteration all the way back to Blockchain drivers without success.

I should mention that I am using a mix of V64 and V56 cards in my rigs, but all have Samsung memory.


Hi! Just curious, did you have time to test 0.5.2 yet? It has a first wave of changes that only aim to stabilize the miner. No real guarantees, only some changes that theoretically should be nicer to the hardware. Otherwise, I agree, we’re dealing with some very delicate issues, and the software/driver/hardware interaction here is not all hunky dory.

Apparently the new release didnot fix the issue.. still have the same error



Ah interesting! You see, I didn’t make the same small stabilizing adjustments in the main 4MB variant kernels. Obviously I should have, my mistake, I simply forgot. Will try fix them as well very soon and will let you know when a release is available.
todxx
Member
**
Offline Offline

Activity: 163
Merit: 65


View Profile
June 15, 2019, 09:25:08 AM
 #1617

I have 1 Vega 56 that was previously crashing 2-3x per day while my other Vegas chugged along. Since flipping to 0.5.2 yesterday I have not had a single crash.
No changes to OC or mem timings.
Cheers toddxx!!

Glad to hear it's running smoother Smiley
You should send your praise in Kerney666's direction though, he's been the one fighting these issues over the last few days.
HughHashner
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
June 15, 2019, 01:20:50 PM
 #1618

I have 1 Vega 56 that was previously crashing 2-3x per day while my other Vegas chugged along. Since flipping to 0.5.2 yesterday I have not had a single crash.
No changes to OC or mem timings.
Cheers toddxx!!

Glad to hear it's running smoother Smiley
You should send your praise in Kerney666's direction though, he's been the one fighting these issues over the last few days.

Much love to Kerney666, too!
pigfrown
Jr. Member
*
Offline Offline

Activity: 47
Merit: 1


View Profile
June 15, 2019, 04:37:42 PM
 #1619

I saw in the release notes that Tonga support has been added, so I tried the latest version (0.5.2) with a Tonga card (r9 380 4GB) but get the following error on startup:


Failed to initialise device idx 3 (-13)


Is this card supported? Or is extra config required for Tonga?



08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] (rev f1)




Bitrated user: pigfrown.
Iamtutut
Member
**
Offline Offline

Activity: 700
Merit: 86


View Profile
June 15, 2019, 05:17:07 PM
 #1620

I saw in the release notes that Tonga support has been added, so I tried the latest version (0.5.2) with a Tonga card (r9 380 4GB) but get the following error on startup:


Failed to initialise device idx 3 (-13)


Is this card supported? Or is extra config required for Tonga?



08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] (rev f1)





I have the same issue on all CN algos except turtlecoin when I launch TRM while any web browser is opened (be Firefox, brave, Edge).
Pages: « 1 ... 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 [81] 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!