Search content
Sort by
Showing 20 of 52 results by biospb
Next time it will be welcome if you refer who made the change of the motd … lot more mods I have, but if this is the politic of HiveOS I think is better to have it internal…
and motd should be configured right…
and motd should be configured right…
Next time write your own motd and then mod it as you like
Re: PhoenixMiner 5.1c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
Bug in Phoenixminer 5.1c - after loosing connection it is still mining on gpu consuming power and finding shares
GPUs power: 600.4 W
Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
Eth: Could not connect to ethash pool eu1.ethermine.org:4444: Connection refused
Eth: Reconnecting in 5 seconds...
Unable to submit ethash share - pool disconnected
Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
Eth: Could not connect to ethash pool eu1.ethermine.org:4444: Connection refused
Eth: Reconnecting in 5 seconds...
Unable to submit ethash share - pool disconnected
Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
Eth: Could not connect to ethash pool eu1.ethermine.org:4444: Connection refused
Eth: Reconnecting in 5 seconds...
Unable to submit ethash share - pool disconnected
Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
Eth: Could not connect to ethash pool eu1.ethermine.org:4444: Connection refused
Eth: Reconnecting in 5 seconds...
Unable to submit ethash share - pool disconnected
GPUs power: 600.4 W
Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
Eth: Could not connect to ethash pool eu1.ethermine.org:4444: Connection refused
Eth: Reconnecting in 5 seconds...
Unable to submit ethash share - pool disconnected
Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
Eth: Could not connect to ethash pool eu1.ethermine.org:4444: Connection refused
Eth: Reconnecting in 5 seconds...
Unable to submit ethash share - pool disconnected
Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
Eth: Could not connect to ethash pool eu1.ethermine.org:4444: Connection refused
Eth: Reconnecting in 5 seconds...
Unable to submit ethash share - pool disconnected
Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
Eth: Could not connect to ethash pool eu1.ethermine.org:4444: Connection refused
Eth: Reconnecting in 5 seconds...
Unable to submit ethash share - pool disconnected
Re: AMD Mem Tweak XL - Read/modify timings/pp/straps on the fly
NOTHING CONCLUSIVE--
I tried reading the several threads that I found after searching earlier posts in this thread concerning user-modded 5700 series AMD graphics cards. The user claiming to be attempting BIOS mods and uploading them with ATIflash has poor English or is deliberately using LOLcat-speak. Nothing posted is legible enough to make sense.
Other long-time gurus explained that that the latest AMD cards have encrypted and signed BIOS. The Navi series won't accept a BIOS flash the way Polaris and earlier cards will.
If you can point me to a legible post or review explaining how to alter a Navi BIOS and flash it, please do.
--scryptr
I tried reading the several threads that I found after searching earlier posts in this thread concerning user-modded 5700 series AMD graphics cards. The user claiming to be attempting BIOS mods and uploading them with ATIflash has poor English or is deliberately using LOLcat-speak. Nothing posted is legible enough to make sense.
Other long-time gurus explained that that the latest AMD cards have encrypted and signed BIOS. The Navi series won't accept a BIOS flash the way Polaris and earlier cards will.
If you can point me to a legible post or review explaining how to alter a Navi BIOS and flash it, please do.
--scryptr
Of course they can...even before 5600, you could flash 5700 with 5700XT bios...but all of those are AMD-made, already signed
bios-es. Flashing is not a problem, but signing
bios-es. Flashing is not a problem, but signing
search for atiflash293plus
Re: AMD Mem Tweak XL - Read/modify timings/pp/straps on the fly
So not sure what you're trying to say here.
that flashing custom bios is possible
Re: PhoenixMiner 4.8c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
Hi, PhoenixMiner!
Merry Christmas and Happy new year!
It seems that Nvidia kernel optimizations for lower power consumption no longer work for last DAG epochs so it is needed to increase core clock or PL again and again to get the same hashrate.
Please take a look if it can be done again.
btw, 440 series nvidia drivers are greatly optimized in terms of irq/queue performance, producing twice less LA on heavy gpu usage. and new cuda 10.2 also.
Next problem - when mining is resumed after reaching tstop/tstart gpu quite often get stuck after few such cycles. Can resuming be done more smooth from low intensity and step by step increasing to target?
Also intensity can be reduced in advance when getting close to tstop temp.
And what about gt auto-tuning not from 0, but from defined gt values? it will take much less time and be more accurate. so there will be no need to set exact values every time oveclocking is changed for one of gpus.
it can be a problem as auto-tuning runs after each stop/resume cycle and can take longer than reaching tstop temp again)
Thanks in advance!
Merry Christmas and Happy new year!
It seems that Nvidia kernel optimizations for lower power consumption no longer work for last DAG epochs so it is needed to increase core clock or PL again and again to get the same hashrate.
Please take a look if it can be done again.
btw, 440 series nvidia drivers are greatly optimized in terms of irq/queue performance, producing twice less LA on heavy gpu usage. and new cuda 10.2 also.
Next problem - when mining is resumed after reaching tstop/tstart gpu quite often get stuck after few such cycles. Can resuming be done more smooth from low intensity and step by step increasing to target?
Also intensity can be reduced in advance when getting close to tstop temp.
And what about gt auto-tuning not from 0, but from defined gt values? it will take much less time and be more accurate. so there will be no need to set exact values every time oveclocking is changed for one of gpus.
it can be a problem as auto-tuning runs after each stop/resume cycle and can take longer than reaching tstop temp again)
Thanks in advance!
Re: GMiner v1.88 Equihash(BEAM, BTG)/CuckooCycle(AE, GRIN)/Ethash/Eaglesong/Blake2s
and what algo have you been testing?
GRIN31, of courseRe: GMiner v1.88 Equihash(BEAM, BTG)/CuckooCycle(AE, GRIN)/Ethash/Eaglesong/Blake2s
tested 1.88 version on GRIN31
13xP1070Ti: reported - 13.2, avg on sparkpool - 12.5 (~3% stales). difference is about 5% = devfee + stales
13xP104 8g: reported - 11.9, avg on sparkpool - 10.6 (~4% stales). difference is about 11%!!
13xP1070Ti: reported - 13.2, avg on sparkpool - 12.5 (~3% stales). difference is about 5% = devfee + stales
13xP104 8g: reported - 11.9, avg on sparkpool - 10.6 (~4% stales). difference is about 11%!!
Re: GMiner v1.83 Equihash(BEAM, BTG)/CuckooCycle(AE, GRIN)/Ethash/Eaglesong
P104-100s have 10+% slower C31 hashrate with 1.85.
confirmed
Re: PhoenixMiner 4.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
second thing that can be easily fixed - auto-tuning is quite slow and it is running after gpu temp reaching its limit. every time!
there is no need for this. just use gt values found during startup.
It is deliberately "slow" (it takes 3-5 minutes on average) in order to get repeatable and reliable results. If the auto-tuning is significantly faster, we will be taking less measurements and as a result the "best" GT found may not be optimal. To avoid the problem you are running into, you can run auto-tune again after the temperatures has stabilized. In order to do that, you need to press the 'z' in the miner console window.there is no need for this. just use gt values found during startup.
no, i am not complaining about its slowness.
the problem is that if gt is not set, auto-tune runs every time gpu starts mining after reaching temp limit.
so, instead of start running at 33MH with already found gt value, gpu starts at 26MH and when it reaches 33 after few minutes, it can reach temp limit again and stop mining.
yes, that is not normal in long term usage, but when it is too hot you have no so many choices.
btw, what do think about starting auto-tuning not from 0 but from user-defined value?
so if most of gpus have the same +/- 1 gt value, you can set, for example, -gt 15, and auto-tuning will try higher and lower values for best performance, and it will take much less time to complete.
Re: PhoenixMiner 4.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
PhoenixMiner
Please fix support for newer drivers on linux - 19.10, 19.20.
currently miner uses -clnew 0 regardless of clkernel setting.
probably all these kernels can work if there was no check for driver version.
second thing that can be easily fixed - auto-tuning is quite slow and it is running after gpu temp reaching its limit. every time!
there is no need for this. just use gt values found during startup.
thanks in advance
Please fix support for newer drivers on linux - 19.10, 19.20.
currently miner uses -clnew 0 regardless of clkernel setting.
probably all these kernels can work if there was no check for driver version.
second thing that can be easily fixed - auto-tuning is quite slow and it is running after gpu temp reaching its limit. every time!
there is no need for this. just use gt values found during startup.
thanks in advance
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v14.6 (Windows/Linux)
It seems drivers are unstable at this number of cards.
If 11.9 works fine you can try to add "-eres 2" option, miner will use old-style DAG generation (since v12 it tries to reduce GPU memory used for DAG in most cases, non-zero "-eres" option value disables it).
If 11.9 works fine you can try to add "-eres 2" option, miner will use old-style DAG generation (since v12 it tries to reduce GPU memory used for DAG in most cases, non-zero "-eres" option value disables it).
yes! -eres 2 make it work! only LA is relatively high. but anyway thanks for advise!!!
btw, in first post it is written that it is default option:
Quote
-eres this setting is related to Ethereum mining stability. Every next Ethereum epoch requires a bit more GPU memory, miner can crash during reallocating GPU buffer for new DAG.
To avoid it, miner reserves a bit larger GPU buffer at startup, so it can process several epochs without buffer reallocation.
This setting defines how many epochs miner must foresee when it reserves GPU buffer, i.e. how many epochs will be processed without buffer reallocation. Default value is 2.
To avoid it, miner reserves a bit larger GPU buffer at startup, so it can process several epochs without buffer reallocation.
This setting defines how many epochs miner must foresee when it reserves GPU buffer, i.e. how many epochs will be processed without buffer reallocation. Default value is 2.
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v14.6 (Windows/Linux)
Thanks, I had a good laugh here 
Unfortunately, I don't have 13 p104 cards to test it. So 12 cards work fine and 13 fail, right? There is no difference for miner if you use 12 or 13 cards so it must be something else, try "-gser 2" option to see if it helps.
Unfortunately, I don't have 13 p104 cards to test it. So 12 cards work fine and 13 fail, right? There is no difference for miner if you use 12 or 13 cards so it must be something else, try "-gser 2" option to see if it helps.
hmm, yes. 12 cards are working. you definitely do not like this number)
and 13 with with -gser 2 option, too. but very slow startup.
with -gser 1 does not. and I found in syslog this
Code:
[27382.925779] Out of memory: Kill process 10880 (ethdcrminer64) score 684 or sacrifice child
[27382.925822] Killed process 10880 (ethdcrminer64) total-vm:321404352kB, anon-rss:1346268kB, file-rss:1308172kB, shmem-rss:133120kB
[27382.948105] oom_reaper: reaped process 10880 (ethdcrminer64), now anon-rss:0kB, file-rss:1313400kB, shmem-rss:133120kB
sorry, forgot to take a look there earlier[27382.925822] Killed process 10880 (ethdcrminer64) total-vm:321404352kB, anon-rss:1346268kB, file-rss:1308172kB, shmem-rss:133120kB
[27382.948105] oom_reaper: reaped process 10880 (ethdcrminer64), now anon-rss:0kB, file-rss:1313400kB, shmem-rss:133120kB
hope this help to trace the problem
v11.9 also works without -gser.
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v14.6 (Windows/Linux)
That's a lot of p104s....
Shhh! He do not like this number
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v14.6 (Windows/Linux)
Hi, Claymore
the bug with P104 on linux with 418 & 430 drivers still present.
please fix it. the last working version is 11.9.
miner kills itself after starting to create gpu buffer
https://postimg.cc/XrY10Fws
the bug with P104 on linux with 418 & 430 drivers still present.
please fix it. the last working version is 11.9.
miner kills itself after starting to create gpu buffer
https://postimg.cc/XrY10Fws
Re: PhoenixMiner 4.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
Please add support for amgpu-pro driver 19.10
miner works, but during autotuning it spams log for about 3 minutes
Code:
2019.06.08:22:16:06.134: main Phoenix Miner 4.2c Linux/gcc - Release build
2019.06.08:22:16:06.138: main Unable to enum CUDA GPUs: no CUDA-capable device is detected
2019.06.08:22:16:06.240: main Unknown OpenCL driver version! Hashrate and stale shares may suffer
2019.06.08:22:16:06.240: main OpenCL platform: OpenCL 2.1 AMD-APP (2841.4)
2019.06.08:22:16:06.240: main Available GPUs for mining:
2019.06.08:22:16:06.240: main GPU1: Radeon RX Series (pcie 1), OpenCL 1.2, 8 GB VRAM, 32 CUs
2019.06.08:22:16:06.240: main GPU2: Radeon RX Series (pcie 2), OpenCL 1.2, 8 GB VRAM, 32 CUs
....
2019.06.08:22:16:06.138: main Unable to enum CUDA GPUs: no CUDA-capable device is detected
2019.06.08:22:16:06.240: main Unknown OpenCL driver version! Hashrate and stale shares may suffer
2019.06.08:22:16:06.240: main OpenCL platform: OpenCL 2.1 AMD-APP (2841.4)
2019.06.08:22:16:06.240: main Available GPUs for mining:
2019.06.08:22:16:06.240: main GPU1: Radeon RX Series (pcie 1), OpenCL 1.2, 8 GB VRAM, 32 CUs
2019.06.08:22:16:06.240: main GPU2: Radeon RX Series (pcie 2), OpenCL 1.2, 8 GB VRAM, 32 CUs
....
miner works, but during autotuning it spams log for about 3 minutes
Code:
2019.06.08:22:19:21.488: main Eth speed: 341.677 MH/s, shares: 10/0/0, time: 0:03
2019.06.08:22:19:23.652: GPU7 GPU7: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.652: GPU7 GPU7 is already in auto-tune process
2019.06.08:22:19:23.654: GPU1 GPU1: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.654: GPU1 GPU1 is already in auto-tune process
2019.06.08:22:19:23.701: GPU10 GPU10: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.701: GPU10 GPU10 is already in auto-tune process
2019.06.08:22:19:23.702: GPU2 GPU2: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.702: GPU2 GPU2 is already in auto-tune process
2019.06.08:22:19:23.703: GPU3 GPU3: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.703: GPU3 GPU3 is already in auto-tune process
2019.06.08:22:19:23.710: GPU4 GPU4: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.710: GPU4 GPU4 is already in auto-tune process
2019.06.08:22:19:23.711: GPU8 GPU8: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.711: GPU8 GPU8 is already in auto-tune process
2019.06.08:22:19:23.715: GPU11 GPU11: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.715: GPU11 GPU11 is already in auto-tune process
2019.06.08:22:19:23.716: GPU5 GPU5: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.716: GPU5 GPU5 is already in auto-tune process
2019.06.08:22:19:23.721: GPU9 GPU9: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.721: GPU9 GPU9 is already in auto-tune process
2019.06.08:22:19:23.764: GPU6 GPU6: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.652: GPU7 GPU7: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.652: GPU7 GPU7 is already in auto-tune process
2019.06.08:22:19:23.654: GPU1 GPU1: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.654: GPU1 GPU1 is already in auto-tune process
2019.06.08:22:19:23.701: GPU10 GPU10: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.701: GPU10 GPU10 is already in auto-tune process
2019.06.08:22:19:23.702: GPU2 GPU2: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.702: GPU2 GPU2 is already in auto-tune process
2019.06.08:22:19:23.703: GPU3 GPU3: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.703: GPU3 GPU3 is already in auto-tune process
2019.06.08:22:19:23.710: GPU4 GPU4: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.710: GPU4 GPU4 is already in auto-tune process
2019.06.08:22:19:23.711: GPU8 GPU8: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.711: GPU8 GPU8 is already in auto-tune process
2019.06.08:22:19:23.715: GPU11 GPU11: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.715: GPU11 GPU11 is already in auto-tune process
2019.06.08:22:19:23.716: GPU5 GPU5: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.716: GPU5 GPU5 is already in auto-tune process
2019.06.08:22:19:23.721: GPU9 GPU9: no -gt value specified, switching to auto-tune
2019.06.08:22:19:23.721: GPU9 GPU9 is already in auto-tune process
2019.06.08:22:19:23.764: GPU6 GPU6: no -gt value specified, switching to auto-tune
Re: GMiner v1.36 Equihash(BEAM, BTG)/CuckooCycle(AE, SWAP, GRIN29, GRIN31)
TBH Beam (and equihash in general) is a waste of time and money on AMD anyways. Lolminer should focus on delivering a non-shite cuckoo miner since he clearly has a better understanding of opencl than most, and (I propose) a 5% dev fee for it; that's a miner I would use.
write him about this. seriously
Re: PhoenixMiner 4.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
Can you confirm that you are seeing v3 kernels loading in the log file? (it should be in the first few pages of the log file, immediately before the card starts to actually mine). We have tested on GTX1080, which should be the same as P104 but perhaps the better memory timings in P104 cause the difference in behavior.
yes, there was v3 kernel in log file after creating DAG. P104 is more likely 1070 with fast memory.
I found that decreasing power limit reduces hasrate on 0,038MH/1W. but I do not tested yet if it works only with v3 kernels.
It's not even close to efficient if that's the question... Even @ 90MH/s you're burning too much power. 80-85 is a good spot, I'm doing 82 @ 215w.
that's great!
thank you