Quote from: EtaCarinae on May 08, 2018, 11:38:53 AM

I would love me some nice juicy and fat linux version Cheesy

Yes, but hopefully not that fat

There is some progress on this but no ETA yet, sorry.

Quote from: j2james on May 08, 2018, 02:56:05 PM

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).

Quote from: duyvu1311 on May 09, 2018, 04:48:23 AM

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.

Quote from: B00gieman on May 11, 2018, 02:01:45 PM

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).

Quote from: sergioheadache on May 11, 2018, 06:00:42 PM

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.

Quote from: sidaliroy on May 14, 2018, 02:02:00 AM

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.