Quote from: MaxMidnite on April 03, 2018, 05:19:32 PM

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

Quote from: Jbodz83 on April 03, 2018, 08:20:34 PM

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/dashboard	4%
https://www.ethpool.org/miners/34FAAa028162C4d4E92DB6abfA236A8E90fF2FC3/dashboard	3%
https://etc.ethermine.org/miners/34FAAa028162C4d4E92DB6abfA236A8E90fF2FC3/dashboard	4%

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/dashboard	5%
https://www.ethpool.org/miners/00d4405692b9F4f2Eb9E99Aee053aF257c521343/dashboard	3%
https://etc.ethermine.org/miners/d549Ae4414b5544Df4d4E486baBaad4c0d6DcD9d/dashboard	4%

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.

Quote from: jimsta on April 04, 2018, 03:10:04 AM

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.

Quote from: j2james on April 04, 2018, 09:16:35 AM

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.

Quote from: j2james on April 04, 2018, 09:57:14 AM

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.

Quote from: Bigdrago on April 04, 2018, 10:10:58 AM

Do this have the same autotune function as claymore?

Not yet, will be added soon.

Quote from: j2james on April 04, 2018, 10:13:16 AM

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.

Quote from: inv1s1bl3 on April 04, 2018, 10:23:08 AM

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.

Quote from: Falconnn on April 05, 2018, 12:44:27 AM

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.

Quote from: milos957 on April 05, 2018, 05:25:18 AM

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.