Search content
Sort by
Showing 13 of 13 results by TimLev
Re: [ANN] AceMiner Fast Grin Mimblewimble Cuckoo cycle miner for AMD/Nvidia
They also lie about speed improvement, their binary blob of the solver has same sha256 hash as the GGM original they took it from.
I have checked hashes of Aceminer 1.1 and GrinGoldMiner RC4 & RC3
Ace
CudaSolver.dll SHA-1 A7F056318A228DD71990065B8DE3940DB225F2B1
CudaSolver.exe SHA-1 FEC6267E23FCC1E82441AD4EB54A35757EFCBE5A
OclSolver.dll SHA-1 469020E11153EBCF0D84BF7F94E6547B5EE264C8
OclSolver.exe SHA-1 E25A9F84D222CC975EBBB5C431CF61A7DCF9D07C
GrinGold RC4&RC3
CudaSolver.dll SHA-1 AE3A2F5246C40DB5F824985FE2752E415F9322CC
CudaSolver.exe SHA-1 D0D1BF4D98D9819BA68896FD4EFF19A948091B8D
OclSolver.dll SHA-1 7D9E2C2B88828B7ED96B78BDB5D10C9462A8E32A
OclSolver.exe SHA-1 0C4EFC58850D04D87F4CB310CCACB38DE5EFFE9F
I don't think they are the same.
The guys always said (in discord chats) that their miner is the fork of GGM and grinminer with some improvements.
This is the idea of open source: anyone can take the code and improve upon it.
Urza, you're shilling your own miner which shows lower hashrates and where you want 2% share. I didn't understand, why it is better than Ace miner?
Re: [ANN] AceMiner Fast Grin Mimblewimble Cuckoo cycle miner for AMD/Nvidia
Mining speed:
Nvidia driver 416.34
[v 1.3]
1060 (+100 0 101W) - 2,2 gps
1070Ti (+100 0 145W) - 3,4 gps
1080 (+100 0 150W) - 3,9 gps
1080Ti (+100 0 210W) - 4,85 gps
1080Ti (+100 0 155W) - 4,6 gps
AMD adrenaline 18.6.1
[v 1.1]
RX570 8Gb (cc:1340 mc:1750) - 1,7 gps
RX480 8Gb (cc:1330 mc:2000) - 1,9 gps
(Celeron 3930, 4Gb RAM)
Nvidia driver 416.34
[v 1.3]
1060 (+100 0 101W) - 2,2 gps
1070Ti (+100 0 145W) - 3,4 gps
1080 (+100 0 150W) - 3,9 gps
1080Ti (+100 0 210W) - 4,85 gps
1080Ti (+100 0 155W) - 4,6 gps
AMD adrenaline 18.6.1
[v 1.1]
RX570 8Gb (cc:1340 mc:1750) - 1,7 gps
RX480 8Gb (cc:1330 mc:2000) - 1,9 gps
(Celeron 3930, 4Gb RAM)
Are you overclocking ?
No, using stock cards.
Anyone else have a 'GPU #0 returned incorrect data!' error? Happens on GPU #0, 1 of my 4 Saphhire R9 280xs, after about 6 hours of mining. It's always the same GPU returning the error, while the others are fine.
Had such happiness with one card. In my case, solution was a significant drop in temperature. Probably some radio elements lost characteristics with age and at high temperature becomes unstable.
What temps did you have before/after? My GPUs are hashing at around 68-74 C.
>72 C - incorrect data, <63 C - correct data
But this is strictly individual.Interesting fact: after modification timings Gigabyte HD7950 gives stable ~330H/s with 1% rejected. (1190/1470) - Pic 1
If increase mem frequency up to 1500, GPU gives ~361 H/s. But about 15% of rejected. In log file appears strings of buffer overflow. - Pic 2
https://yadi.sk/i/SHGnaZM739jvER
Pic 1
https://yadi.sk/i/dRQtFiZW39jvLu
Pic 2
What does this buffer overflow mean ? Obviously, hashrate indexes is not very accurate ?
If increase mem frequency up to 1500, GPU gives ~361 H/s. But about 15% of rejected. In log file appears strings of buffer overflow. - Pic 2
https://yadi.sk/i/SHGnaZM739jvER
Pic 1
https://yadi.sk/i/dRQtFiZW39jvLu
Pic 2
What does this buffer overflow mean ? Obviously, hashrate indexes is not very accurate ?
What voltage do you have to overvolt to get it stable at 1190 Mhz core?
Stock voltage, 1.195V. For 5 years, since Litecoin, no problems. Gigabyte Windforce.
Interesting, what's "solutions buf overflow" mean ? If the author made logging, and it turned on by default, would be great to understand the data.
Anyone else have a 'GPU #0 returned incorrect data!' error? Happens on GPU #0, 1 of my 4 Saphhire R9 280xs, after about 6 hours of mining. It's always the same GPU returning the error, while the others are fine.
Had such happiness with one card. In my case, solution was a significant drop in temperature. Probably some radio elements lost characteristics with age and at high temperature becomes unstable.
Interesting fact: after modification timings Gigabyte HD7950 gives stable ~330H/s with 1% rejected. (1190/1470) - Pic 1
If increase mem frequency up to 1500, GPU gives ~361 H/s. But about 15% of rejected. In log file appears strings of buffer overflow. - Pic 2
https://yadi.sk/i/SHGnaZM739jvER
Pic 1
https://yadi.sk/i/dRQtFiZW39jvLu
Pic 2
What does this buffer overflow mean ? Obviously, hashrate indexes is not very accurate ?
If increase mem frequency up to 1500, GPU gives ~361 H/s. But about 15% of rejected. In log file appears strings of buffer overflow. - Pic 2
https://yadi.sk/i/SHGnaZM739jvER
Pic 1
https://yadi.sk/i/dRQtFiZW39jvLu
Pic 2
What does this buffer overflow mean ? Obviously, hashrate indexes is not very accurate ?
So 15.12 is more stable?
Yes, 15.12 works perfectly. 0 crashes on win 10.
@Claymore
Rig 6xR9 390 1150/1500
v.1.0 - v.8.0 - 0 crashes for all the time.
v.9.0/9.1 crashes each 10-15 min, various GPUs. (any -i value)
Something is wrong with this version.
Rollback on v.8 returns stability.
Rig 6xR9 390 1150/1500
v.1.0 - v.8.0 - 0 crashes for all the time.
v.9.0/9.1 crashes each 10-15 min, various GPUs. (any -i value)
Something is wrong with this version.
Rollback on v.8 returns stability.
Again and again.
Problems can be:
1. PSU wattage load
2. PSU ripple suppression
3. PSU voltage regulation at different load variations
4. Bad risers and other cables. (Least likely if still working in other versions)
5. Incorrectly configuring windows
Answer to myself, maybe be helpful for someone.
The problem was in Radeon driver. If all of previous versions worked fine with v. 16.10 (including Claymore's ethereum miner), the version 9/9.1 in some configurations (including my 6xR9 390) works only* with drivers v. 15.12.
For sporting interest, made few clean re-installation to purity of the findings.
310 h/s from 1 GPU (-i 8 ) now.
2. Tips in 1-5 - utter nonsense and completely useless demagoguery. Only misleads readers.
@Claymore
Rig 6xR9 390 1150/1500
v.1.0 - v.8.0 - 0 crashes for all the time.
v.9.0/9.1 crashes each 10-15 min, various GPUs. (any -i value)
Something is wrong with this version.
Rollback on v.8 returns stability.
Rig 6xR9 390 1150/1500
v.1.0 - v.8.0 - 0 crashes for all the time.
v.9.0/9.1 crashes each 10-15 min, various GPUs. (any -i value)
Something is wrong with this version.
Rollback on v.8 returns stability.
Re: Claymore's Dual Ethereum+Decred/Siacoin GPU Miner v5.3 (Windows/Linux)
Hello, Claymore!
I am not an Englishman, so I apologize for the language in advance.
Regularly one card in rig starts to continuously get incorrect shares. It can work 3-5-10 days 24/7 with no problem, and suddenly all the shares are incorrect: "GPU #2 got incorrect share. If you see this warning often, make sure you did not overclock it too much!"
Overclocked or not does not matter, the same result. After rebooting begins to work well next period.
Would be very good if the miner will be have watchdog option: if 9 of 10 last shares from one card are incorrect, then execute reboot.bat.
(Rig configuration: 2x Sapphire Nitro R9 390, 2x Gigabyte R9 290 3X, 1x Sapphire R9 290 3X, MB GIGABYTE GA-X38-DS4, Win 10, Crimson 15.12, Claymore's miner 5.1 beta, Eth only) (GPU #2 - Gigabyte R9 290 3X 1040/1250)
I am not an Englishman, so I apologize for the language in advance.
Regularly one card in rig starts to continuously get incorrect shares. It can work 3-5-10 days 24/7 with no problem, and suddenly all the shares are incorrect: "GPU #2 got incorrect share. If you see this warning often, make sure you did not overclock it too much!"
Overclocked or not does not matter, the same result. After rebooting begins to work well next period.
Would be very good if the miner will be have watchdog option: if 9 of 10 last shares from one card are incorrect, then execute reboot.bat.
(Rig configuration: 2x Sapphire Nitro R9 390, 2x Gigabyte R9 290 3X, 1x Sapphire R9 290 3X, MB GIGABYTE GA-X38-DS4, Win 10, Crimson 15.12, Claymore's miner 5.1 beta, Eth only) (GPU #2 - Gigabyte R9 290 3X 1040/1250)