 Show Posts
|
|
Pages: [1] 2 3 4 »
|
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…
Next time write your own motd and then mod it as you like |
|
|
|
|
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
|
|
|
|
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
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
search for atiflash293plus |
|
|
|
So not sure what you're trying to say here.
that flashing custom bios is possible |
|
|
|
|
Is there any Navi/Vega bios editor?
|
|
|
|
flashing 5700 with custom bios is not a problem any more  the only problem is bios editor for Navi... hexeditor is our friend and shostt58  |
|
|
|
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! |
|
|
|
and what algo have you been testing? GRIN31, of course |
|
|
|
|
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%!!
|
|
|
|
P104-100s have 10+% slower C31 hashrate with 1.85.
confirmed |
|
|
|
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. 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. |
|
|
|
|
realbminer
why beam is so slow on P104? more than a half less than other miners.
Can you fix it?
and what about Swap support?
btw, there is no miner supporting SWAP on P104...
|
|
|
|
|
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
|
|
|
|
|
13 cards in rig work just fine. on linux using HiveOS
|
|
|
|
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).
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: -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. |
|
|
|
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. 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 [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 hope this help to trace the problem v11.9 also works without -gser. |
|
|
|
That's a lot of p104s.... Shhh! He do not like this number |
|
|
|
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  |
|
|
|
Please add support for amgpu-pro driver 19.10 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
....
miner works, but during autotuning it spams log for about 3 minutes 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
|
|
|
|
|
