...
does -acm setting makes any different under linux? claymore states that under linux no need for comput mode.
This is partially true. Under Linux, this is not called Compute mode, and -acm won't do anything but you can still have the same problem (big drop in hashrate in DAG epoch 180+ vs DAG epoch 2) because of the TLB thrashing when the DAG size increases. If you are seeing such hashrate drop under Linux (and it is quite noticeable when mining ETH or ETC), you need to enable the large page support as described here:
https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx (in the "Large page support") section. Note that in the latest AMD drivers for Linux this is supposed to be turned on by default, and in the drivers before 17.40, it may not have an effect at all.
Hello PhoenixMiner i'm use mine Nicehash but always switch DAG, re-connection mining and Shut Down mine using last drivers 18.9.3. So can use Drivers 18.8.2 for MSI RX580 4gb working to Nicehash?
Thanks.
The drivers shouldn't be a problem. In 18.9.3 there weren't relevant changes in the OpenCL implementation, so using 18.8.2 probably won't make a difference. Could you please send us a log (preferably whenever the problem is happening) to see what is going wrong?
hashrate goes to zero on the pool but the miner shows as if it's working just fine. Works fine in claymore...
This seems like the IP hijack attack aganst your network/ISP. Please try using an SSL-enabled pool like ethermine (e.g. -pool ssl://eu1.ethermine.org:5555 instead of -pool eu1.ethermine.org:4444). If you are already using SSL pool, please send us a (partial) log to see if there are any clues what happens.
Will be added support of Ubiq (hardfork) algo?
Good day PM please Add --->> Will be added support of Ubiq (hardfork) New Ubqhash algo?
We will probably add support but not in the next release, as we are trying to finish it ASAP. The change seems small but it requires a lot of conditional checks and changes in the code that need to be thoroughly tested, etc, which can easily add a week or two to our schedule.
Mined now for few days and seems that phoenix is little faster than claymore.
After adding -mi settings, started mining better. -gt still auto tune. started mining prezzed Z and -gt was calculated.
Notised that after coin network difficult changes about 10TH (up or down), then was need to auto tune -gt setting again, was mining better.
So there is suggestion to phoenix , can you add setting that monitor coin network difficult and if changes in difficult are big then phoenix calculates new -gt settings.
Exsample: ETC dif 197TH calculated first, dificult rised to 206TH need to calculate again -gt settings. And this up and down goes every day.
This few minutes autotune is worth.
Theoretically, there shouldn't be need to recalculate the -gt values whenever the network difficulty change. Probably something else has changed like the driver version, the PM kernels (if you have upgraded PhoenixMiner since the last auto GT), the core and/or memory clocks, etc.). Also, it is not possible to get the network difficulty from the pool (it simply doesn't send us this information, only the share difficulty). However we may add an option to re-run auto-tune periodically in the future.
