Bitcoin Forum
May 31, 2020, 05:00:16 AM *
News: Latest Bitcoin Core release: 0.19.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 228 »
  Print  
Author Topic: PhoenixMiner 5.0b: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)  (Read 235812 times)
Yellow_donkey
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
February 13, 2018, 06:15:12 AM
 #501

It's the day after and still no 2.7 a or b.  Frowny face.
1590901216
Hero Member
*
Offline Offline

Posts: 1590901216

View Profile Personal Message (Offline)

Ignore
1590901216
Reply with quote  #2

1590901216
Report to moderator
You get merit points when someone likes your post enough to give you some. And for every 2 merit points you receive, you can send 1 merit point to someone else!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1590901216
Hero Member
*
Offline Offline

Posts: 1590901216

View Profile Personal Message (Offline)

Ignore
1590901216
Reply with quote  #2

1590901216
Report to moderator
gawdfather007
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
February 13, 2018, 04:50:47 PM
 #502

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.
Tranzius
Newbie
*
Offline Offline

Activity: 20
Merit: 0


View Profile
February 13, 2018, 07:38:37 PM
 #503

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

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.. Smiley Just imagine how much can Claymore earn with his software earning every hour... Incredible money mine.. Smiley

Babs797
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
February 13, 2018, 08:15:55 PM
 #504

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.
alexwd47
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
February 14, 2018, 12:20:16 AM
 #505

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
TheShobo
Newbie
*
Offline Offline

Activity: 32
Merit: 0


View Profile
February 14, 2018, 03:04:46 AM
 #506

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!
PhoenixMiner
Member
**
Offline Offline

Activity: 241
Merit: 18


View Profile
February 14, 2018, 08:39:20 AM
 #507

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:
  https://mega.nz/#F!zUFTyIrC!OSlA4BMlUvFq4HDbkK-AIg

  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
PhoenixMiner
Member
**
Offline Offline

Activity: 241
Merit: 18


View Profile
February 14, 2018, 09:47:25 AM
 #508

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.

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
Eth speed: 141.837 MH/s, shares: 169/0/0, time: 1:29
GPUs: 1: 28.508 MH/s (27) 2: 28.309 MH/s (32) 3: 28.315 MH/s (37/1) 4: 28.309 MH/s (34) 5: 28.397 MH/s (39)
New job is not "found", it is send from the pool, the miner (tries to) finds solution (aka share), which is send to the pool as a proof that the miner is working. In the long run, the number of shares will be proportional to the average hashrate of each GPU.

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.

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

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.

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.

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.

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.
Kartel
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
February 14, 2018, 01:09:50 PM
 #509

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
cmd_whoami
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
February 14, 2018, 01:32:22 PM
Last edit: February 14, 2018, 03:22:33 PM by cmd_whoami
 #510


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....
wip
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
February 14, 2018, 02:21:44 PM
 #511

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.
fr4nkthetank
Legendary
*
Offline Offline

Activity: 1834
Merit: 1021


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


View Profile WWW
February 14, 2018, 02:32:29 PM
 #512

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 Smiley

dohfish
Newbie
*
Offline Offline

Activity: 65
Merit: 0


View Profile
February 14, 2018, 02:53:59 PM
 #513


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.
TheShobo
Newbie
*
Offline Offline

Activity: 32
Merit: 0


View Profile
February 14, 2018, 04:01:16 PM
 #514

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.
elgi76
Member
**
Offline Offline

Activity: 126
Merit: 10


View Profile
February 14, 2018, 05:09:17 PM
 #515

2.6 work better for me with 2 r9 fury and 4 rx470
mxl86
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
February 14, 2018, 05:14:53 PM
 #516

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

Activity: 2
Merit: 0


View Profile
February 14, 2018, 06:02:06 PM
 #517

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.
JoepMeloen
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
February 14, 2018, 10:37:56 PM
 #518

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 !
kkanoee
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
February 14, 2018, 11:56:57 PM
 #519

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:
  https://mega.nz/#F!zUFTyIrC!OSlA4BMlUvFq4HDbkK-AIg

  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


Trying it tonight, will report if any issue. See ya in 8+ hours.
Yellow_donkey
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
February 15, 2018, 03:03:30 AM
 #520

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:
  https://mega.nz/#F!zUFTyIrC!OSlA4BMlUvFq4HDbkK-AIg

  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


I just tried it and no go.  Please confirm that solo mining/direct mining to geth or parity remains a non-feature with 2.7a.  Thanks.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 228 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!