We will look into this and try fixing it for the 2.8b release.
latest still wont attrack massive users until dual mining is implemented.
nonetheless, this is still the fastest and the most stable ethash miner.
if only dual wont benefit me much, ill transfer here.
We will implement dual mining eventually.
On my RX 580 cards Claymore miner 11.5 still a bit faster. About 0,25-0,5%. His fee is 1%, Phoenix is 0,65. Result is no difference.
Phoenix gives much more rejected (staled) shares than Claymore's...
Continue to use Claymore...
Add an option like -ttli in Claymore. It enables low intensity mode on reaching pointed temperature...
There will be new experimental Ellesmere and Vega kernels in PhoenixMiner 2.8b. As for the -ttli option, in our experience the native GPU throttling works better: you just need to set -tmax (and -tstop with a few degrees higher temp) and the GPU should take care of throttling in a better way than it is possible by modulating the GPU usage via something like -ttli.
- CPU utilization during normal operation is lowered by about a factor of 10 regardless of the number of GPUs
sounds familiar
Well, we had to keep our advantage in this area
Hi Phoenix, great job on the miner, I've switched all my rigs completely to yours.
One quirk: I noticed your log is giving out a time that is one hour behind. For example, if it's 1:40pm in real time, the log will display current time as 12:40pm.
I'm based in Australia, where daylight savings is on currently. In about a couple weeks' time, our time will move 'behind' and essentially if the log does output the same time, the real time and log time will match.
Nonetheless, the problem still exists now. It's weird that the log is displaying 'timezone time disregarding daylight savings' instead of simply taking the computer's system time.
Could you please look into this? I have to manage 30+ rigs and little things like this can add up to a huge headache.
Thanks!
Sorry about that, we will fix it in 2.8b.
Thanks phoenix for this good software, phoenixminer 2.8a has been stable for a while already, only hashrate on the pole measurement is less than what the phoenixminer indicates also the stale shares number does not match with the pool ethermine program gives 6 stale shares but on the pool ethermine it is 11 once phoenix does not know what you have done but the share number is much less than the phoenixminer version 2.6.
I think the 2.6 version is the best in all fronts and More SHARES .
What do the other users of this software actually think phoenixminer 2.6 or 2.8a. my rig is gtx 1060 6gb 6x.
software windows 10 pro lite 64-bit- Nvidia driver 391.01
institution:
setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
PhoenixMiner.exe -pool eu1.ethermine.org:4444 -pool2 eu1.ethermine.org:4444 -wal 0xXXXXXXXXXXXXXXXX.rig4 -pass x -nvidia -proto 3 -ftimeout 120 -cdm 0 -mi 12 -log 0 -minRigSpeed 90.000 - rmode 2 -eres 0 -coin eth -coin2 eth
The stale shares reported by PhoenixMiner will always be lower than the ones at the pool, as explained many times in this thread (and in the FAQ in the first post). The number of shares for a small period of time can vary wildly and is not a good indicator of the speed.
Running 2.8a since yesterday evening, very stable even with my weakest GPU (lowest ASIC rate), same stale shares rate as 2.7C (2% the last hour).
I tried claymore V11.5 and got a hung GPU after 45mn (RX 570 4GB 1150MHz core / 2070MHz mem with bios mod), the same GPU can mine for hours and hours with phoenix.
Therefore I keep on using phoenixminer.
The new kernels for RX470/480/570/580 that are coming in 2.8b, should provide some speed increase as well, although their main goal is to increase stability and allow using higher mining intensity on the same voltages and clocks.
on claymore i have "-eres 0" for error cuda, add on phoenix this command please!
This command exists in Phoenix miner. And it's the same as in Claymore.
That is correct. However, -eres 0 is just a stopgap measure. After two more DAG epochs (i.e. in less than two weeks), the DAG memory problems will return again. The only real solution is to use either Windows 7 or some version of Windows, which doesn't hog GPU memory (some miners report good results with Windows Server 2016 but we can only confirm that Win 7 solves the problem for us).
Changes in version 2.7c (since 2.6):
* Supports AMD Vega, 580/570/480/470, 460/560, Fury, 390/290 and older AMD GPUs with enough VRAM
sigh,,,,,,
But it only supports compute 3.0 or higher Nvidia cards. Meanwhile ethminer, and other crypto apps support older Tesla cards from the c2050, m2050, and s2050 Fermi cored which haul ass still compared to some of the GTX series.. I have some 6GB and 3GB Teslas that still run well for CUDA 6.5 or higher.
Why is it when developers crank out a new and improved version they kill off support for the hardware that got the game started a while ago?
ccminer and a few others still have the source code or compiled archived versions out there.
Is there a previous version of PhoenixMiner that will support the older Fermi based cards?
The CUDA 9.1 dev kit can run on these cards.
[/list]
No, there never was any support for GPUs with less than CUDA cap 3.0 in PhoenixMiner.
There are no fundamental problems to adapt the CUDA kernels for older GPUs, but we don't have any of them to test on and probably (like 99% probability) there will be bugs and crashes. Also, we use some features that were first introduced in 3.0, and while it is possible to provide versions that work with 2.0 and 2.1, they will be substantially slower and might not be able to mine enough coins to even pay the power bill.
