Bitcoin Forum
September 16, 2019, 05:19:11 PM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 ... 186 »
  Print  
Author Topic: PhoenixMiner 4.6c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)  (Read 189463 times)
Jbodz83
Newbie
*
Offline Offline

Activity: 125
Merit: 0


View Profile
April 04, 2018, 06:04:09 AM
 #1361

This is my hashrate and stale share percentage in Claymore 11.6

https://image.ibb.co/iz6vBc/ETC.png

Phoenix can tap my RIG up to 395Mhs (13GPU) however, it gives me 5-6% stale share..

i like the hashrate spike from PhoenixMiner, but i guess effeciency goes to Claymore 11.6 - hope that PhoenixMiner could catch up soon.. Cool


Your screen shot doesn't show the stale shares (%). what you are seeing is Valid Share/Rejected Share/Bad Share. Even with v2.7c I only had 2.6% stale, after updating to 2.8c its down to 0.58%. And your Rejected shares are quite high 3 rejected in 404 valid, I have 0 rejected and only 0.01% invalid. So something is not right in your configuration.

Sorry, i didnt get you, this SS if you can see in the right its 404 valid 3 stales (1%) 0 Invalid (0%) - unfortunately, i am not looking in my miners results sir. thats why i shared the screenshot directly from pool. well.. cant have this kind of percentage of stale share in PhoenixMiner. something is wrong with your reference i guess?

Thanks for sharing your experience by the way Smiley - check the pool not the miner's result sir Smiley
1568654351
Hero Member
*
Offline Offline

Posts: 1568654351

View Profile Personal Message (Offline)

Ignore
1568654351
Reply with quote  #2

1568654351
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
j2james
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
April 04, 2018, 09:16:35 AM
 #1362

Hi Phoenix, can you change time logging in the next release to be more user friendly?

Now you use format

17625:02:43:37.171

But for me 17625 looks strange. I really do not know what is it. Can you log date instead of 17625?

Another point. I use -minRigSpeed 188 option. It should do restart if avg hashrate is less then 188 during last 5 minutes. But this is not true. Please look at log. Only 1 minute I had hashrate less then 188. Not 5 minutes, but rig was rebooted

Code:
Line 169001: 17625:12:01:00.948: main Eth speed: 192.206 MH/s, shares: 2537/0/2, time: 36:32
Line 169008: 17625:12:01:06.018: main Eth speed: 193.469 MH/s, shares: 2537/0/2, time: 36:32
Line 169013: 17625:12:01:11.088: main Eth speed: 191.407 MH/s, shares: 2537/0/2, time: 36:33
Line 169026: 17625:12:01:16.158: main Eth speed: 191.587 MH/s, shares: 2537/0/2, time: 36:33
Line 169029: 17625:12:01:21.228: main Eth speed: 191.606 MH/s, shares: 2537/0/2, time: 36:33
Line 169034: 17625:12:01:26.231: main Eth speed: 191.135 MH/s, shares: 2537/0/2, time: 36:33
Line 169036: 17625:12:01:31.246: main Eth speed: 190.546 MH/s, shares: 2537/0/2, time: 36:33
Line 169047: 17625:12:01:36.251: main Eth speed: 191.941 MH/s, shares: 2537/0/2, time: 36:33
Line 169049: 17625:12:01:41.256: main Eth speed: 190.582 MH/s, shares: 2537/0/2, time: 36:33
Line 169055: 17625:12:01:46.256: main Eth speed: 189.725 MH/s, shares: 2537/0/2, time: 36:33
Line 169057: 17625:12:01:51.302: main Eth speed: 190.850 MH/s, shares: 2537/0/2, time: 36:33
Line 169067: 17625:12:01:56.310: main Eth speed: 190.770 MH/s, shares: 2537/0/2, time: 36:33
Line 169075: 17625:12:02:01.310: main Eth speed: 190.820 MH/s, shares: 2537/0/2, time: 36:33
Line 169082: 17625:12:02:06.312: main Eth speed: 192.562 MH/s, shares: 2537/0/2, time: 36:33
Line 169084: 17625:12:02:11.514: main Eth speed: 190.879 MH/s, shares: 2537/0/2, time: 36:34
Line 169092: 17625:12:02:16.515: main Eth speed: 190.799 MH/s, shares: 2537/0/2, time: 36:34
Line 169094: 17625:12:02:21.518: main Eth speed: 190.793 MH/s, shares: 2537/0/2, time: 36:34
Line 169099: 17625:12:02:26.518: main Eth speed: 190.781 MH/s, shares: 2537/0/2, time: 36:34
Line 169101: 17625:12:02:31.518: main Eth speed: 190.915 MH/s, shares: 2537/0/2, time: 36:34
Line 169116: 17625:12:02:36.519: main Eth speed: 190.963 MH/s, shares: 2538/0/2, time: 36:34
Line 169121: 17625:12:02:41.522: main Eth speed: 190.766 MH/s, shares: 2538/0/2, time: 36:34
Line 169133: 17625:12:02:46.579: main Eth speed: 190.568 MH/s, shares: 2538/0/2, time: 36:34
Line 169143: 17625:12:02:51.590: main Eth speed: 190.527 MH/s, shares: 2539/0/2, time: 36:34
Line 169150: 17625:12:02:56.591: main Eth speed: 190.601 MH/s, shares: 2539/0/2, time: 36:34
Line 169154: 17625:12:03:01.604: main Eth speed: 190.593 MH/s, shares: 2539/0/2, time: 36:34
Line 169159: 17625:12:03:06.604: main Eth speed: 190.677 MH/s, shares: 2539/0/2, time: 36:34
Line 169164: 17625:12:03:11.606: main Eth speed: 190.855 MH/s, shares: 2539/0/2, time: 36:35
Line 169173: 17625:12:03:16.608: main Eth speed: 190.845 MH/s, shares: 2539/0/2, time: 36:35
Line 169175: 17625:12:03:21.611: main Eth speed: 189.304 MH/s, shares: 2539/0/2, time: 36:35
Line 169183: 17625:12:03:26.611: main Eth speed: 190.948 MH/s, shares: 2539/0/2, time: 36:35
Line 169191: 17625:12:03:31.613: main Eth speed: 190.941 MH/s, shares: 2539/0/2, time: 36:35
Line 169198: 17625:12:03:36.630: main Eth speed: 190.786 MH/s, shares: 2539/0/2, time: 36:35
Line 169203: 17625:12:03:41.634: main Eth speed: 191.880 MH/s, shares: 2539/0/2, time: 36:35
Line 169208: 17625:12:03:46.683: main Eth speed: 190.897 MH/s, shares: 2539/0/2, time: 36:35
Line 169210: 17625:12:03:51.687: main Eth speed: 191.073 MH/s, shares: 2539/0/2, time: 36:35
Line 169217: 17625:12:03:56.689: main Eth speed: 191.021 MH/s, shares: 2539/0/2, time: 36:35
Line 169219: 17625:12:04:01.693: main Eth speed: 190.925 MH/s, shares: 2539/0/2, time: 36:35
Line 169225: 17625:12:04:06.696: main Eth speed: 190.788 MH/s, shares: 2539/0/2, time: 36:35
Line 169230: 17625:12:04:11.698: main Eth speed: 190.634 MH/s, shares: 2539/0/2, time: 36:36
Line 169243: 17625:12:04:16.698: main Eth speed: 190.537 MH/s, shares: 2539/0/2, time: 36:36
Line 169245: 17625:12:04:21.700: main Eth speed: 190.440 MH/s, shares: 2539/0/2, time: 36:36
Line 169252: 17625:12:04:26.703: main Eth speed: 190.492 MH/s, shares: 2539/0/2, time: 36:36
Line 169254: 17625:12:04:31.704: main Eth speed: 190.597 MH/s, shares: 2539/0/2, time: 36:36
Line 169262: 17625:12:04:36.716: main Eth speed: 190.594 MH/s, shares: 2539/0/2, time: 36:36
Line 169266: 17625:12:04:41.723: main Eth speed: 190.437 MH/s, shares: 2539/0/2, time: 36:36
Line 169271: 17625:12:04:46.737: main Eth speed: 190.413 MH/s, shares: 2539/0/2, time: 36:36
Line 169273: 17625:12:04:51.777: main Eth speed: 190.313 MH/s, shares: 2539/0/2, time: 36:36
Line 169293: 17625:12:04:56.778: main Eth speed: 190.389 MH/s, shares: 2540/0/2, time: 36:36
Line 169301: 17625:12:05:01.812: main Eth speed: 190.256 MH/s, shares: 2540/0/2, time: 36:36
Line 169307: 17625:12:05:06.966: main Eth speed: 187.663 MH/s, shares: 2540/0/2, time: 36:36
Line 169309: 17625:12:05:12.163: main Eth speed: 179.329 MH/s, shares: 2540/0/2, time: 36:37
Line 169322: 17625:12:05:17.163: main Eth speed: 155.063 MH/s, shares: 2541/0/2, time: 36:37
Line 169324: 17625:12:05:22.288: main Eth speed: 111.250 MH/s, shares: 2541/0/2, time: 36:37
Line 169329: 17625:12:05:27.525: main Eth speed: 85.712 MH/s, shares: 2541/0/2, time: 36:37
Line 169332: 17625:12:05:32.705: main Eth speed: 115.706 MH/s, shares: 2541/0/2, time: 36:37
Line 169339: 17625:12:05:37.775: main Eth speed: 163.700 MH/s, shares: 2541/0/2, time: 36:37
Line 169346: 17625:12:05:42.811: main Eth speed: 173.852 MH/s, shares: 2541/0/2, time: 36:37

Code:
17625:12:05:42.811: main *** 36:37 ***************************************************
17625:12:05:42.811: main Eth: Mining ETH on eth-eu1.nanopool.org:9999
17625:12:05:42.811: main Eth speed: 173.852 MH/s, shares: 2541/0/2, time: 36:37
17625:12:05:42.811: main GPUs: 1: 29.437 MH/s (390) 2: 28.839 MH/s (437/1) 3: 29.572 MH/s (445/1) 4: 28.203 MH/s (451) 5: 29.520 MH/s (396) 6: 28.282 MH/s (422)
17625:12:05:42.811: main Eth: Accepted shares 2541 (27 stales), rejected shares 0 (0 stales)
17625:12:05:42.811: main Eth: Incorrect shares 2 (0.08%), est. stales percentage 1.06%
17625:12:05:42.811: main Eth: Maximum difficulty of found share: 46.1 TH (!!!)
17625:12:05:42.811: main Eth: Average speed (5 min): 184.180 MH/s
17625:12:05:42.811: main Eth: Effective speed: 192.72 MH/s; at pool: 192.72 MH/s
17625:12:05:42.811: main 
17625:12:05:42.811: main Average ethash speed for 5 min is below minimum of 188 MH/s. Restarting!
j2james
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
April 04, 2018, 09:57:14 AM
 #1363

Hi Phoenix,

Can you think about new option in miner to switch to next pool from epools if average (for 5 minutes, for example) share accepting time is more then configured? It will require to define for each pool its own time. Also may be some conditions should be used to back to previous pool. I think if you will like this idea, you will find the best solution for this issue.
Bigdrago
Newbie
*
Offline Offline

Activity: 309
Merit: 0


View Profile
April 04, 2018, 10:10:58 AM
 #1364

Do this have the same autotune function as claymore?
j2james
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
April 04, 2018, 10:13:16 AM
 #1365

Anybody knows why invalid shares is present? I'm in mining about 3 months, but only yesterday I had two invalid shares (on different cards). I use Phoenix miner now and use it about a week. Before that I used Claymore. And only yesterday I had caught 2 invalid shares. Can it be result of overclocking or no? Is it normal or no?
j2james
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
April 04, 2018, 10:14:42 AM
 #1366

Do this have the same autotune function as claymore?

Claymore does not have this functionality as I know.
inv1s1bl3
Newbie
*
Offline Offline

Activity: 67
Merit: 0


View Profile
April 04, 2018, 10:23:08 AM
 #1367

Hello guys! I have been using this miner for a long time now, but I just cannot understand something:

17625:13:20:17.214: main GPUs: 1: 31.507 MH/s (1) 2: 31.487 MH/s (5) 3: 31.485 MH/s (2) 4: 31.484 MH/s (6) 5: 30.601 MH/s (1)
17625:13:20:17.415: main GPU1: 50C 48%, GPU2: 52C 58%, GPU3: 50C 47%, GPU4: 46C 49%, GPU5: 49C 39%

All of my cards are the same, with the same BIOS modifications and setups! Why are some generating more heat than the others? I have tried to read the log file, but it's just not giving any infromation about that.
In HWINFO all stats are the same.
Jbodz83
Newbie
*
Offline Offline

Activity: 125
Merit: 0


View Profile
April 04, 2018, 10:39:30 AM
 #1368

Hello guys! I have been using this miner for a long time now, but I just cannot understand something:

17625:13:20:17.214: main GPUs: 1: 31.507 MH/s (1) 2: 31.487 MH/s (5) 3: 31.485 MH/s (2) 4: 31.484 MH/s (6) 5: 30.601 MH/s (1)
17625:13:20:17.415: main GPU1: 50C 48%, GPU2: 52C 58%, GPU3: 50C 47%, GPU4: 46C 49%, GPU5: 49C 39%

All of my cards are the same, with the same BIOS modifications and setups! Why are some generating more heat than the others? I have tried to read the log file, but it's just not giving any infromation about that.
In HWINFO all stats are the same.
i had the same observation before. and then i realize that my GPU position on each other causes the middle GPU in higher temp.
airflow and other ventilation could cause this i believe. Smiley
inv1s1bl3
Newbie
*
Offline Offline

Activity: 67
Merit: 0


View Profile
April 04, 2018, 10:44:29 AM
 #1369


i had the same observation before. and then i realize that my GPU position on each other causes the middle GPU in higher temp.
airflow and other ventilation could cause this i believe. Smiley

I thought that also, but all of my cards are placed within 15cms apart. It is not like one is closer to the other Cheesy
Jbodz83
Newbie
*
Offline Offline

Activity: 125
Merit: 0


View Profile
April 04, 2018, 11:11:02 AM
 #1370


i had the same observation before. and then i realize that my GPU position on each other causes the middle GPU in higher temp.
airflow and other ventilation could cause this i believe. Smiley

I thought that also, but all of my cards are placed within 15cms apart. It is not like one is closer to the other Cheesy
Grin lets just say that not all GPU are the same? Smiley then again, nothing to worry as your RIG is at the best temps.
jimsta
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile
April 04, 2018, 01:23:20 PM
 #1371

Do this have the same autotune function as claymore?

Claymore does not have this functionality as I know.

Claymore has auto DCRI adjustment for each inidividual card starting with 11.4 and up.  It gives me about 3-4 more MH in total on my 8 card rig and about 1MH more on my 9 card rig.   my 3 card gaming PC there is no change but that's because I have 1 AMD and 2x Nvidia in there.
j2james
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
April 04, 2018, 04:11:11 PM
 #1372

Do this have the same autotune function as claymore?

Claymore does not have this functionality as I know.

Claymore has auto DCRI adjustment for each inidividual card starting with 11.4 and up.  It gives me about 3-4 more MH in total on my 8 card rig and about 1MH more on my 9 card rig.   my 3 card gaming PC there is no change but that's because I have 1 AMD and 2x Nvidia in there.

Sorry, my answer Claymore does not have this functionality as I know. is incorrect, because I did not understood the question Sad
janding
Newbie
*
Offline Offline

Activity: 137
Merit: 0


View Profile
April 04, 2018, 05:01:44 PM
 #1373

Anybody knows why invalid shares is present? I'm in mining about 3 months, but only yesterday I had two invalid shares (on different cards). I use Phoenix miner now and use it about a week. Before that I used Claymore. And only yesterday I had caught 2 invalid shares. Can it be result of overclocking or no? Is it normal or no?

Every time I have ever seen an invalid share it is because the GPU clock to too high.
If you are right on the edge of being too high you will occasionally get one. I think if you back
the clock down by 15 or 20 that issue will go away.

inv1s1bl3
Newbie
*
Offline Offline

Activity: 67
Merit: 0


View Profile
April 04, 2018, 05:22:02 PM
 #1374

Do this have the same autotune function as claymore?

Claymore does not have this functionality as I know.

Claymore has auto DCRI adjustment for each inidividual card starting with 11.4 and up.  It gives me about 3-4 more MH in total on my 8 card rig and about 1MH more on my 9 card rig.   my 3 card gaming PC there is no change but that's because I have 1 AMD and 2x Nvidia in there.

Wow, this made me look for the latest Claymore miner and test it, sadly the case with me is that Phoenix's miner is giving me the best and most optimal rig performance... but I really liked the idea to see my cards pulling around 32mh/s + Cheesy

Btw, since 2.8c the stale shares have dropped from 7-8 per hour to less than 5!
Falconnn
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
April 05, 2018, 12:44:27 AM
 #1375

PhoenixMiner 2.8c tested on AMD and NVIDIA rig, my observations are:
Nvidia rig works 3-5Mhs more then Claymore 11.5  P106 runs 25.7-26.1, GTX1070 33.2 GTX1060 24.1
AMD rig on RX570 8GB have 2Mhs less around 29, claymore have 31+ and little less on RX 470 around 32.6, claymore 11.6 have 32.8
On awesomeminer dont see Progress on Nvidia card how many accepted, Rejected...
I have problems on NVIDIA P106 cards, with fan controls, does not show a percentage, got error after few minuts
with some fixes, the program will be really good
milos957
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
April 05, 2018, 05:25:18 AM
Last edit: April 05, 2018, 05:44:59 AM by milos957
 #1376

Something weird happened tonight on one of my two rigs. Early this morning I noticed on ethermine.org that one rig with 8xRX 480 cards did not work for about 5 hours.
https://imgur.com/a/dASLC
I approached the rig and, surprisingly, noticed that he worked steadily since the last restart I did about 8 hours before.
https://imgur.com/a/bLLTP
I checked the log file and I realized that there was no errors or restart in it. I reviewed the Task Manager and found that PhoenixMiner.exe on this rig uses about 887 MB of memory, which is roughly 441 MB more compared to the 8xRX 580 cards running steadily on ethermine.org, practically twice as much memory.
https://imgur.com/a/vL3r8
I restarted the rig and he reappeared at ethermine.org, but I noticed that after 5 minutes of work PhoenixMiner.exe used 558 MB of memory and after 8 minutes 887 MB of memory again.
I do not know how the Phoenix miner could work permanently, and that ethermine org shows it does not work. This is not about any kind of hacking on the side, I think the problem is in the miner itself, maybe it's a bag in the miner. I'd like to hear your suggestions.
panzer168
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
April 05, 2018, 05:49:10 AM
 #1377

Something weird happened tonight on one of my two rigs. Early this morning I noticed on ethermine.org that one rig with 8xRX 480 cards did not work for about 5 hours.
https://imgur.com/a/dASLC
I approached the rig and, surprisingly, noticed that he worked steadily since the last restart I did about 8 hours before.
https://imgur.com/a/bLLTP
I checked the log file and I realized that there was no errors or restart in it. I reviewed the Task Manager and found that PhoenixMiner.exe on this rig uses about 887 MB of memory, which is roughly 441 MB more compared to the 8xRX 580 cards running steadily on ethermine.org, practically twice as much memory.
https://imgur.com/a/vL3r8
I restarted the rig and he reappeared at ethermine.org, but I noticed that after 5 minutes of work PhoenixMiner.exe used 558 MB of memory and after 8 minutes 887 MB of memory again.
I do not know how the Phoenix miner could work permanently, and that ethermine org shows it does not work. This is not about any kind of hacking on the side, I think the problem is in the miner itself, maybe it's a bag in the miner. I'd like to hear your suggestions.

I mine on nanopool and I got that too. One of my rig stopped mining for some reason, but the rig remained power on, it seemed like it has crashed or something.
PhoenixMiner
Member
**
Offline Offline

Activity: 220
Merit: 13


View Profile
April 05, 2018, 06:02:17 AM
 #1378

Any plans for CryptoNote miner or integration, would be great?
  Not in the immediate future but in a few months a lot could and probably would change.  Wink

This is my hashrate and stale share percentage in Claymore 11.6

https://image.ibb.co/iz6vBc/ETC.png

Phoenix can tap my RIG up to 395Mhs (13GPU) however, it gives me 5-6% stale share..

i like the hashrate spike from PhoenixMiner, but i guess effeciency goes to Claymore 11.6 - hope that PhoenixMiner could catch up soon.. Cool
   This problem seems to impact a fair share of users so we tested like crazy but the results are really puzzling. For example, in the most pure form of testing - with a test network proxy that eliminates all latencies, the difference is less than 1% (as it should be) and virtually zero when using the new 2.9 branch which lowers the internal stale shares to about 0.1%. Also, when checking out one of the many devfee addresses of Claymore, we get the following on ethermine, ethpool and ethermine-etc at the moment of this writing (this is a great way of comparison as represents the average stale shares of many rigs):
https://www.ethermine.org/miners/34FAAa028162C4d4E92DB6abfA236A8E90fF2FC3/dashboard4%
https://www.ethpool.org/miners/34FAAa028162C4d4E92DB6abfA236A8E90fF2FC3/dashboard3%
https://etc.ethermine.org/miners/34FAAa028162C4d4E92DB6abfA236A8E90fF2FC3/dashboard4%

Now, compare this to our devfee wallet (we have three on ethermine, and one on ethpool and ethermine.etc):
https://www.ethermine.org/miners/00d4405692b9F4f2Eb9E99Aee053aF257c521343/dashboard5%
https://www.ethpool.org/miners/00d4405692b9F4f2Eb9E99Aee053aF257c521343/dashboard3%
https://etc.ethermine.org/miners/d549Ae4414b5544Df4d4E486baBaad4c0d6DcD9d/dashboard4%
The difference is way smaller than what is observed by a lot of users (and confirmed by our own tests when we use a single mining rig or small group of rigs). As we said, in version 2.9, the internal stale shares are almost zero (the job change latency from the moment the new job is received from the pool to the moment first hash is computed is less than 30 ms), so if this doesn't solve the problem, it would be very strange indeed.

Glad to be able to try Phoenix Miner, I'm mainly an AMD miner across 3 rigs.  I did notice that Phoenix miner on a 9 card AMD rig mixed of rx 570/580 pulled an extra 20 watts (from the wall) compared to the 1180 (from the wall) of Claymore 11.4, not a biggie because it's so small but I'm just a bit curious.

Hashrate is the same between both.

my other rig which is a smorgasboard of different brands of cards is about 4-5 MH/s lower using phoenix.

Is it possible to customize the GT/DCRI for each individual card?

I like the output and format of Phoenix way better but at this moment only using it on 2 of my rigs (the other Nvidia).

Thanks for the miner!
  Thank you for trying our miner. We are preparing a new version that will be released soon with substantial improvements in the AMD kernels in both speed and latency (which should decrease stale shares). Yes, you can specify different -gt (or -dcri) for each GPU by using -gt 15,18,15,15 for example for 4 GPU rig.


Hi Phoenix, can you change time logging in the next release to be more user friendly?

Now you use format

17625:02:43:37.171

But for me 17625 looks strange. I really do not know what is it. Can you log date instead of 17625?

Another point. I use -minRigSpeed 188 option. It should do restart if avg hashrate is less then 188 during last 5 minutes. But this is not true. Please look at log. Only 1 minute I had hashrate less then 188. Not 5 minutes, but rig was rebooted

Code:
17625:12:05:42.811: main *** 36:37 ***************************************************
17625:12:05:42.811: main Eth: Mining ETH on eth-eu1.nanopool.org:9999
17625:12:05:42.811: main Eth speed: 173.852 MH/s, shares: 2541/0/2, time: 36:37
17625:12:05:42.811: main GPUs: 1: 29.437 MH/s (390) 2: 28.839 MH/s (437/1) 3: 29.572 MH/s (445/1) 4: 28.203 MH/s (451) 5: 29.520 MH/s (396) 6: 28.282 MH/s (422)
17625:12:05:42.811: main Eth: Accepted shares 2541 (27 stales), rejected shares 0 (0 stales)
17625:12:05:42.811: main Eth: Incorrect shares 2 (0.08%), est. stales percentage 1.06%
17625:12:05:42.811: main Eth: Maximum difficulty of found share: 46.1 TH (!!!)
17625:12:05:42.811: main Eth: Average speed (5 min): 184.180 MH/s
17625:12:05:42.811: main Eth: Effective speed: 192.72 MH/s; at pool: 192.72 MH/s
17625:12:05:42.811: main  
17625:12:05:42.811: main Average ethash speed for 5 min is below minimum of 188 MH/s. Restarting!
  Yes, you are quite right, 17265 is not something that is meaningful in the real life (it is the number of days since the Unix epoch - Jan 1st, 1970). This was done to save a bit of CPU time to avoid converting to the local time but it is nothing really, so we will change it to a more understandable format in the future releases.
 
    As for your second question: -mirRigSpeed tracks the 5 minute average speed (the same which is shown every 40 seconds or when you press the key s), which is using five minute floating window (i.e. it is the average speed for the last five minutes). For example if the speeds was 200 MH/s but dropped to 100 MH/s two minutes ago, the 5 min average will be 160 MH/s (computed as ((200 * 3) + (100 * 2)) / 5). In your case you can see that the speed has dropped to 174 MH/s for some time so the average speed has also dropped to 184 Mh/s.

Hi Phoenix,

Can you think about new option in miner to switch to next pool from epools if average (for 5 minutes, for example) share accepting time is more then configured? It will require to define for each pool its own time. Also may be some conditions should be used to back to previous pool. I think if you will like this idea, you will find the best solution for this issue.
   This is actually a pretty good idea. We are planning to add detailed pool statistics (share acceptance time, job change time, rejected shares rate, etc.) and this would be a nice way of using the statistics for more than just information. We will probably implement this in the near future.

Do this have the same autotune function as claymore?
  Not yet, will be added soon.

Anybody knows why invalid shares is present? I'm in mining about 3 months, but only yesterday I had two invalid shares (on different cards). I use Phoenix miner now and use it about a week. Before that I used Claymore. And only yesterday I had caught 2 invalid shares. Can it be result of overclocking or no? Is it normal or no?
  As long as the incorrect shares are just a few there is nothing to worry about. If they are on different cards, the most probable reason is that the pool is changing the jobs like crazy (two or more changes for less than two seconds) and the computed share was valid but too old (i.e. more than one generation older than the current one). If the incorrect shares become more (more than 0.2-0.5%) and are on the same GPU, then you may have problem with too much overclock.

Hello guys! I have been using this miner for a long time now, but I just cannot understand something:

17625:13:20:17.214: main GPUs: 1: 31.507 MH/s (1) 2: 31.487 MH/s (5) 3: 31.485 MH/s (2) 4: 31.484 MH/s (6) 5: 30.601 MH/s (1)
17625:13:20:17.415: main GPU1: 50C 48%, GPU2: 52C 58%, GPU3: 50C 47%, GPU4: 46C 49%, GPU5: 49C 39%

All of my cards are the same, with the same BIOS modifications and setups! Why are some generating more heat than the others? I have tried to read the log file, but it's just not giving any infromation about that.
In HWINFO all stats are the same.
  One possible reason is the card location (first one with open fans that suck cold air is usually the coolest), another is the difference between the chips themselves, VRMs, etc. Even on the same voltage, some chips/VRMs just consume more power than the others, which translates to more heat.

PhoenixMiner 2.8c tested on AMD and NVIDIA rig, my observations are:
Nvidia rig works 3-5Mhs more then Claymore 11.5  P106 runs 25.7-26.1, GTX1070 33.2 GTX1060 24.1
AMD rig on RX570 8GB have 2Mhs less around 29, claymore have 31+ and little less on RX 470 around 32.6, claymore 11.6 have 32.8
On awesomeminer dont see Progress on Nvidia card how many accepted, Rejected...
I have problems on NVIDIA P106 cards, with fan controls, does not show a percentage, got error after few minuts
with some fixes, the program will be really good
  We are preparing a new version with faster AMD kernels.  If you are getting error 999 on the Nvidia card, you should lower the memory clock a little.

Something weird happened tonight on one of my two rigs. Early this morning I noticed on ethermine.org that one rig with 8xRX 480 cards did not work for about 5 hours.
https://imgur.com/a/dASLC
I approached the rig and, surprisingly, noticed that he worked steadily since the last restart I did about 8 hours before.
https://imgur.com/a/bLLTP
I checked the log file and I realized that there was no errors or restart in it. I reviewed the Task Manager and found that PhoenixMiner.exe on this rig uses about 887 MB of memory, which is roughly 441 MB more compared to the 8xRX 580 cards running steadily on ethermine.org, practically twice as much memory.
https://imgur.com/a/vL3r8
I restarted the rig and he reappeared at ethermine.org, but I noticed that after 5 minutes of work PhoenixMiner.exe used 558 MB of memory and after 8 minutes 887 MB of memory again.
I do not know how the Phoenix miner could work permanently, and that ethermine org shows it does not work. This is not about any kind of hacking on the side, I think the problem is in the miner itself, maybe it's a bag in the miner. I'd like to hear your suggestions.
  You have fallen victim of the MITM scamers (so called IP hijack attack). The IP address of the ethermine server was hijacked by hackers (this happens in your ISP, so it is not your rig's fault but the result is still the same. You can see the telltale sign of the 10000 MH difficulty, which is never used by ethermine (their jobs are always with 4000MH difficulty). Fortunately, there is quick and easy fix the prevent similar problems in the future: use the encrypted (SSL) address of ethermine like this: -pool ssl://eu1.ethermine.org:5555. Note that the address starts with ssl:// and the port is 5555.


Digital_Seytan
Newbie
*
Offline Offline

Activity: 134
Merit: 0


View Profile
April 05, 2018, 10:36:36 AM
Last edit: April 05, 2018, 11:47:00 AM by Digital_Seytan
 #1379

I have used a long period of Claymore miner which I notice with claymore miner is very unstable and often fixed and a high negative very high DEVFEE, and then I switched to Phoenixminer which is very stable and almost never jammers only shame hashrate measurement on the pole is always a lot lower than the measurement of phoenixminer 2.8.c and the AVG on the pole remains low and of course a lower Devfee, but still you lose a lot, trowens nodevfee works perfectly, But after a long period of use of ETHMINER 14.3 I come behind no Devfee open software and higher AVG and Hashrate on the pool super and much and many times better than Phoenixminer and Of course much better than Claymore (is a real thief)
I am of course curious about the findings of other users.

http://www.resimag.com/p1/6717fbc241.jpeg

Download PhoenixMiner 2.8c:
https://mega.nz/#F!2VskDJrI!lsQsz1CdDe8x5cH3L8QaBw

Download: Claymore 11.5:
https://github.com/digitalpara/download-NODEVFEE-CLAYMORE-11-5---DevFee-Removed

Download: Claymore 11.6:
https://github.com/digitalpara/download-NODEVFEE-CLAYMORE-11-6---DevFee-Removed

Download Ethminer 14 with watchdog:
https://github.com/digitalpara/NODEVFEE-ETHMINER-14-3---Auto-start-WatchDog

I am really curious what the phoenixminer version 2.9 has to offer, and minimal devfee on or off function
Jbodz83
Newbie
*
Offline Offline

Activity: 125
Merit: 0


View Profile
April 05, 2018, 10:51:49 AM
 #1380

Any plans for CryptoNote miner or integration, would be great?
  Not in the immediate future but in a few months a lot could and probably would change.  Wink

This is my hashrate and stale share percentage in Claymore 11.6

https://image.ibb.co/iz6vBc/ETC.png

Phoenix can tap my RIG up to 395Mhs (13GPU) however, it gives me 5-6% stale share..

i like the hashrate spike from PhoenixMiner, but i guess effeciency goes to Claymore 11.6 - hope that PhoenixMiner could catch up soon.. Cool
   This problem seems to impact a fair share of users so we tested like crazy but the results are really puzzling. For example, in the most pure form of testing - with a test network proxy that eliminates all latencies, the difference is less than 1% (as it should be) and virtually zero when using the new 2.9 branch which lowers the internal stale shares to about 0.1%. Also, when checking out one of the many devfee addresses of Claymore, we get the following on ethermine, ethpool and ethermine-etc at the moment of this writing (this is a great way of comparison as represents the average stale shares of many rigs):
https://www.ethermine.org/miners/34FAAa028162C4d4E92DB6abfA236A8E90fF2FC3/dashboard4%
https://www.ethpool.org/miners/34FAAa028162C4d4E92DB6abfA236A8E90fF2FC3/dashboard3%
https://etc.ethermine.org/miners/34FAAa028162C4d4E92DB6abfA236A8E90fF2FC3/dashboard4%

Now, compare this to our devfee wallet (we have three on ethermine, and one on ethpool and ethermine.etc):
https://www.ethermine.org/miners/00d4405692b9F4f2Eb9E99Aee053aF257c521343/dashboard5%
https://www.ethpool.org/miners/00d4405692b9F4f2Eb9E99Aee053aF257c521343/dashboard3%
https://etc.ethermine.org/miners/d549Ae4414b5544Df4d4E486baBaad4c0d6DcD9d/dashboard4%
Quote
The difference is way smaller than what is observed by a lot of users (and confirmed by our own tests when we use a single mining rig or small group of rigs). As we said, in version 2.9, the internal stale shares are almost zero (the job change latency from the moment the new job is received from the pool to the moment first hash is computed is less than 30 ms), so if this doesn't solve the problem, it would be very strange indeed.

appreciate the time comparing and clear justification, i am looking forward to see 2.9 outperform Claymore.
what i like about PM is that it could maximize my GPU's capability to hash up to 31.2Mhs for 580's which has a difference of .5 Mhs from Claymore.
having 1-2% of stale share is reasonable enough to shift to PM, i am still trying out other settings using PM though.

thanks and appreciate your feedback.
Pages: « 1 ... 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 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 ... 186 »
  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!