IOTUSA
|
|
February 22, 2017, 02:41:51 PM |
|
Sadly v12 and v12.1 are too unstable here (already tried to low intensity)...rig with 3x 7990 and 1x R9 295x2, under win10 with cat 15.12...other versions and optiminer run fine...
Can I mine dash with claymore? how ? I have 7990 and 280x some help will be appreciate!!! No Dash. That is minable with ASIC. Well you can, it just most likely will not be profitable at all.
|
|
|
|
IOTUSA
|
|
February 22, 2017, 02:44:47 PM |
|
I have an odd issue with V12.0/12.1 where I have 6 x 480 GPU's under Windows 10 x64 (latest anniversary release) and 16.9.x drivers. The miner will start with all cards running at 300h/s+ at standard intensity (6) but every single time after a few minutes the miner will drop one card to zero (0) hash. A little later the miner will crash.
I have tried swapping PCI slots, changing drivers, swapping risers etc. but it persists.
I also sometimes get 'faulty data' or 'incorrect data' and even OpenCL crash but it's more rare.
I'm running a 1300W EVGA PSU so it should be fine. Out of ideas.
|
|
|
|
Wandika
Sr. Member
Offline
Activity: 508
Merit: 250
In CryptoEnergy we trust
|
|
February 22, 2017, 03:09:09 PM |
|
Sadly v12 and v12.1 are too unstable here (already tried to low intensity)...rig with 3x 7990 and 1x R9 295x2, under win10 with cat 15.12...other versions and optiminer run fine...
Can I mine dash with claymore? how ? I have 7990 and 280x some help will be appreciate!!! No Dash. That is minable with ASIC. Well you can, it just most likely will not be profitable at all. That is right. It is better not to GPU mine dash.
|
|
|
|
IOTUSA
|
|
February 22, 2017, 04:08:34 PM |
|
Does anyone have hash-rate and power draw numbers for Sapphire Radeon 7950 3 GB ? (Stock)
|
|
|
|
ccccccc7
|
|
February 22, 2017, 04:10:02 PM |
|
Anybody done any tests on power draw for V12.1?
I woke up to a partly burned 6pin.
inb4 "stop blaming Claymore hur dur"
I am using Aerocool 1000w on x2 390 which is know is a pile of shit for mining
Already fucked 2 of the 4 pcie power cables with the same issue but this was due to overclock.
The issue is I now, after the above situation, set a heavy powerlimit restriction and undervolt which was fine through V9->V11
Looking now to either mine the PSU to death or sell it in a couple of months.
Anyone else stupid enough to buy Areostool PSU and could share experience?
|
|
|
|
Tamilson
|
|
February 22, 2017, 04:22:08 PM |
|
Anybody done any tests on power draw for V12.1?
I woke up to a partly burned 6pin.
inb4 "stop blaming Claymore hur dur"
I am using Aerocool 1000w on x2 390 which is know is a pile of shit for mining
Already fucked 2 of the 4 pcie power cables with the same issue but this was due to overclock.
The issue is I now, after the above situation, set a heavy powerlimit restriction and undervolt which was fine through V9->V11
Looking now to either mine the PSU to death or sell it in a couple of months.
Anyone else stupid enough to buy Areostool PSU and could share experience?
The 12.1 use about 2% more power than the 12.
|
Happy Coding Life
|
|
|
ccccccc7
|
|
February 22, 2017, 04:56:34 PM |
|
Doesn't account for damage.
Aeroshit must be on its last legs
Thanks
|
|
|
|
Assaro
Member
Offline
Activity: 114
Merit: 10
|
|
February 22, 2017, 05:29:27 PM |
|
I have an odd issue with V12.0/12.1 where I have 6 x 480 GPU's under Windows 10 x64 (latest anniversary release) and 16.9.x drivers. The miner will start with all cards running at 300h/s+ at standard intensity (6) but every single time after a few minutes the miner will drop one card to zero (0) hash. A little later the miner will crash.
I have tried swapping PCI slots, changing drivers, swapping risers etc. but it persists.
I also sometimes get 'faulty data' or 'incorrect data' and even OpenCL crash but it's more rare.
I'm running a 1300W EVGA PSU so it should be fine. Out of ideas.
had the same problem with 4x R9 390 rig. Had to go down with intensity (-i), to get it work... But finally i got to the -i 2 and on this point i went to version 12.0 (-i8) which is faster then v12.1 with -i 2..... next i went this rig on nicehash multialgo.... strange is that the GPU are cooler on ETH mining than on Zec ... (1-2 degrees but anyway.....)
|
|
|
|
jstefanop
Legendary
Offline
Activity: 2162
Merit: 1401
|
|
February 22, 2017, 06:57:41 PM |
|
Hmm so I can confirm there is some weird stuff going on with claymore v12 and polaris hash reporting. First shot is claymore 24h average v12.1 right before I switched to optiminer 1.6.2. Second is optiminer after 24 hours. Claymore reports exactly 2804 average hashrate miner side which should equal ~2750 poolside after dev fee is taken out. Poolside reports over 100mh less than that though. Optiminer reports 2734, which is exactly what pool is reporting at 2731 Whats more interesting is that Claymore on a 280x rig reports the exact hashrate minus fee that the pool reports. At first I thought this was either a pool/hashrate bug issue, but the fact that optiminer reports the correct hashrate, and the 280x rigs report correct with claymore. My guess is that either there is a bug with polaris hash reporting (i hope) or he couldn't reach optiminer performance on polaris, so he bumped his numbers by 5% to make it look like his miner is faster
|
|
|
|
Claymore (OP)
Donator
Legendary
Offline
Activity: 1610
Merit: 1325
Miners developer
|
|
February 22, 2017, 08:08:46 PM |
|
Hmm so I can confirm there is some weird stuff going on with claymore v12 and polaris hash reporting. First shot is claymore 24h average v12.1 right before I switched to optiminer 1.6.2. Second is optiminer after 24 hours. Claymore reports exactly 2804 average hashrate miner side which should equal ~2750 poolside after dev fee is taken out. Poolside reports over 100mh less than that though. Optiminer reports 2734, which is exactly what pool is reporting at 2731 Whats more interesting is that Claymore on a 280x rig reports the exact hashrate minus fee that the pool reports. At first I thought this was either a pool/hashrate bug issue, but the fact that optiminer reports the correct hashrate, and the 280x rigs report correct with claymore. My guess is that either there is a bug with polaris hash reporting (i hope) or he couldn't reach optiminer performance on polaris, so he bumped his numbers by 5% to make it look like his miner is faster 1. Hashrate is calculated in the same way for all cards, so Polaris cards cannot get different numbers related to 280X calculations. Your idea about adding 5% on polaris is wrong too. 2. You know I don't care about Linux much. In Windows you can easily see that my miner is the fastest for Polaris because the difference is significant; in Linux speeds must be similar. If you get bad numbers on pool and think that it's because of the miner, don't use it, you have a choice. My opinion: it's something related to pool calculation, for ZEC I always get more hashrate variations on pools side than for ETH mining.
|
|
|
|
fr4nkthetank
Legendary
Offline
Activity: 2294
Merit: 1182
Now the money is free, and so the people will be
|
|
February 22, 2017, 08:50:17 PM |
|
press "S" and see if you have any invalid shares. oh wait you cant see that in zec
|
|
|
|
jstefanop
Legendary
Offline
Activity: 2162
Merit: 1401
|
|
February 22, 2017, 10:43:01 PM |
|
Hmm so I can confirm there is some weird stuff going on with claymore v12 and polaris hash reporting. First shot is claymore 24h average v12.1 right before I switched to optiminer 1.6.2. Second is optiminer after 24 hours. Claymore reports exactly 2804 average hashrate miner side which should equal ~2750 poolside after dev fee is taken out. Poolside reports over 100mh less than that though. Optiminer reports 2734, which is exactly what pool is reporting at 2731 Whats more interesting is that Claymore on a 280x rig reports the exact hashrate minus fee that the pool reports. At first I thought this was either a pool/hashrate bug issue, but the fact that optiminer reports the correct hashrate, and the 280x rigs report correct with claymore. My guess is that either there is a bug with polaris hash reporting (i hope) or he couldn't reach optiminer performance on polaris, so he bumped his numbers by 5% to make it look like his miner is faster 1. Hashrate is calculated in the same way for all cards, so Polaris cards cannot get different numbers related to 280X calculations. Your idea about adding 5% on polaris is wrong too. 2. You know I don't care about Linux much. In Windows you can easily see that my miner is the fastest for Polaris because the difference is significant; in Linux speeds must be similar. If you get bad numbers on pool and think that it's because of the miner, don't use it, you have a choice. My opinion: it's something related to pool calculation, for ZEC I always get more hashrate variations on pools side than for ETH mining. Yes he hasn't optimized his polaris kernel under windows, so that makes sense. What does not make sense is that your miner reports a certain hashrate that is not matched on the pool. Your miner does not produce any invalid shares or errors so its not that, and the pool calculates shares the same way for both miners, so if it was calculating wrong for your shares it would be wrong for optimizer's shares as well (pool does not care where valid shares come from, calculation is simply #shares/time). Hash rate variation also is not it since this is a 24 hour average. The miner is simply submitting less shares to the pool than it *should* based on the hashrate calculated by your miner. So again either your hashrate calculation is wrong, or shares are "disappearing." The only explanation that would explain a correct hashrate calculation, but less "valid" shares being retuned by your kernel is that for your Polaris ASM implementation you have optimized it to the point that the theoretical solutions per iteration (which is what I'm assuming your hashrate calculation is based on), is slightly less than its supposed to be (i.e. 1.8 instead of 1.88).
|
|
|
|
Claymore (OP)
Donator
Legendary
Offline
Activity: 1610
Merit: 1325
Miners developer
|
|
February 22, 2017, 11:25:38 PM |
|
Miner does not use 1.88 factor in calculations, using it is a bad idea because it is theoretical factor and real implementation may be not so good. Therefore miner just counts all solutions found, and time that was spent. If algorithm implementation has a bug that causes 1.8 factor, it will cause less number of solutions and less calculated hashrate. So this idea is wrong. I still think it's related to pool. What pool do you use? I will put all my polaris cards to it and check 2-3 daily hashrates to see hashrate deviations.
|
|
|
|
jstefanop
Legendary
Offline
Activity: 2162
Merit: 1401
|
|
February 22, 2017, 11:54:24 PM |
|
Miner does not use 1.88 factor in calculations, using it is a bad idea because it is theoretical factor and real implementation may be not so good. Therefore miner just counts all solutions found, and time that was spent. If algorithm implementation has a bug that causes 1.8 factor, it will cause less number of solutions and less calculated hashrate. So this idea is wrong. I still think it's related to pool. What pool do you use? I will put all my polaris cards to it and check 2-3 daily hashrates to see hashrate deviations.
flypool
|
|
|
|
zzzzzzzzzz
|
|
February 23, 2017, 03:22:26 AM |
|
Miner does not use 1.88 factor in calculations, using it is a bad idea because it is theoretical factor and real implementation may be not so good. Therefore miner just counts all solutions found, and time that was spent. If algorithm implementation has a bug that causes 1.8 factor, it will cause less number of solutions and less calculated hashrate. So this idea is wrong. I still think it's related to pool. What pool do you use? I will put all my polaris cards to it and check 2-3 daily hashrates to see hashrate deviations.
flypool I mined on flypool for a long time with other miners (SA5, Optiminer), and the pool hash rate was equal to my raw hash rate at the miner. So, unless something has changed on the pool recently, I wouldn't think it's their calculations causing the discrepancy.
|
|
|
|
henz46
Newbie
Offline
Activity: 24
Merit: 0
|
|
February 23, 2017, 05:54:45 AM |
|
Miner does not use 1.88 factor in calculations, using it is a bad idea because it is theoretical factor and real implementation may be not so good. Therefore miner just counts all solutions found, and time that was spent. If algorithm implementation has a bug that causes 1.8 factor, it will cause less number of solutions and less calculated hashrate. So this idea is wrong. I still think it's related to pool. What pool do you use? I will put all my polaris cards to it and check 2-3 daily hashrates to see hashrate deviations.
i have same problem, F2pool.com 4x sapphire rx 470 4gb With v.12 miner show 1073 h/s, pool show 1000-1030 h/s (24-hrs-Hashrate) With v.12.1 miner show 1097 h/s, pool show 999-1006 h/s (24-hrs-Hashrate)
|
|
|
|
bitcoinsay
Sr. Member
Offline
Activity: 434
Merit: 255
Presale starts on 28th of April!
|
|
February 23, 2017, 06:37:56 AM |
|
The price was really low. But the speed of solving increased.
|
|
|
|
Vaculin
|
|
February 23, 2017, 06:57:34 AM |
|
The price was really low. But the speed of solving increased.
It is not so profitable.
|
|
|
|
micairvas
|
|
February 23, 2017, 09:09:04 AM |
|
What about support for NVidia cards and implementing in miner, do you maybe planning such thing? In that case we can mine with mixed Nvidia/Ati gpus at same rig?
|
|
|
|
Xiadas
Full Member
Offline
Activity: 322
Merit: 100
Blockchain Just Entered The Real World
|
|
February 23, 2017, 10:46:41 AM |
|
What about support for NVidia cards and implementing in miner, do you maybe planning such thing? In that case we can mine with mixed Nvidia/Ati gpus at same rig?
I do not think he has time to support Nvidia cards.
|
|
|
|
|