PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)

[4play]

For now i have never problem with PhoenixMiner. Now i have a problem with this:
I using PM 2.9e

Code:

2018.05.13:10:26:26.668: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.668: GPU2 GPU2 search error: unspecified launch failure
2018.05.13:10:26:26.678: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.678: GPU5 GPU5 search error: unspecified launch failure
2018.05.13:10:26:26.694: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.694: GPU3 GPU3 search error: unspecified launch failure
2018.05.13:10:26:26.709: wdog Thread(s) not responding. Restarting.
2018.05.13:10:26:26.725: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU6 GPU6 search error: unspecified launch failure
2018.05.13:10:26:26.725: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU1 GPU1 search error: unspecified launch failure
2018.05.13:10:26:26.756: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)

My settings are same all time. I have gtx 1070 (8gb) gpus. How to solve this problem any idea?

[rboer]

For now i have never problem with PhoenixMiner. Now i have a problem with this:
I using PM 2.9e

Code:

2018.05.13:10:26:26.668: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.668: GPU2 GPU2 search error: unspecified launch failure
2018.05.13:10:26:26.678: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.678: GPU5 GPU5 search error: unspecified launch failure
2018.05.13:10:26:26.694: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.694: GPU3 GPU3 search error: unspecified launch failure
2018.05.13:10:26:26.709: wdog Thread(s) not responding. Restarting.
2018.05.13:10:26:26.725: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU6 GPU6 search error: unspecified launch failure
2018.05.13:10:26:26.725: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU1 GPU1 search error: unspecified launch failure
2018.05.13:10:26:26.756: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)

My settings are same all time. I have gtx 1070 (8gb) gpus. How to solve this problem any idea?

try lowering the GPU2 overclock settings a bit, looks like that is the card that is causing the issue

[4play]

For now i have never problem with PhoenixMiner. Now i have a problem with this:
I using PM 2.9e

Code:

2018.05.13:10:26:26.668: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.668: GPU2 GPU2 search error: unspecified launch failure
2018.05.13:10:26:26.678: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.678: GPU5 GPU5 search error: unspecified launch failure
2018.05.13:10:26:26.694: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.694: GPU3 GPU3 search error: unspecified launch failure
2018.05.13:10:26:26.709: wdog Thread(s) not responding. Restarting.
2018.05.13:10:26:26.725: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU6 GPU6 search error: unspecified launch failure
2018.05.13:10:26:26.725: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU1 GPU1 search error: unspecified launch failure
2018.05.13:10:26:26.756: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)

My settings are same all time. I have gtx 1070 (8gb) gpus. How to solve this problem any idea?

try lowering the GPU2 overclock settings a bit, looks like that is the card that is causing the issue

 Ok, tnx for advice. I’ll try this

[Digital_Seytan]

I have unspecified launch failure 719 for some days now, what does this mean, and what can you do about it? phoenixminer 2.9.e nvdia 388.31 win 10/64

[jonfrakes]

DAG generation freezes/crashes the whole system with the latest PhoenixMiner. I'm using 8 GTX 1070s (6 MSI Gaming Xs and 2 Zotac Minis). I tried running the miner using -lidag 3, but to no avail.

Windows 10 Pro
8 GB RAM
73728 MB Virtual Memory / Pagefile Size

[sidaliroy]

Still no info on 3.0?

[PhoenixMiner]

I would love me some nice juicy and fat linux version

    Yes, but hopefully not that fat There is some progress on this but no ETA yet, sorry.

Hi Phoenix, can you explain how -nvf option works (and, of course, for -clf) more detailed and can it be used with new kernels or with old ones only? Also I would like to have more details about -mi and -gt options. If you can explain it in understandable way for regular users, it will be so good. May be it will be better also to include this information in readme file. Thank you for very good work!

   It's hard to this do in non-technical terms (and frankly, it's not that understandable even in technical terms) but here it goes:

   -clf/-nvf

   Theoretically, it would be best to leave it to the driver to decide how to synchronize the individual kernel dispatches (calls) - this should provide the best speed and utilization of the GPU. In practice however, the driver often doesn't do very good job, and here is the role of the -clf and -nvf options (first one is for AMD cards, second one - for Nvidia cards). When these options are at their default values (1), PhoenixMiner will "force" the synchronization periodically to avoid driver issues. This still leaves some room for the driver to do optimizations between these "force" points. If the options are at 2, the driver has no say at all. The other extreme is when these options are at 0: no forced synchronization will be performed and the driver will be fully in control. Possible problems when using -clf/-nvf at 0 are unstable hashrate or semi-permanent drops of the hashrate. -clf/-nvf 2 should provide much more stable hashrate but sometimes at the price of slightly lower absolute speed.
   These options are used for both the new kernels and the old ones, and can be specified per-GPU.

 -mi

   This effectively sets the size of job performed by each kernel dispatch (call). The bigger -mi values correspond to larger kernel sizes. This usually increases the hashrate because less time is lost in overhead when starting/stopping the kernel. However the bigger job sizes can also cause crashes and unresponsive video drivers, especially if one of the GPUs is also used as main GPU (connected to a display or a plug). In most cases AMD cards have less problems with high -mi values than Nvidia cards, which are almost unusable at high -mi values and sometimes just crash with high job sizes.

 -gt

   Again, theoretically, the GPU should "know" the best how to combine the individual threads in each kernel dispatch in order to maximize the throughout. It does this by switching very fast from one thread to another whenever the first thread is waiting for a memory read/write to finish. This is something like hyper-threading on steroids. Again, the theory doesn't correspond to practice too well, so we are doing "manual" reordering of the memory accesses but this should be fine-tuned for each GPU depending on the core clocks, memory clocks, and memory access latency. This is done by the -gt parameter. Note that there may be more than one "best" or "equally best" -gt value and the difference between these will be almost 0. We are going to release an auto-tune option in PhoenixMiner 3.0, which will automatically find the best -gt values for each AMD card individually (note that -gt only works for AMD cards).

I cannot use

Code:

-coin clo 

param. Please, update the miner to support CLO.

   Coming in PhonixMiner 3.0 along with a lot of other ethash coins.

Here we go again:

Miner:
7*1070 + 5*580

So on Claymore v. 11.6 i use This bat file:

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
Miners\Claymore_Dual_Ethereum_v10.2\EthDcrMiner64.exe -epool eu1.ethermine.org:4444 -ewal walletaddress.rigcozinha -epsw x -allpools 1 -mport 4444 -cclock 1150 -mclock 2225 -cvddc 850 -mvddc 850

MSI Afterburnner 4.5.0:
Core: 0
Mem: +715
PL: 65%
Power Consumption: 1750w

PhoniexMiner config bat file:

Code:

 REM
REM Example bat file for starting PhoenixMiner.exe to mine ETH
REM

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 -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal walletaddress.RIGcozinha -proto 3 -cclock 1150 -mclock 2225 -cvddc 850 -mvddc 850 -log 0

Afterburnner config are the same

Power Consumption: 2150w

Whats the problem?
I like verter PM, but With This difference i cannot keep using.

    Most probably you are using the blockchain beta drivers, and the undervolt settings are not applied properly by PhoenixMiner. Check with GPU-Z or something like this to see the actual voltage of the GPUs. The solution is either to use third-party program to control the clocks and voltages, or use newer drivers (18.x.x are working good for us).

Hello,

i am running 2 different instances of the miner, 1 for nvidia and 1 for amd, its more comfortable for me to control the settings this way,

for now i used -cdm and 2 diferent ports, so i see them in my control panel as 2 miners,

is there an option to see them as 1 miner  ? somehow make the cdm know that there are 2 windows running ?


thanks

   No, unfortunately there is no way to see them as single miner as each instance needs a different port to listen to.

Still no info on 3.0?

   Around the end of the month. We are adding a lot of new features, and we don't want to release new versions with too little changes between them to avoid upgrade fatigue.

   

[j2james]

   It's hard to this do in non-technical terms (and frankly, it's not that understandable even in technical terms) but here it goes:

   -clf/-nvf

   Theoretically, it would be best to leave it to the driver to decide how to synchronize the individual kernel dispatches (calls) - this should provide the best speed and utilization of the GPU. In practice however, the driver often doesn't do very good job, and here is the role of the -clf and -nvf options (first one is for AMD cards, second one - for Nvidia cards). When these options are at their default values (1), PhoenixMiner will "force" the synchronization periodically to avoid driver issues. This still leaves some room for the driver to do optimizations between these "force" points. If the options are at 2, the driver has no say at all. The other extreme is when these options are at 0: no forced synchronization will be performed and the driver will be fully in control. Possible problems when using -clf/-nvf at 0 are unstable hashrate or semi-permanent drops of the hashrate. -clf/-nvf 2 should provide much more stable hashrate but sometimes at the price of slightly lower absolute speed.
   These options are used for both the new kernels and the old ones, and can be specified per-GPU.

 -mi

   This effectively sets the size of job performed by each kernel dispatch (call). The bigger -mi values correspond to larger kernel sizes. This usually increases the hashrate because less time is lost in overhead when starting/stopping the kernel. However the bigger job sizes can also cause crashes and unresponsive video drivers, especially if one of the GPUs is also used as main GPU (connected to a display or a plug). In most cases AMD cards have less problems with high -mi values than Nvidia cards, which are almost unusable at high -mi values and sometimes just crash with high job sizes.

 -gt

   Again, theoretically, the GPU should "know" the best how to combine the individual threads in each kernel dispatch in order to maximize the throughout. It does this by switching very fast from one thread to another whenever the first thread is waiting for a memory read/write to finish. This is something like hyper-threading on steroids. Again, the theory doesn't correspond to practice too well, so we are doing "manual" reordering of the memory accesses but this should be fine-tuned for each GPU depending on the core clocks, memory clocks, and memory access latency. This is done by the -gt parameter. Note that there may be more than one "best" or "equally best" -gt value and the difference between these will be almost 0. We are going to release an auto-tune option in PhoenixMiner 3.0, which will automatically find the best -gt values for each AMD card individually (note that -gt only works for AMD cards).

The very thank you Phoenix!

Your description has added some clarity. Once again, I'm grateful to you for not ignoring your users' questions and trying to answer all of them. This is one more advantage of your team, in addition to the fact that your product, in my opinion, has already surpassed Claymore.

[Digital_Seytan]

For now i have never problem with PhoenixMiner. Now i have a problem with this:
I using PM 2.9e

Code:

2018.05.13:10:26:26.668: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.668: GPU2 GPU2 search error: unspecified launch failure
2018.05.13:10:26:26.678: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.678: GPU5 GPU5 search error: unspecified launch failure
2018.05.13:10:26:26.694: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.694: GPU3 GPU3 search error: unspecified launch failure
2018.05.13:10:26:26.709: wdog Thread(s) not responding. Restarting.
2018.05.13:10:26:26.725: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU6 GPU6 search error: unspecified launch failure
2018.05.13:10:26:26.725: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU1 GPU1 search error: unspecified launch failure
2018.05.13:10:26:26.756: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)

My settings are same all time. I have gtx 1070 (8gb) gpus. How to solve this problem any idea?

try lowering the GPU2 overclock settings a bit, looks like that is the card that is causing the issue

I have also had the same problem for a couple of days, have you solved it and what did you like to report?

[Digital_Seytan]

For now i have never problem with PhoenixMiner. Now i have a problem with this:
I using PM 2.9e

Code:

2018.05.13:10:26:26.668: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.668: GPU2 GPU2 search error: unspecified launch failure
2018.05.13:10:26:26.678: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.678: GPU5 GPU5 search error: unspecified launch failure
2018.05.13:10:26:26.694: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.694: GPU3 GPU3 search error: unspecified launch failure
2018.05.13:10:26:26.709: wdog Thread(s) not responding. Restarting.
2018.05.13:10:26:26.725: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU6 GPU6 search error: unspecified launch failure
2018.05.13:10:26:26.725: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU1 GPU1 search error: unspecified launch failure
2018.05.13:10:26:26.756: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)

My settings are same all time. I have gtx 1070 (8gb) gpus. How to solve this problem any idea?

try lowering the GPU2 overclock settings a bit, looks like that is the card that is causing the issue

 Ok, tnx for advice. I’ll try this

I have also had the same problem for a couple of days, have you solved it and what did you like to report?

[j2james]

For now i have never problem with PhoenixMiner. Now i have a problem with this:
I using PM 2.9e

Code:

2018.05.13:10:26:26.668: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.668: GPU2 GPU2 search error: unspecified launch failure
2018.05.13:10:26:26.678: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.678: GPU5 GPU5 search error: unspecified launch failure
2018.05.13:10:26:26.694: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.694: GPU3 GPU3 search error: unspecified launch failure
2018.05.13:10:26:26.709: wdog Thread(s) not responding. Restarting.
2018.05.13:10:26:26.725: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU6 GPU6 search error: unspecified launch failure
2018.05.13:10:26:26.725: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU1 GPU1 search error: unspecified launch failure
2018.05.13:10:26:26.756: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)

My settings are same all time. I have gtx 1070 (8gb) gpus. How to solve this problem any idea?

try lowering the GPU2 overclock settings a bit, looks like that is the card that is causing the issue

I have also had the same problem for a couple of days, have you solved it and what did you like to report?

I have this error regularly beginning from 2018.04.22:18:14. I do not remove logs, so I have full history. Sometime I have other errors. My error history is the following:

error 719 - 5 times (the 1st of them was 2018.04.22:18:14)
error 999 - 1 time
error 719 - 1 time
error 719 and error 999 after 719 - 1 time
error 719 - 1 time
error 4 - 1 time
error 719 - 7 times
error 999 - 1 time
error 719 - 1 time (this one was 2018.05.11:15:24)

Also I had some restarts during this period w\o errors in log files.

All these errors in PM 2.9e. Before that I used 2.7c and 2.8c. And only one time I had only one error 999 in 2.7c. So looks like something wrong in 2.9e.

If PM developers want I can provide all logs.

[pinamalina]

For now i have never problem with PhoenixMiner. Now i have a problem with this:
I using PM 2.9e

Code:

2018.05.13:10:26:26.668: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.668: GPU2 GPU2 search error: unspecified launch failure
2018.05.13:10:26:26.678: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.678: GPU5 GPU5 search error: unspecified launch failure
2018.05.13:10:26:26.694: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.694: GPU3 GPU3 search error: unspecified launch failure
2018.05.13:10:26:26.709: wdog Thread(s) not responding. Restarting.
2018.05.13:10:26:26.725: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU6 GPU6 search error: unspecified launch failure
2018.05.13:10:26:26.725: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.05.13:10:26:26.725: GPU1 GPU1 search error: unspecified launch failure
2018.05.13:10:26:26.756: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)

My settings are same all time. I have gtx 1070 (8gb) gpus. How to solve this problem any idea?

try lowering the GPU2 overclock settings a bit, looks like that is the card that is causing the issue

 Ok, tnx for advice. I’ll try this

I have also had the same problem for a couple of days, have you solved it and what did you like to report?

I got these same errors when OC-ing my 1070 to the limits.
Follow next steps to resolve this problem - worked 100% in my case:

• Reduce the OC settings for the nvidia cards
• Reinstall nvidia drivers
• Run Phoenix ... it will for sure work again

I got this problem twice; In both cases when searching for maximum stable mem freq I can push the 1070 gpus.
Currently running stable at:
  Core: -200 (minus 200)
  Mem: 765
  Power Limit: 59
  Hashing: 32.770 MH/s
To tune, I am using nvidia Inspector as it allows me to easily tune individual gpus.
I have this line "call nvidia-tune.bat" in start.bat before the PhoenixMiner.exe line:

Code:

::nvidia-tune.bat file content: 7 nvidia cards 0..7 - 
:: Note1: card 3 - it is stable at max 625 mem clock - any atampt to go higher will produce errors in minutes after the mining starts
:: Note2: The fans are set to run at constant speed - I have found these values (different for each fan) that keep my cards at around 50-55oC, depending on the ambient temperature
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:0,0,-200 -setMemoryClockOffset:0,0,765 -setPowerTarget:0,59 -setTempTarget:0,1,65 -setFanSpeed:0,45
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:1,0,-200 -setMemoryClockOffset:1,0,765 -setPowerTarget:1,59 -setTempTarget:1,1,65 -setFanSpeed:1,60
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:2,0,-200 -setMemoryClockOffset:2,0,765 -setPowerTarget:2,59 -setTempTarget:2,1,65 -setFanSpeed:2,45
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:3,0,-200 -setMemoryClockOffset:3,0,625 -setPowerTarget:3,55 -setTempTarget:3,1,65 -setFanSpeed:3,40
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:4,0,-200 -setMemoryClockOffset:4,0,765 -setPowerTarget:4,59 -setTempTarget:4,1,65 -setFanSpeed:4,45
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:5,0,-200 -setMemoryClockOffset:5,0,765 -setPowerTarget:5,59 -setTempTarget:5,1,65 -setFanSpeed:5,60
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:6,0,-200 -setMemoryClockOffset:6,0,765 -setPowerTarget:6,59 -setTempTarget:6,1,65 -setFanSpeed:6,45

In my experience the nvidia is not gracefully handling errors when it comes to errors from OC. In best scenario (when slightly overclocked), PhoenixMiner will restart as expected. In worst case, when OC is too high, nvidia driver/configuration gets corrupted and the error as above ends any attempt to mine with the card. The reboot, restart nor cold restart will not make it go away. Only the driver reinstall fixes the problem.

[j2james]

I got this problem twice; In both cases when searching for maximum stable mem freq I can push the 1070 gpus.
Currently running stable at:
  Core: -200 (minus 200)
  Mem: 765
  Power Limit: 59
  Hashing: 32.770 MH/s
To tune, I am using nvidia Inspector as it allows me to easily tune individual gpus.
I have this line "call nvidia-tune.bat" in start.bat before the PhoenixMiner.exe line:

Code:

::nvidia-tune.bat file content: 7 nvidia cards 0..7 - 
:: Note1: card 3 - it is stable at max 625 mem clock - any atampt to go higher will produce errors in minutes after the mining starts
:: Note2: The fans are set to run at constant speed - I have found these values (different for each fan) that keep my cards at around 50-55oC, depending on the ambient temperature
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:0,0,-200 -setMemoryClockOffset:0,0,765 -setPowerTarget:0,59 -setTempTarget:0,1,65 -setFanSpeed:0,45
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:1,0,-200 -setMemoryClockOffset:1,0,765 -setPowerTarget:1,59 -setTempTarget:1,1,65 -setFanSpeed:1,60
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:2,0,-200 -setMemoryClockOffset:2,0,765 -setPowerTarget:2,59 -setTempTarget:2,1,65 -setFanSpeed:2,45
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:3,0,-200 -setMemoryClockOffset:3,0,625 -setPowerTarget:3,55 -setTempTarget:3,1,65 -setFanSpeed:3,40
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:4,0,-200 -setMemoryClockOffset:4,0,765 -setPowerTarget:4,59 -setTempTarget:4,1,65 -setFanSpeed:4,45
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:5,0,-200 -setMemoryClockOffset:5,0,765 -setPowerTarget:5,59 -setTempTarget:5,1,65 -setFanSpeed:5,60
start C:\dev\Tools\Guru3D.com\nvidiaInspector.exe -setBaseClockOffset:6,0,-200 -setMemoryClockOffset:6,0,765 -setPowerTarget:6,59 -setTempTarget:6,1,65 -setFanSpeed:6,45

In my experience the nvidia is not gracefully handling errors when it comes to errors from OC. In best scenario (when slightly overclocked), PhoenixMiner will restart as expected. In worst case, when OC is too high, nvidia driver/configuration gets corrupted and the error as above ends any attempt to mine with the card. The reboot, restart nor cold restart will not make it go away. Only the driver reinstall fixes the problem.

Thank you. I will play with that

[EthCiN]

Hello,
With this version I have lots of share timeouts.
I never had this problem, I have stable Internet connection and using DwarfPool.
Here the log:

Code:

2018.05.14:09:55:59.521: main Eth speed: 155.620 MH/s, shares: 240/0/0, time: 0:54
2018.05.14:09:55:59.521: main GPUs: 1: 33.271 MH/s (51) 2: 24.619 MH/s (31) 3: 31.424 MH/s (52) 4: 33.007 MH/s (60) 5: 33.298 MH/s (46)
2018.05.14:09:56:03.610: GPU3 Eth: GPU3: ETH share found!
2018.05.14:09:56:03.611: eths Eth: Send: {"id":13,"jsonrpc":"2.0","method":"eth_submitWork","params":["0x6d002bc2c16113db","0x6087a8f6886a0f261b6fedeba190e517035789954da6daa64b9f3f080c42b599","0x3ee348896117da0e9051e859fccfd6b81374f28aa8989757942aaf84ad7cf022"]}

2018.05.14:09:56:03.611: eths Eth: Share actual difficulty: 4100 MH
2018.05.14:09:56:03.649: eths Eth: Received: {"id":13,"jsonrpc":"2.0","result":true}
2018.05.14:09:56:03.649: eths Eth: Share accepted in 39 ms
2018.05.14:09:56:04.621: main  
2018.05.14:09:56:04.621: main *** 0:54 ***************************************************
2018.05.14:09:56:04.621: main Eth: Mining ETH on eth-eu.dwarfpool.com:8008 for 0:00


2018.05.14:09:56:04.621: main Eth speed: 155.580 MH/s, shares: 241/0/0, time: 0:54
2018.05.14:09:56:04.621: main GPUs: 1: 33.272 MH/s (51) 2: 24.619 MH/s (31) 3: 31.414 MH/s (53) 4: 32.978 MH/s (60) 5: 33.297 MH/s (46)
2018.05.14:09:56:04.621: main Eth: Accepted shares 241 (0 stales), rejected shares 0 (0 stales)
2018.05.14:09:56:04.621: main Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00% 
2018.05.14:09:56:04.621: main Eth: Maximum difficulty of found share: 910.6 GH (!)
2018.05.14:09:56:04.621: main Eth: Average speed (5 min): 155.457 MH/s
2018.05.14:09:56:04.621: main Eth: Effective speed: 147.49 MH/s; at pool: 147.49 MH/s
2018.05.14:09:56:04.621: main  
2018.05.14:09:56:06.465: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

2018.05.14:09:56:06.465: eths Eth: Share timeout in 606 s
2018.05.14:09:56:06.508: eths Eth: Received: {"result":["0x6087a8f6886a0f261b6fedeba190e517035789954da6daa64b9f3f080c42b599","0xe6073b5528bd0132af704e709c5723848c28e74e1d250eff85fc89e916b8515e","0x0000000225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574"],"jsonrpc":"2.0","id":5}
2018.05.14:09:56:09.731: main Eth speed: 155.589 MH/s, shares: 241/1/0, time: 0:54

How can I fix it?
Regards,
Marcin

[j2james]

I got this problem twice; In both cases when searching for maximum stable mem freq I can push the 1070 gpus.
Currently running stable at:
  Core: -200 (minus 200)
  Mem: 765
  Power Limit: 59
  Hashing: 32.770 MH/s

Do not understand how your 1070s work on these settings. With PL 59 for my 1070 hasrate is very not stable. When I setted MC 750, after some seconds I had 719 error and reboot. CC -200 also makes hashrate unstable. Now I'm testing PL +64, CC -100, MC +670 with power 750W and avg hashrate per card 32.06 (about 192.4 per 6 cards). So all my changes of previous OC settings is changing CC from +0 to -100.

[dohfish]

I got this problem twice; In both cases when searching for maximum stable mem freq I can push the 1070 gpus.
Currently running stable at:
  Core: -200 (minus 200)
  Mem: 765
  Power Limit: 59
  Hashing: 32.770 MH/s

Do not understand how your 1070s work on these settings. With PL 59 for my 1070 hasrate is very not stable. When I setted MC 750, after some seconds I had 719 error and reboot. CC -200 also makes hashrate unstable. Now I'm testing PL +64, CC -100, MC +670 with power 750W and avg hashrate per card 32.06 (about 192.4 per 6 cards). So all my changes of previous OC settings is changing CC from +0 to -100.

Not all cards are the same, overclock potential will be different between models, individual chips etc so you basically need to be lucky aswell.

[crypper]

I've been using claymore for my RX X80s for over a year now. Decided to give phoenix a go...and I'm damn happy I did: slight improvement in hashrate at the same clocks and power and significant reduction in stale shares! I've been suffering from 5-15% stales (ethermine.org) since Byzantium fork in 2017. With phoenix I have <1% stales.
Great job, man.

Retraction of my previous statement: number of stale shares is marginally lower than claymore's. During the first few hours of running phoenix I indeed had <1% of stales; number increased with time though and as of now I'm back to 5-10% stales.
Bad job, man!

[pinamalina]

I've been using claymore for my RX X80s for over a year now. Decided to give phoenix a go...and I'm damn happy I did: slight improvement in hashrate at the same clocks and power and significant reduction in stale shares! I've been suffering from 5-15% stales (ethermine.org) since Byzantium fork in 2017. With phoenix I have <1% stales.
Great job, man.

Retraction of my previous statement: number of stale shares is marginally lower than claymore's. During the first few hours of running phoenix I indeed had <1% of stales; number increased with time though and as of now I'm back to 5-10% stales.
Bad job, man!

Your 5-10% stale share is arguably bad. With the PH 2.9e, migrated from Claymore 11.5 my stale share rate is slightly higher than on Claymore yet still in the range of 1-3% - varies from day to day.
Stale share is sensitive not only to the miner code but also on the quality of your network speed and latency. Shares are accepted in 40-42ms in my case. What is yours? What is your ping to your pool? Here is what I have:
C:\Program Files\NVIDIA Corporation\NVSMI>ping eu1.ethermine.org

Pinging eu1.ethermine.org [46.105.121.53] with 32 bytes of data:
Reply from 46.105.121.53: bytes=32 time=59ms TTL=54
Reply from 46.105.121.53: bytes=32 time=42ms TTL=54
Reply from 46.105.121.53: bytes=32 time=41ms TTL=54
Reply from 46.105.121.53: bytes=32 time=41ms TTL=54

Ping statistics for 46.105.121.53:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 41ms, Maximum = 59ms, Average = 45ms

Connect a rig to network using wired connection (avoid wireless at any cost). Make sure you are not using switches/APs that introduce unexpected latency.

[crypper]

I've been using claymore for my RX X80s for over a year now. Decided to give phoenix a go...and I'm damn happy I did: slight improvement in hashrate at the same clocks and power and significant reduction in stale shares! I've been suffering from 5-15% stales (ethermine.org) since Byzantium fork in 2017. With phoenix I have <1% stales.
Great job, man.

Retraction of my previous statement: number of stale shares is marginally lower than claymore's. During the first few hours of running phoenix I indeed had <1% of stales; number increased with time though and as of now I'm back to 5-10% stales.
Bad job, man!

Your 5-10% stale share is arguably bad. With the PH 2.9e, migrated from Claymore 11.5 my stale share rate is slightly higher than on Claymore yet still in the range of 1-3% - varies from day to day.
Stale share is sensitive not only to the miner code but also on the quality of your network speed and latency. Shares are accepted in 40-42ms in my

could you please explain to a noob (me) the difference between network speed and network latency?

[pinamalina]

I've been using claymore for my RX X80s for over a year now. Decided to give phoenix a go...and I'm damn happy I did: slight improvement in hashrate at the same clocks and power and significant reduction in stale shares! I've been suffering from 5-15% stales (ethermine.org) since Byzantium fork in 2017. With phoenix I have <1% stales.
Great job, man.

Retraction of my previous statement: number of stale shares is marginally lower than claymore's. During the first few hours of running phoenix I indeed had <1% of stales; number increased with time though and as of now I'm back to 5-10% stales.
Bad job, man!

Your 5-10% stale share is arguably bad. With the PH 2.9e, migrated from Claymore 11.5 my stale share rate is slightly higher than on Claymore yet still in the range of 1-3% - varies from day to day.
Stale share is sensitive not only to the miner code but also on the quality of your network speed and latency. Shares are accepted in 40-42ms in my

could you please explain to a noob (me) the difference between network speed and network latency?

You will get the best answer if you Google: network latency definition.