So many rejected shares on 5.0x verisions... About 1-1.2% overall rejected shares (not stales or incorrect) on my RX 580 8Gb rigs...
Could you please tell us on which pools? This is normal on nicehash, as it doesn't accept stale shares and they count as rejected shares, and it seems that recently nicehash started changing the jobs more often, leading to more rejected shares.
Yes, it's on nicehash. Is there some way to correct show these stale shares?
We only can detect a part of stale shares - these that are discovered after we have received a new job. However, due to the delay in the pool itself and the network latency, most stale shares can not be discovered at miner level. So we send these shares and nicehash rejects them. We could take into account when the job last changed and if a share is rejected soon after a job has changed we can count it as stale instead of rejected but this won't be 100% reliable. However the bigger problem is that nicehash really doesn't count the stale shares at all unlike other pool that give reduced reward for stale shares, so it won't be correct to count them as stale in the statistics - you won't get any reward from them anyway.
There is nothing you can do unless you connect the display to 8 GB or 6 GB card. As this isn't possible in your case, you can instead run separate instance of PhoenixMiner for just GPU1 (adding the argument -gpus 1) and use a pool that only mines ETH. The other five cards will run on another instance of PhoenixMiner (with -gpus 23456), that can mine both ETH and ETC.
How to make this? With a 2 bat files? I will have 2 miners on the screen or is it possible to make in one?
Yes, make two different bat files and run them both. You will have two console windows, it's not possible to combine them as they are independent from each other. One thing to be aware of, if you are using remote control port, is to change the port number in one of the bat files to something else than the default port with this command-line argument:
-cdmport 3334 (this will change the remote control port to 3334, the default is 3333).
hello,
I have 2 rigs where the GPU 1 still don't mine ETH :/
and the one which works, have the same problem when I bench epoch 360
W10, latest AMD drivers, 4Go GPU, -eres 0.
Problem is, on the opposite of claymore, phoenix reboot the miner automatically instead of having GPU 1 at 0 hashrate and letting the rest mine.
normallyall my rigs have the same configuration, I don't know why it works better on somme than on other.
Does someone have an idea?
thx
An obvious question but are you running PhoenixMiner 5.0e? If so, please send us a log to check for any problems in it.
why did my miner stop when I started to DAG # 352? and doesn't reboot by itself,
2020.06.11:05:45:24.320: GPU5 GPU5: Starting up... (0)
2020.06.11:05:45:24.320: GPU5 GPU5: Generating ethash light cache for epoch #352
2020.06.11:05:45:24.342: GPU3 GPU3: Starting up... (0)
2020.06.11:05:45:24.398: GPU6 GPU6: Starting up... (0)
2020.06.11:05:45:24.444: GPU2 GPU2: Starting up... (0)
2020.06.11:05:45:24.559: GPU4 GPU4: Starting up... (0)
2020.06.11:05:45:24.604: GPU1 GPU1: Starting up... (0)
2020.06.11:05:45:27.189: main Eth speed: 0.000 MH/s, shares: 5/0/0, time: 0:02
2020.06.11:05:45:27.189: main GPUs: 1: 0.000 MH/s (1) 2: 0.000 MH/s (0) 3: 0.000 MH/s (1) 4: 0.000 MH/s (1) 5: 0.000 MH/s (1) 6: 0.000 MH/s (1)
2020.06.11:05:45:28.011: GPU5 Light cache generated in 3.7 s (16.3 MB/s)
2020.06.11:05:45:28.248: GPU3 GPU3: Allocating DAG (3.77) GB; good for epoch up to #354
2020.06.11:05:45:28.280: GPU3 GPU3: Generating DAG for epoch #352
2020.06.11:05:45:28.520: GPU6 GPU6: Allocating DAG (3.77) GB; good for epoch up to #354
2020.06.11:05:45:28.575: GPU6 GPU6: Generating DAG for epoch #352
2020.06.11:05:45:28.814: GPU2 GPU2: Allocating DAG (3.77) GB; good for epoch up to #354
2020.06.11:05:45:28.849: GPU2 GPU2: Generating DAG for epoch #352
2020.06.11:05:45:29.109: GPU4 GPU4: Allocating DAG (3.77) GB; good for epoch up to #354
thank you for your help
Please tell us the driver version and the Windows version, and the version of PhoenixMiner that you are running. Also, the log from the start would help much more than just the last several lines.