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

JoepMeloen

newbie

Activity: 15

Merit: 0

I like it sofar.. i love the altcoins devfee.. stupid CM devfee is crashing my rig alot.

one very important question though..

How to set target temp? -tt 65 doesnt seems to work and gpus are running way to hot, up to 80C. CM can keep them nicely on the targettemp..how to do this in PM?
~~also: -cclock and -mclock etc doesnt take and there pretty important to finetune the rig.~~ (just read your comment about it)

im using awsome miner (with PM as user added software)and need the cmd's -tt , cclock, -mclock. mostly the -TT !

Awsome miner also doesnt show info about the miner, any clue why not? (it does show the console)

also: get this into Awsome Miner !

Saltist

newbie

Activity: 2

Merit: 0

Just going to say good work!

Phoenix mines faster than Claymore, calculated hashrate is closer to reported and most importantly - my rig is running for 14 days without a reboot already - more than claymore ever managed.

mxl86

newbie

Activity: 10

Merit: 0

2.7a seems more stable for me as for keeping my OC settings with MSI Afterburner, no resets for 3 hours now.

elgi76

member

Activity: 124

Merit: 10

2.6 work better for me with 2 r9 fury and 4 rx470

TheShobo

newbie

Activity: 31

Merit: 0

Quote from: PhoenixMiner on February 14, 2018, 04:47:25 AM

Quote from: TheShobo on February 13, 2018, 10:04:46 PM

I haven't read through every reply, so I apologize if this has already been answered.
You say a Linux version is planned but may take some time. Do you have any estimate at all as to when that would be? This miner sounds excellent and I'd love to switch my rigs over.

We have to implement: hardware control and dual mining before starting to work on the Linix version seriously. So no sooner that a few months unfortunately.

Not exactly what I had hoped to hear but I definitely appreciate the reply and the hard work you're putting in.
I'll try and be patient. Thanks.

dohfish

newbie

Activity: 65

Merit: 0

Quote from: cmd_whoami on February 14, 2018, 08:32:22 AM

Quote from: PhoenixMiner on February 14, 2018, 04:47:25 AM

Quote from: cmd_whoami on February 12, 2018, 11:16:01 AM

The only thing I don't understand is why GPU0 is GPU1. This makes the fan speed and temp readout in the miner not line up with the correct cards.

Fan temp on GPU0 = GPU5 in Phoenix Hashrate of GPU0 = GPU1 in Phoenix
Fan temp on GPU1 = GPU1 in Phoenix Hashrate of GPU1 = GPU2 in Phoenix
Fan temp on GPU2 = GPU2 in Phoenix Hashrate of GPU2 = GPU3 in Phoenix
Fan temp on GPU3 = GPU3 in Phoenix Hashrate of GPU3 = GPU4 in Phoenix
Fan temp on GPU4 = GPU4 in Phoenix Hashrate of GPU4 = GPU5 in Phoenix
Fan temp on GPU5 = GPU6 in Phoenix Hashrate of GPU5 = GPU6 in Phoenix
Fan temp on GPU6 = GPU7 in Phoenix Hashrate of GPU6 = GPU7 in Phoenix
Fan temp on GPU7 = GPU8 in Phoenix Hashrate of GPU7 = GPU8 in Phoenix
Fan temp on GPU8 = GPU9 in Phoenix Hashrate of GPU8 = GPU9 in Phoenix

We've seen similar things on AMD cards because of broken support for bus ID in the drivers but not on Nvidia cards. The ordering is based on the bus ID (ascending order) and the fan/temp reporting is matched to the bus ID as well, but in same cases like this one the NVML library obviously doesn't report the correct bus ID for the GPU5 and it ends up as the first. Could you press the 's' key on your keyboard and copy the list of GPUs with their bus IDs (it may be easier to do it from the log file than from the screen)?

17576:08:08:13.086: main Available GPUs for mining:
17576:08:08:13.086: main GPU1: GeForce GTX 1070 (pcie 1), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU2: GeForce GTX 1070 (pcie 2), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU3: GeForce GTX 1070 (pcie 3), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU4: GeForce GTX 1070 (pcie 4), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU5: GeForce GTX 1070 Ti (pcie 5), CUDA cap. 6.1, 8 GB VRAM, 19 CUs
17576:08:08:13.086: main GPU6: GeForce GTX 1070 (pcie 6), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU7: GeForce GTX 1070 (pcie 8 ), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU8: GeForce GTX 1070 (pcie 9), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU9: GeForce GTX 1070 (pcie 10), CUDA cap. 6.1, 8 GB VRAM, 15 CUs

17576:08:08:13.086: main Eth: Accepted shares 2171 (32 stales), rejected shares 2 (0 stales)
17576:08:08:13.086: main Eth: Incorrect shares 12 (0.38%), est. stales percentage 1.47%
17576:08:08:13.086: main Eth: Maximum difficulty of found share: 76.2 TH (!!!)
17576:08:08:13.086: main Eth: Average speed (5 min): 302.663 MH/s
17576:08:08:13.086: main Eth: Effective speed: 291.26 MH/s; at pool: 290.99 MH/s
17576:08:08:13.086: main
17576:08:08:15.723: main Eth speed: 303.298 MH/s, shares: 2171/2/12, time: 20:43
17576:08:08:15.723: main GPUs: 1: 34.044 MH/s (221/5) 2: 33.216 MH/s (234) 3: 33.701 MH/s (274) 4: 32.071 MH/s (226) 5: 34.033 MH/s (254) 6: 34.187 MH/s (237/7) 7: 34.237 MH/s (260) 8: 33.813 MH/s (230) 9: 33.995 MH/s (237)

@PhoenixMiner - Looks like the issue is with the odd card of the rig, the Zotac 1070 Ti AMP Edition. I added that 9th card when Windows did the fall creators update allowing Windows to find more than 8 cards. The other 8 are Zotac 1070 AMP Extremes. The 1070 Ti, GPU4, GPU5 in Phoenix, is in the correct GPU location of my OC tool ( Nvidia Inspector 1.9.7.8 ).

(Nvidia Inspector allows Over Clock on more than 8 cards which can be set by batch file or GUI and gives all info that GPUZ provides. On top of that it's more stable than MSI's After Burner). (The ONLY downside to Nvidia Inspector is you can't program a fan curve).

WHO EVER QUESTIONS PHOENIX ISN'T AS GOOD IF NOT MORE STABLE THAN CLAYMORE? 12 INCORRECT SHARES IN 20HRS @ 302 MH/s ON 9 CARDS.

There's a good chance that two of your cards are clocked too high, I have been running Phoenix on 10 rigs with 12xRX580's for 11 days straight now, no reboots or anything with 0 invalid shares on all 10 rigs.

fr4nkthetank

legendary

Activity: 2294

Merit: 1182

Now the money is free, and so the people will be

Well so far i'll just be waiting for the next version. Claymore isnt so bad if you have nodevfee plus dual mine blake2s or something else

wip

newbie

Activity: 8

Merit: 0

Hello team,

Would there be any particulaur reason if 3stale shares was received miner jumps directly to backup pool?
I can understand if we get X amount of rejected shares, but stale shares.

config is now changed, but i would like to know why its set to 3 on stale shares.

cmd_whoami

newbie

Activity: 14

Merit: 0

Quote from: PhoenixMiner on February 14, 2018, 04:47:25 AM

Quote from: cmd_whoami on February 12, 2018, 11:16:01 AM

The only thing I don't understand is why GPU0 is GPU1. This makes the fan speed and temp readout in the miner not line up with the correct cards.

Fan temp on GPU0 = GPU5 in Phoenix Hashrate of GPU0 = GPU1 in Phoenix
Fan temp on GPU1 = GPU1 in Phoenix Hashrate of GPU1 = GPU2 in Phoenix
Fan temp on GPU2 = GPU2 in Phoenix Hashrate of GPU2 = GPU3 in Phoenix
Fan temp on GPU3 = GPU3 in Phoenix Hashrate of GPU3 = GPU4 in Phoenix
Fan temp on GPU4 = GPU4 in Phoenix Hashrate of GPU4 = GPU5 in Phoenix
Fan temp on GPU5 = GPU6 in Phoenix Hashrate of GPU5 = GPU6 in Phoenix
Fan temp on GPU6 = GPU7 in Phoenix Hashrate of GPU6 = GPU7 in Phoenix
Fan temp on GPU7 = GPU8 in Phoenix Hashrate of GPU7 = GPU8 in Phoenix
Fan temp on GPU8 = GPU9 in Phoenix Hashrate of GPU8 = GPU9 in Phoenix

We've seen similar things on AMD cards because of broken support for bus ID in the drivers but not on Nvidia cards. The ordering is based on the bus ID (ascending order) and the fan/temp reporting is matched to the bus ID as well, but in same cases like this one the NVML library obviously doesn't report the correct bus ID for the GPU5 and it ends up as the first. Could you press the 's' key on your keyboard and copy the list of GPUs with their bus IDs (it may be easier to do it from the log file than from the screen)?

17576:08:08:13.086: main Available GPUs for mining:
17576:08:08:13.086: main GPU1: GeForce GTX 1070 (pcie 1), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU2: GeForce GTX 1070 (pcie 2), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU3: GeForce GTX 1070 (pcie 3), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU4: GeForce GTX 1070 (pcie 4), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU5: GeForce GTX 1070 Ti (pcie 5), CUDA cap. 6.1, 8 GB VRAM, 19 CUs
17576:08:08:13.086: main GPU6: GeForce GTX 1070 (pcie 6), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU7: GeForce GTX 1070 (pcie 8 ), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU8: GeForce GTX 1070 (pcie 9), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17576:08:08:13.086: main GPU9: GeForce GTX 1070 (pcie 10), CUDA cap. 6.1, 8 GB VRAM, 15 CUs

17576:08:08:13.086: main Eth: Accepted shares 2171 (32 stales), rejected shares 2 (0 stales)
17576:08:08:13.086: main Eth: Incorrect shares 12 (0.38%), est. stales percentage 1.47%
17576:08:08:13.086: main Eth: Maximum difficulty of found share: 76.2 TH (!!!)
17576:08:08:13.086: main Eth: Average speed (5 min): 302.663 MH/s
17576:08:08:13.086: main Eth: Effective speed: 291.26 MH/s; at pool: 290.99 MH/s
17576:08:08:13.086: main
17576:08:08:15.723: main Eth speed: 303.298 MH/s, shares: 2171/2/12, time: 20:43
17576:08:08:15.723: main GPUs: 1: 34.044 MH/s (221/5) 2: 33.216 MH/s (234) 3: 33.701 MH/s (274) 4: 32.071 MH/s (226) 5: 34.033 MH/s (254) 6: 34.187 MH/s (237/7) 7: 34.237 MH/s (260) 8: 33.813 MH/s (230) 9: 33.995 MH/s (237)

17576:08:09:01.576: main GPU1: 51C 35%, GPU2: 63C 35%, GPU3: 48C 35%, GPU4: 61C 49%, GPU5: 59C 35%, GPU6: 51C 35%, GPU7: 59C 35%, GPU8: 49C 35%, GPU9: 56C 35%

@PhoenixMiner - Looks like the issue is with the odd card of the rig, the Zotac 1070 Ti AMP Edition. I added that 9th card when Windows did the fall creators update allowing Windows to find more than 8 cards. The other 8 are Zotac 1070 AMP Extremes with a fan speed of 35%. The 1070 Ti, GPU4, GPU5 in Phoenix, is in the GPU4 location of my OC tool ( Nvidia Inspector 1.9.7.8 ) with a fan speed of 49%.

(Nvidia Inspector allows Over Clock on more than 8 cards which can be set by batch file or GUI and gives all info that GPUZ provides. On top of that it's more stable than MSI's After Burner). (The ONLY downside to Nvidia Inspector is you can't program a fan curve).

WHO EVER QUESTIONS PHOENIX ISN'T AS GOOD IF NOT MORE STABLE THAN CLAYMORE? 12 INCORRECT SHARES IN 20HRS @ 302 MH/s ON 9 CARDS.

Edit: I thought only getting 12 incorrect shares was amazing at those speeds....

Kartel

newbie

Activity: 5

Merit: 0

Hello, have an issue, working great since few days, after a reboot when i try to launch it my win10 just freez.

Have already disable quick edit mode, enable it too, same thing, always freezing.

Any help will be wonderfull here...
thx

PhoenixMiner

full member

Activity: 357

Merit: 101

Quote from: mistercoin on February 09, 2018, 05:17:00 PM

First i've seen of this. I am anxious to try out a new miner. Any chance of you adding support for Zcash? Or a miner for Zcash? Would be a great boon

Mistercoin-

We have to first implement a lot of other features, and then, possibly, add support for other algorithms.

Quote from: johnalim on February 11, 2018, 11:22:57 AM

I would like to understand further the lines of text printed on the console while the miner application is running.
Could you help me understand:

1. How to find out which GPUs are idle (waiting for job) and which GPUs are busy solving an algorithm?
2. How to find out how long it took to finish a share? and are shares solved by 1 GPU only or which GPUs helped to complete the share?
3. How to find out when a solution was submitted?
4. What is difference between "New job found... from " and "ETH share found"?

Let me know if these are details found on console of the app, or such debug strings can be printed by adding a parameter to the script, or such details are unavailable or do not exist.

Reason for asking this is that we could be too caught up with hashrates (processing power) and yet forget that idle GPUs (due to absence of a job or difficulty finding a share) affect performance too. No point overclocking GPUs only to be stuck waiting like a Ferrari stuck in traffic.

The GPUs are not sitting idle waiting for work if they show a hashrate. Generally, the pool sends work immediately after connecting to it and all the GPUs work on the same "job", without any periods of idling. You can see the number of shares found by each GPU shown in the statistics in parenthesis after the hashrate like this (also note that the GPU3 had one incorrect share):

Quote from: janding on February 11, 2018, 12:22:36 PM

If you have multiple GPU's in a system you will need to do this for each GPU.
Disable all the GPU's but one. Find the best number for that GPU.
Record that number then disable that GPU and enable the next one.
Repeat until you have all the setting for each GPU.

This can take some time, but it’s worth it.

Nice description. One small advice - you don't have to disable the other GPUs unless the rig is hitting thermal or power limits and throttling as a consequence - just ignore the hashrates of the other GPUs and only try to maximize the hashrate of the GPU you are currently adjusting.

Quote from: cmd_whoami on February 12, 2018, 11:16:01 AM

The only thing I don't understand is why GPU0 is GPU1. This makes the fan speed and temp readout in the miner not line up with the correct cards.

Fan temp on GPU0 = GPU5 in Phoenix Hashrate of GPU0 = GPU1 in Phoenix
Fan temp on GPU1 = GPU1 in Phoenix Hashrate of GPU1 = GPU2 in Phoenix
Fan temp on GPU2 = GPU2 in Phoenix Hashrate of GPU2 = GPU3 in Phoenix
Fan temp on GPU3 = GPU3 in Phoenix Hashrate of GPU3 = GPU4 in Phoenix
Fan temp on GPU4 = GPU4 in Phoenix Hashrate of GPU4 = GPU5 in Phoenix
Fan temp on GPU5 = GPU6 in Phoenix Hashrate of GPU5 = GPU6 in Phoenix
Fan temp on GPU6 = GPU7 in Phoenix Hashrate of GPU6 = GPU7 in Phoenix
Fan temp on GPU7 = GPU8 in Phoenix Hashrate of GPU7 = GPU8 in Phoenix
Fan temp on GPU8 = GPU9 in Phoenix Hashrate of GPU8 = GPU9 in Phoenix

We've seen similar things on AMD cards because of broken support for bus ID in the drivers but not on Nvidia cards. The ordering is based on the bus ID (ascending order) and the fan/temp reporting is matched to the bus ID as well, but in same cases like this one the NVML library obviously doesn't report the correct bus ID for the GPU5 and it ends up as the first. Could you press the 's' key on your keyboard and copy the list of GPUs with their bus IDs (it may be easier to do it from the log file than from the screen)?

Quote from: Amstellodamois on February 12, 2018, 05:44:01 PM

Isn't there a way to automate this? Have the miner calculate a moving average while it's changing this parameter, thus finding out the best for each card.

"PhoenixMiner, the miner taylored to your cards" does sound appealing.

There is but given all the other features that wait to be implemented, this is going to wait its turn. Also, it would require that the rig has absolutely stable conditions during the adjustment period or the results will be invalid.

Quote from: mxl86 on February 12, 2018, 08:05:15 PM

Using MSI Afterburner

Hopefully, 2.7a would help with this as well. Still, the only real solution is to add over-clocking options in the program itself and periodically reset the clocks if they are running away from the intended values. We are implementing this for AMD cards now and we will try to do it for Nvida cards as well even though the relevant functions of NVAPI are proprietary.

Quote from: gawdfather007 on February 13, 2018, 11:50:47 AM

I have been using Phoenix Miner for about 2 days and its working better than claymore, getting 0.5mh higher compared to it and temps are a degree low, small improvement but still an improvement but i have an issue with this miner from time to time i get this error

17575:19:25:26.793: GPU1 CUDA error in CudaProgram.cu:433 : unknown error (999)
17575:19:25:26.795: GPU1 GPU1 search error: unknown error

If this always happens on the same GPU (GPU1 in this instance), error 999 is strongly connected to too high memory overclock. Dial back the memory clocks by 20-30 MHz on the corresponding GPU and see if this would help.

Quote from: TheShobo on February 13, 2018, 10:04:46 PM

I haven't read through every reply, so I apologize if this has already been answered.
You say a Linux version is planned but may take some time. Do you have any estimate at all as to when that would be? This miner sounds excellent and I'd love to switch my rigs over.

We have to implement: hardware control and dual mining before starting to work on the Linix version seriously. So no sooner that a few months unfortunately.

PhoenixMiner

full member

Activity: 357

Merit: 101

As the work on the hardware control options is taking longer than expected, here is a beta version with the other new features: PhoenixMiner 2.7a. It can be downloaded from here:
(MEGA links are no longer active)

Here are the checksums to verify the download:

Code:

    File: PhoenixMiner_2.7a.zip
   SHA-1: fd967e62d05adec1c9d6126c347d711ac7028688
 SHA-256: 237d6f3f781d9a4a718559c956d2da0bf81e82c374e7ce6dca44e397bcd404ff
 SHA-512: 13584ac2a99073e3ea53ecc308ee19422bd26f85e585313740f9e275d0318a7cfa7151f0a63292d97c1736b8d072ea4b8d3743e97927f83979b6d93348b71d18

Note that this is not an official release and the hardware control and solo mining features are not included in it (they will be included in the final 2.7 release). The changes are:

Improvements in switching between normal mode and devfee mode to avoid some GPUs "losing" their overcloking/undervolting settings
Increase the frequency of getWork requests to lower the probability of stale shares
Added support for direct mining of Akroma, WhaleCoin, and Victorium without DevFee switching (use akroma, whale, or vic in the -coin parameter)
Show warning messages and more detailed error messages when the virtual memory is low, or GPU memory is not enough for DAG allocation
Other small improvements and changes

TheShobo

newbie

Activity: 31

Merit: 0

I haven't read through every reply, so I apologize if this has already been answered.
You say a Linux version is planned but may take some time. Do you have any estimate at all as to when that would be? This miner sounds excellent and I'd love to switch my rigs over.

Thanks!

alexwd47

newbie

Activity: 1

Merit: 0

Add to your command line: -cdmport 3333
to remote it and detect it as a claymore dual miner with Awesome miner

Phoenix is more stable with an high OC

Babs797

newbie

Activity: 7

Merit: 0

Quote

Could give us some specifics? How menu cards you have, and what command line you are using? Note that the -gpus option GPU indexes start from 1, not 0 like in the -di option. So, if you want to use only the first three cards, you have to use -gpus 123 or -di 012.

6 cards total, selecting 3 using "-gpus 345" in the config file.

Tranzius

newbie

Activity: 20

Merit: 0

I think let's wait for new version. Devs are currently busy to release it, so let's wait..

I also like this miner and hope that devs will continue with it. Every competition is good. Especially when reward as "Devfee" is so great..

Currently I really don't understand why any programmer team do not assemble 10+ good programmers and make perfect mining software as it is the MOST rewarding and most expensive software in world..

Just imagine how much can Claymore earn with his software earning every hour... Incredible money mine..

gawdfather007

newbie

Activity: 3

Merit: 0

I have been using Phoenix Miner for about 2 days and its working better than claymore, getting 0.5mh higher compared to it and temps are a degree low, small improvement but still an improvement but i have an issue with this miner from time to time i get this error

17575:19:25:26.793: GPU1 CUDA error in CudaProgram.cu:433 : unknown error (999)
17575:19:25:26.795: GPU1 GPU1 search error: unknown error
17575:19:25:26.815: GPU4 CUDART error in CudaProgram.cu:422 : unknown error (30)
17575:19:25:26.815: GPU4 GPU4 search error: unknown error
17575:19:25:26.833: GPU5 CUDART error in CudaProgram.cu:422 : unknown error (30)
17575:19:25:26.833: GPU5 GPU5 search error: unknown error
17575:19:25:26.851: GPU3 CUDART error in CudaProgram.cu:422 : unknown error (30)
17575:19:25:26.851: GPU3 GPU3 search error: unknown error
17575:19:25:26.851: GPU2 CUDART error in CudaProgram.cu:422 : unknown error (30)
17575:19:25:26.851: GPU2 GPU2 search error: unknown error
17575:19:25:26.860: GPU6 CUDART error in CudaProgram.cu:422 : unknown error (30)
17575:19:25:26.860: GPU6 GPU6 search error: unknown error
17575:19:25:27.004: wdog Thread(s) not responding. Restarting.
17575:19:25:27.397: main Eth speed: 77.554 MH/s, shares: 26/0/0, time: 0:43
17575:19:25:27.397: main GPUs: 1: 0.000 MH/s (2) 2: 15.471 MH/s (5) 3: 15.539 MH/s (4) 4: 15.536 MH/s (2) 5: 15.538 MH/s (5) 6: 15.469 MH/s ( Cool

17575:19:25:29.413: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0x92d02bb7b745090918a04da139ec175b699b73ddd94f978d3039d017e4c3e99f","0xf4c702c8373b1a6467eb30d4640b62436e55a6c8c9e2f486197f6e0b2dd72f5f","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}
17575:19:25:29.413: eths Eth: New job #92d02bb7 from eth-asia1.nanopool.org:9999; diff: 10000MH
17575:19:25:29.442: GPU1 GPU1: Starting up...
17575:19:25:29.468: GPU1 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17575:19:25:29.468: GPU1 GPU1 initMiner error: all CUDA-capable devices are busy or unavailable
17575:19:25:29.474: GPU2 GPU2: Starting up...
17575:19:25:29.505: GPU3 GPU3: Starting up...
17575:19:25:29.520: GPU2 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17575:19:25:29.520: GPU2 GPU2 initMiner error: all CUDA-capable devices are busy or unavailable
17575:19:25:29.537: GPU4 GPU4: Starting up...
17575:19:25:29.552: GPU5 GPU5: Starting up...
17575:19:25:29.563: GPU3 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17575:19:25:29.563: GPU3 GPU3 initMiner error: all CUDA-capable devices are busy or unavailable
17575:19:25:29.583: GPU6 GPU6: Starting up...
17575:19:25:29.604: GPU4 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17575:19:25:29.604: GPU4 GPU4 initMiner error: all CUDA-capable devices are busy or unavailable
17575:19:25:29.644: GPU5 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17575:19:25:29.644: GPU5 GPU5 initMiner error: all CUDA-capable devices are busy or unavailable
17575:19:25:29.681: GPU6 CUDART error in CudaProgram.cu:230 : all CUDA-capable devices are busy or unavailable (46)
17575:19:25:29.681: GPU6 GPU6 initMiner error: all CUDA-capable devices are busy or unavailable
17575:19:25:32.475: main Eth speed: 0.000 MH/s, shares: 26/0/0, time: 0:43
17575:19:25:32.475: main GPUs: 1: 0.000 MH/s (2) 2: 0.000 MH/s (5) 3: 0.000 MH/s (4) 4: 0.000 MH/s (2) 5: 0.000 MH/s (5) 6: 0.000 MH/s ( Cool

then i switched back to claymore and didn't encounter this, so can someone explain why is this happening with phoenix miner? i really like phoenix miner it shows more details and gives out better result and has a lower devfee, i would really love a solution for this problem.

Yellow_donkey

newbie

Activity: 31

Merit: 0

It's the day after and still no 2.7 a or b. Frowny face.

mxl86

newbie

Activity: 10

Merit: 0

Quote from: PhoenixMiner on February 12, 2018, 10:58:08 AM

Quote from: johnalim on February 11, 2018, 01:28:25 AM

Hi,

Thank you for making this miner.

I would like to know if your miner supports multiple instances. I have 12 cards and would want 2 instances of your miner running simultaneously with 6 cards accessible for each instance. Reason for doing this is to increase probability of getting shares.

Could you comment if this is possible, how to achieve it and if it will yield the benefits I stated?

Thank you and more power to you and your team.

John

Yes, you can do this and it is quite easy. The first step is to have two copies of the PhoenixMiner folder. Then add the command line option -gpus 123456 to the command line of the first miner (or in the config.txt file if you are using config.txt file instead of directly adding command-line options). This will limit the first instance of PhoenixMiner to the first six cards of your rig. For the second instance of the miner use the option -gpus 7,8,9,10,11,12 and it will use the other six cards.
If you want to use remote monitoring, you have to add the option -cdmport 3334 on one of the instances (first or second) because they cant both run on the default port 3333 for remote monitoring.
As for the more probability of getting shares, we don't think that it would make much difference but you can use one half of the rig to mine on one pool and other - on different pool and compare which works best for your. Or you can even mine different coins.

Quote from: Tranzius on February 11, 2018, 05:38:46 AM

Hello Phoenix, is there any scheduled date when version 2.7. will be released? I had to switch back to Claymore's miner because of that bug when during Devfee session the voltage parameters of cards are reset.

I really like your miner as it has better hashrate performance and lower stale shares on Ethermine.
Also stability is without any problems..mining 2 weeks and no sigle crash.

We will release an early beta tomorrow or the day after tomorrow (depending on how the internal testing goes). The "seemless" devfee switch is already undergoing testing and works quite stable but the hardware control options are nowhere near completion, so we will probably release a 2.7a versions without them but with all the other new features first.

Quote from: Vixxx on February 11, 2018, 07:46:50 AM

How to use -gt (GPU tuning, what does it do)? I dont seem to find any value that would make a difference.

There is quite small difference unless you go to really high gt values (above 30-40). Also, give it at least 30-60 seconds for the hashrate to "settle" after changing the gt value before moving to the next gt value (you can move by 10, for example from 15 to 25, then wait one minute to see what the hashrate looks like when it stabilizes, then repeat and so on).

Quote from: cdrx on February 11, 2018, 08:13:36 AM

Running HWiNFO v5.72 in the background I lose 1-2 mh/s ... it's just me ?

Yes, this is normal, and the same effect can be observed with GPU-Z when looking in the sensor tab. The reason is that the ADL library is not thread-safe and the sensor readings can't be read in parallel, which slows down the driver, especially when all available sensors are read every second or so, which is the normal mode of operation of these programs. If you want to keep them in the background, make sure that the frequency of reading of the sensors is not too high (for example once every 10-30 seconds should be fine but once every few seconds is too often).

Quote from: Babs797 on February 11, 2018, 09:23:42 PM

The -gpus command does not work. I cannot mine with only specific gpus. Any suggestions?

Could give us some specifics? How menu cards you have, and what command line you are using? Note that the -gpus option GPU indexes start from 1, not 0 like in the -di option. So, if you want to use only the first three cards, you have to use -gpus 123 or -di 012.

Quote from: mxl86 on February 12, 2018, 03:52:54 AM

Nvidia here, all 1060s.

Hmm, this is something new. So far we have seen this only with AMD cards. Would you mind telling us what program you are using for setting the clocks and voltages of your cards?

Using MSI Afterburner

janding

jr. member

Activity: 170

Merit: 6

Quote from: Amstellodamois on February 12, 2018, 05:44:01 PM

Quote from: janding on February 11, 2018, 12:22:36 PM

Quote from: Vixxx on February 11, 2018, 07:46:50 AM

How to use -gt (GPU tuning, what does it do)? I dont seem to find any value that would make a difference.

Using the -gt tuning can make a worthwhile increase in your hash rates.
This is only used for AMD cards.

Here is how I found the best way to tune and use it.

Have your miner up and running.
Using the '+' key increase the tuning parameter to a larger number than you need.
Start out at 100.
Watch your displayed hash rate in the mining window.
Let it display a few updates to see where the speed is currently running.
Decrease the tuning number by 10 using the '-' key.
Watch the hash rate.
Continue decreasing the number by 10 on each test while watching the hash rates.
You should see the hash rate starting to increase as you go down in numbers.
The hash rate will increase and then start to decrease.
When you reach that point you are close.
Now start going up and down by 5 instead of 10 on each test.
You will eventually find the sweet spot where you can't improve it any more.
Set that number in the -gt parameter in your config.txt file.

If you have multiple GPU's in a system you will need to do this for each GPU.
Disable all the GPU's but one. Find the best number for that GPU.
Record that number then disable that GPU and enable the next one.
Repeat until you have all the setting for each GPU.

This can take some time, but it’s worth it.

Isn't there a way to automate this? Have the miner calculate a moving average while it's changing this parameter, thus finding out the best for each card.

"PhoenixMiner, the miner taylored to your cards" does sound appealing.

I might be in the minority on this but it doesn't appeal to me to have the miner decide those settings. Although it would be
quite interesting to see it do that.
I had much rather do it myself, I trust my settings more than what the miner would do for me.
It's part of the fun for me to tune my rigs to get every hash/second I can get and understand what I'm doing.
If you did decide to change mining software and the other miners doesn't do that, you would need to do it anyway.
I'm sure that the settings on one miner would not be totally accurate on another miner also.
But it might be a selling point for the developers.

Topic: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux) - page 475. (Read 784985 times)