Quote from: shidocs on March 14, 2021, 06:59:11 AM

Hello Dev,

I started mining a month ago and used PhoenixMiner most of the time.

Every 2 or so days all my cards start getting about 30% invalid shares on my 12x 3070 rig on HiveOS. At first I thought I had an issue on the rig, maybe the mobo since it was all cards at once. But everything seemed normal and even cards at 39c had the issue. Restarting the miner always solved it.

A few weeks later I made a 2 new rigs on a different city, 3000km away (2x 12x 3070). The issue happened again, on all 3 rigs at once. This ruled out local issues.

I changed one of the rigs to a different miner just to troubleshoot if it was an issue with PhoenixMiner, and apparently is. The two rigs on PhoenixMiner exhibited the same issue a couple times, while the rig on the other miner didn't.

I searched a bit and found a post on reddit with someone with the same issue, he didn't name PhoenixMiner but said many miners are experiencing the same issue on 3060 and 3070: https://www.reddit.com/r/EtherMining/comments/lz7a3f/best_mining_software_and_how_to_choose_it/gq0s4my/?utm_source=reddit&utm_medium=web2x&context=3

Apparently it has something to do with epoch changes, I researched a bit and an epoch change occurs in eth between 8 and 48 hours, which is in line of the issue happening every few days. If a new DAG needs to be generated, the issue is likely the same when we start the miner with overclocking and get tons of invalid shares. That's why HiveOS have a config option to overclock only X seconds after miner start.

If I correctly diagnosed the issue, the solution will likely be to either restart the miner on a new epoch or send some message to HiveOS to bring the cards to default settings during epoch changes, or some other software change that makes the cards be in a stable state when loading DAGs while overclocked.

I will happily change back to PhoenixMiner when there is a solution for this issue, keep up the great work!

Thanks!

The most probable reason is too much memory overclock. And if the extreme memory overclock is also applied during the DAG generation, this may lead to corrupted DAG, which then will cause a lot of invalid shares. In 5.5c you can use the option -mcdag 1 to reset the memory overclock during DAG generation. On Windows -mcdag 1 is all you need (provided that you let PhoenixMiner overclock the memory with -mclock +XXXX).

However under Linux the things are more complicated because PhoenixMiner can't apply the memory overclock by itself. So, when you specify -mcdag 1 under Linux, PhoenixMiner searches for a shell script named daggen.sh, and if there is such a script, it is called once for each Nvidia GPU, passing the GPU index as the first argument, and PCIE bus ID as second argument. You must put in this script commands to reset the memory overclock, and to schedule re-applying the memory overclock after about 60 seconds (to be sure that the DAGs are already generated). The miner will then wait for about 7 seconds before starting DAG generation to allow the script enough time to reset the memory overclock.

Quote from: Shefu89 on March 14, 2021, 11:02:26 AM

Hi! Im new around here and registered here because i need little or big help with phoenixminer.

I have used it about 12 months now but recently it keeps crashing. Especially after Devfee.

example from log file:

Quote

2021.03.14:12:27:51.524: eths Eth: New job #89981f0a from ethash.poolbinance.com:1800; diff: 1073MH
2021.03.14:12:27:51.902: main DevFee: Disconnected and stopped
2021.03.14:12:27:54.975: main GPU1: 47C 77% 96W, GPU2: 49C 74% 98W, GPU3: 41C 75% 98W, GPU4: 46C 78% 93W
GPUs power: 385.0 W; cost: 0.55 USD/day
2021.03.14:12:27:55.376: main Eth speed: 158.749 MH/s, shares: 255/0/0, time: 0:30
2021.03.14:12:27:55.376: main GPUs: 1: 39.546 MH/s (67) 2: 39.759 MH/s (65) 3: 39.722 MH/s (67) 4: 39.723 MH/s (56)
2021.03.14:12:27:56.381: main Restart timeout reached

any ideas why?

After "restart timeout....." command panel just closes. No warning/error... nothing. Just closes.

config file look like this(i using -li 1 because stability no other reason):

Quote

-pool stratum+tcp://ethash.poolbinance.com:1800
-wal xxxxxxxxx
-amd -timeout 30 -lidag 2 -gt 6 -altinit -wdog 1 -wdtimeout 30 -li 1 -hstats 2 -prate 0.06 -rxboost 1

You just need to remove the -timeout 30 option from your config.txt file as it literally forces the miner to restart after 30 minutes (do not confuse -timeout with -wdtimeout, these are very different options). Here is the help for -timeout:

Quote

-timeout <n> Restart miner according to -rmode after n minutes

Quote from: W.T.R. on March 14, 2021, 07:17:29 PM

Quote

Quote from: earlybird36 on March 13, 2021, 03:50:04 PM

Is there any way to delay the application of overclock on the core during dag creation. I know its possible on the memory with -mcdag but Im having issues on the coreclock during dag creation process. I know increasing memory will increase the hashrate but in my case, increasing the coreclock increases the hashrate as well. Weirdly it only happens on my gtx 1070.

Not that weird - the TLB cache is part of the core, and its speed is the limiting factor of the hashrate of GTX1070 with the current DAG sizes. We could add it but not in the next release.

Is there any way to fix this TLB cache problem? I am one of probably many 1070, and 1080Ti users that would be grateful if there would be some kind of fix for this problem in the upcoming releases. We are losing 4-10 mh/s per card now as oppose to 2017.
Tnx.

We tried a lot of different approaches in the past but none of them worked. Only Nvidia knows if these GPUs (most of the Pascal series expect 1070Ti) even have the hardware ability to increase the virtual page size (the only thing that would fix the problem properly) like AMD did with the Polaris cards a few years ago. The whole point is moot now because even if Polaris GPUs are capable of larger page sizes, Nvidia wouldn't be bothered to release fixed drivers anyway.

Quote from: OlympicSSJ on March 14, 2021, 10:53:09 PM

Could some one pls tell me what command must be entered in the bat file that replaces the pill for ether?
With the pill I have around 10 mh/s increase on my 1080ti, but somewhere was mentioned now there's a command that renders the pill useless.

Im currently getting around 47,7 mh/s on a palit 1080ti Jetstream 85 tdp, 220 core, 330 mem. At very few occasions it jumps to 49 mh/s when I put EXACTLY 200 core/ 230 mem, but if goes back down to 47 whe new dag file loads or smt.
Lowering tdp below 75% or core clocks drives the speed down significantly. Any idea on different settings that can push it to 49?
Thanks!

You don't need the pill with PhoenixMiner. You need to add the option -straps <n>. Start with -straps 1, and the try the higher values to see how much tighter timings the card can take. You can also try fine-tuning the memory timings with the command-line options -vmt1, -vmt2, -vmt3, -vmr - check the documentation for more information about all these options.

Quote from: micdee on Today at 05:11:12 AM

Tnx. I will check the data and the logfiles.
When I run the miner in the console as far as I know it always starts with the card names.. (which GPU are found for mining) In this list it shows 6 times the same (type) cards RX 580

I even had fitted the RX 5700 as a single available GPU, but then I get the miner error "NO GPU for mining"

Is there any known hardware limit for getting the RX 5700 XT's to work in Phoenixminer, e.g. minimum of RAM used, or anything else, which we might have overlooked?
The rig is fitted with only 4 Gb RAM. (We use the Asrock H110 BTC Pro+ mobo)

Perhaps the driver version may be the issue. Do not use the latest AMD Linux drivers for anything else than RX6000 AMD cards.