Quote from: Miner59 on February 01, 2018, 06:32:15 PM

Been using this miner for like 6 hours now and it's amazing. 4-5 MH/s more than Claymore, which is great!

But I'm having this weird problem right now, I have 2x RX560's which are getting 14.7 MH/s each, but every ~10 seconds they both drop to ~12 MH/s for 2 seconds and then it goes back to 14.7 MH/s. My RX580's are not doing this and are keeping strong on the 30.5 MH/s mark. With Claymore I do not have this issue, I also tested this with Ethminer and the RX560's do not drop in hashrate at all.

Would be great if you could get that fixed somehow, other than that, this miner simply amazes me, keep up the good work!

Please try using the command line option -mi with different values (for example 8, or 9 instead of the default value of 10). You can change it only for the RX560s by using it like this:

Code:

-mi 8,8,10,10,10

In the above example the first two cards will run with mining intensity 8, and the other three - with mining intensity 10. This assumes that the RX560s are the first and the second card and you have five cards in the rig. The order of the cards must be the same that is listed by PhoenixMiner when starting up.

Quote from: Dhino on February 01, 2018, 10:59:37 PM

Any plan for Linux version?

Yes, but it was pushed back in order to implement hardware control (fan speed, clocks, voltages) and dual mining for decred first. Also, it would require more testing because there are a lot of Linux distributions that are used for mining. We are planning to release it in about two months now.

Quote from: shanepottermi on February 02, 2018, 02:12:01 AM

If you really want to make your fee lower than claymore and increase the fees you receive i'd suggest running your dev fee less often but for longer. Claymore runs his every hour.. it takes a minute for a system with a lot of gpus to spin them all up making that 30-70 seconds less effective because 10+ seconds its spinning the cards up.. then when it cuts off i have to wait for my cards to spin up to start mining again. It makes his 1% fee a lot larger than 1% an produces less for him. If you ran your fee like once every 4-6 hours instead of every 90 minutes but you ran it for an equivalent time relative to the 90 min dev fee.. we'd all make more long term. You might end up with some of the gamer miners trying to cut the fee but the people running a lot of cards 24/7 won't. Since you're not spinning up all the large farms over n over again for a short burst an instead mined for a 1-2 minutes you'd probably pull more in fees and we'd pay less due to downtime switching to dev pools. Win win for everyone.

The devfee period by itself is not the problem but the switching of DAG epochs. If you are mining any of directly supported coins (Ethereum, Ethereum Classic, Expanse, Musicoin, UBIQ, Pirl, Ellaism, Metaverse ETP, or Pegascoin), the miner will try to detect it and use the same coin for devfee, thus eliminating the DAG switch. If you mine any of these coins and PhoenixMiner fails to detect the coin correctly, use the -coin command-line option as described in the Reamde.txt file (or the first post in this thread) to force the usage of this coin for devfee and eliminate the DAG switches for devfee completely.
Also, if you are mining other ethash-based coins, we will be adding support for new coins soon.

Quote from: alkoholik24 on February 02, 2018, 11:51:57 AM

Hello,

Code:

17564:12:26:44.968: main Phoneix Miner 2.5d Windows/msvc - Release
17564:12:26:44.968: main Cmd line: -pool eu1.ethermine.org:4444 -wal 0x36fd6ca7b320c46189bb9e78f5390573cace4745.Rig003 -proto 3
17564:12:26:47.093: main Available GPUs for mining:
17564:12:26:47.170: main GPU1: GeForce GTX 1070 (pcie 1), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17564:12:26:47.170: main GPU2: GeForce GTX 1070 (pcie 2), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17564:12:26:47.170: main GPU3: GeForce GTX 1070 (pcie 3), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17564:12:26:47.210: main NVML library initialized
17564:12:26:51.887: main Listening for CDM remote manager at port 3333 in read-only mode
17564:12:26:51.887: main Eth: the pool list contains 3 pools
17564:12:26:51.887: main Eth: primary pool: eu1.ethermine.org:4444
17564:12:26:51.888: main Eth: Connecting to ethash pool eu1.ethermine.org:4444
17564:12:26:52.171: eths Eth: Connected to ethash pool eu1.ethermine.org:4444
17564:12:26:52.171: eths Eth: Starting GPU mining
17564:12:26:52.238: wdog Starting watchdog thread
17564:12:26:52.239: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_login","params":["0x36fd6ca7b320c4g07cab9e78f5390573cace4745.Rig003"]}

17564:12:26:52.294: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":true}
17564:12:26:52.295: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

17564:12:26:52.355: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0xf4b2522add423224a6cb7b8f6388076fcc9d2b37ef4576e8ee8ed4f2f1bf4242","0xb683d2a97f567602a1931b76b9fb447dd5563f0e4ab5dd69250556e7c1c94783","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4c8da2"]}
17564:12:26:52.355: eths Eth: New job #f4b2522a from eu1.ethermine.org:4444; diff: 4000MH
17564:12:26:52.360: GPU1 GPU1: Starting up...
17564:12:26:52.360: GPU1 Eth: Generating light cache for epoch #167
17564:12:26:52.381: GPU2 GPU2: Starting up...
17564:12:26:54.430: GPU3 GPU3: Starting up...
17564:12:26:55.306: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x29db229bbcc8f6acc243be972de280ed12e2a302b18c1a00eeeda7bc7b2f9fbb","0xb683d2a971567602a1931b76b9fb447dd5563f0e4ab5dd69250556e7c1c94783","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4c8da3"]}
17564:12:26:55.306: eths Eth: New job #29db229b from eu1.ethermine.org:4444; diff: 4000MH
17564:12:26:56.977: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
17564:12:26:56.977: main GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0) 3: 0.000 MH/s (0)
17564:12:26:59.874: GPU2 GPU2: Allocating DAG (2.32) GB; good for epoch up to #169
17564:12:26:59.984: GPU2 CUDA error in CudaProgram.cu:282 : out of memory (2)
17564:12:26:59.987: GPU1 GPU1: Allocating DAG (2.32) GB; good for epoch up to #169
17564:12:27:00.004: GPU2 GPU2 initMiner error: out of memory
17564:12:27:00.191: GPU3 GPU3: Allocating DAG (2.32) GB; good for epoch up to #169
17564:12:27:00.318: GPU3 CUDA error in CudaProgram.cu:282 : out of memory (2)
17564:12:27:00.318: GPU3 GPU3 initMiner error: out of memory
17564:12:27:00.400: GPU1 GPU1: Allocating light cache buffer (37.1) MB; good for epoch up to #169
17564:12:27:00.521: GPU1 GPU1: Generating DAG for epoch #167
17564:12:27:00.572: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x2e8a792c718867a8bdf1df222574c99b608f9a441e2b75bbc50af387f5842ad4","0xb683d2a971567602a1931b76b9fb447dd5563f0e4ab5dd69250556e7c1c94783","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4c8da4"]}
17564:12:27:00.572: eths Eth: New job #2e8a792c from eu1.ethermine.org:4444; diff: 4000MH
17564:12:27:00.590: GPU2 GPU2: Starting up...
17564:12:27:00.603: GPU3 GPU3: Starting up...
17564:12:27:00.848: wdog GPU thread(s) not responding. Restarting.
17564:12:27:02.073: GPU1 GPU1: DAG 13%
17564:12:27:02.084: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
17564:12:27:02.084: main GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0) 3: 0.000 MH/s (0)
17564:12:27:03.755: GPU1 GPU1: DAG 25%

the same in PhoenixMiner2.4
GPU default setting

Why is that?

Please use a batch file to start the miner with the following contents (the important part are the setx statements to set the environment variables):

Code:

setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100

PhoenixMiner.exe -clKernel 1 -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal 0x36fd6ca7b320c46189bb9e78f5390573cace4745.Rig003 -proto 3
pause

Quote from: Aurren on February 02, 2018, 05:03:30 PM

Tried the 2.5d and got a lot of stale (but when I switched back to claymore I noticed a lot of stale shares too (15%+)). When the stale shares went back to normal with claymore 2-4%, I got 2.6b and tried again. Getting normal amount of stales again, so far so good.

I've noticed that the log file stays at 1 KB until I stop the miner. Is the log file in memory until I stop it? I'm worried about running out of memory.

No, the file is not kept in memory, but Windows Explorer doesn't show the size of the file properly. Press F5 while Windows Explorer is open in the PhoenixMiner folder and you will see the real size of the log file.

Finally, a reminder that the release candidate of 2.6b is out with a possible fix for those that see more stales with 2.5d (and other improvements). For more information see this post: https://bitcointalk.org/index.php?topic=2647654.msg29359128#msg29359128.