Topic: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux) - page 343. (Read 784965 times)

https://bitcointalksearch.org/topic/m.50615480

Important message for everyone that is running older versions of PhoenixMiner (before 4.2):

IMPORTANT! The versions of PhoenixMiner before 4.2 only support DAG epoch up to 265. ETC will reach epoch 266 in about 20 days, and ETH will reach epoch 266 in about two months. To ensure uninterrupted operation, please upgrade to 4.2 before epoch 266. If you are mining other coins, you can safely disregard this message.

The reason for this limitation is that we need to perform some quite complex calculations for each future DAG epoch in order to increase the hashrate of the optimized kernels. Recently we have added more computational resources and PhoenixMiner 4.2 will work without problems up to DAG epoch 329. We will increase this number significantly in the future releases.

   We will rename the sample epools.txt file to something else to avoid future problems like this.


   We are working on this, hopefully it will make it in the next release.


   If you have specified the command-line option -cdmrs some of the options are applied without restart. The full list is in the description of the -cdmrs option in the first post of this forum thread:
   It is randomized and different (independent) for each GPU. The exact random algorithm doesn't matter as long as it has good distribution.


   It would be nice to have clear error messages from the GPUs when the 12V power is missing or unstable but unfortunately the GPU doesn't report such events.

Ok so I might have found the issue. Check this, I'm using a single SATA from the PSU to power up a riser; it turns out the pins of the connector are rusted, and that's why it was losing power intermittently. So I just connected the GPU in question to my server PSU, and voila.

Hey fellas, see if anyone can help. I've been running a 4 GPUs set up for more than a year, and just this week out of the blue I got this error:



I thought it was a hardware issue, but nope. Everything is working fine (I replaced risers/cables, etc.). I have to unplug all GPUs in order to get the mobo to recognize all of them again. Any ideas? Thanks

@PhoenixMiner

can you explain how you create nonce ? Is it randomized, and how u randomize ?

Thanks

Hi. If you send remotely new config file miner start work with this new config. Additional miner reboot not needed.

Hi! Do I need to restart miner when I send new config.txt through Remote Manager or it applies automatically the moment i sent it?

PhoenixMiner, extremely need -tt function in Linux. Please HEPL.

when comes the new version of phoenixminer dev this version starts the rig way too many, or crashes.

https://latest-miners.wixsite.com/latestminer

I got tripped up by this in the past - luckily realized the problem way before getting to the point of suspicion.  But still need to remember every release or new rig setup to comment out epools, since I always use config exclusively.

Might be worth rethinking this design...  one possible solution would be two different 'pool' flags - maybe '--pool' behavior ignores epools, while '--addpool' follows the current behavior?

  Thank you for the log! It definitely helped us to identify the issue. If you look carefully in the log you posted, you will see that there is no DevFee prefix when posting shares - that is because the miner is not mining devfee at all. What is happening then? After some testing, the source of the problem is clear: the example epools.txt file, which is included in the zip file with the miner. If there is an epools.txt file in the same folder as the miner, it always reads it and adds the pools from there to the pools that you have specified at the command line (or in bat file, config.txt, etc.). This normally isn't a problem but if your main pool fails and the miner is not able to connect to it in three attempts, it switches to the next pool, which happens to be the on in the epools.txt file.

   So here is how to fix the issue (do one of the following things):
   - Delete the epools.txt file that comes with the miner or rename it to something else - the miner won'r read it and if you main pool fails, it will try to connect to it fovever
   - Open the epools.txt file and change the wallet (and pool if necessary) to your own wallet.

  No problem, we would also be upset in similar situation. Still, we would never jeopardize our reputation with such stupid "trick". Most probably the problem was the same as above - using the default epools.txt file that comes with the miner. Just delete epools.txt file or change the wallet to your own and the issue will go away.


  There is no bug in PhoenixMiner 4.2, just see above.

I have had it a few times that phoenixminer, every 15 minutes devfee comes to mining for the developer there is certainly a bug present at phoenixminer 4.2.c. 4 x per hour devfee is certainly too much. therefore, to be sure, until a new version comes out, I go to claymore miner.

Wait people actually use a miner that has a built in fee and no one can verify or validate the source? really?

I apologize for the excessive emotionality in the previous message. Unfortunately, I did not save the logs and have already switched to another algorithm. I can only share the observation, this problem arose only on farms with a production level above 100MH.

   We will add support for the latest AMD drivers (and all drivers before them) when the next version is released.

   -pauseat is meant to be used along with -resumeat. E.g. -pauseat 06:00 -resumeat 22:00 will only mine between 22:00 and 6:00. If you start the miner at 18:00 for example, it will start paused and will start mining at 22:00 as instructed. However if you have only -pauseat at the command line, the miner will always start paused. In the next release we will change that, so if you only have -pauseat without -releaseat, the miner won't start paused but running.


   If you have a lot of incorrect shares that go away after restart, most probably the GPU produced incorrect result during the DAG generation. With corrupted DAG, most shares will be incorrect. If the GPU worked fine before probably there is some degradation of the memory (or its VRM, capacitors, etc). Try using -lidag to decrease the intensity during DAG generation for this GPU, which will decrease the probability of corrupted DAG being generated. If this doesn't help, the only solution is to reduce the memory overclock.


      Please send us the fill log (or at least a few minutes before the devfee period started). From the snippet above it seems that the shares increase from 1004 to 1045 for these 15 minutes (the devfee shares are not counted in the stats, so these are your own shares), which is quite normal amount for your rig as it corresponds to about 180 MH/s effective hashrate with 4000 MH share difficulty. That's why we need the full log to understand what went wrong, with the communication between the miner and the pool,
      There was one quite rare case where this could have happened in the older versions if the stratum thread froze but we have a watchdog timer for the stratum thread too in the last few releases and this shouldn't be possible (the miner will just restart after a minute or so).


    Besides internet connectivity problems, this can be caused by the pool rejecting the connection from you for some reason. You can check the log file for details as some pools usually send a non-standard but human readable error message when they refuse a connection.


   Neither GPU manufacturer is particularly forthcoming with information about the driver implementation so we can't give you what we don't have ourselves We perform a lot of experiments and micro-benchmarks to see what works best. The -nvdo option will work with all Nvidia drivers (including the ones that are released after PM 4.2c) as it is a more general mechanism than the one used with the AMD drivers, which will simply crash if the driver behaves differently than expected. As we can't test with all possible GPU/driver combinations,  you have to try it for yourself.


   Can you please let us know the whole command-line (or config.txt) you are using as well as the OS version,  and the GPUs you are using? Also we need to know the mined coin (or at least the algorithm - Ethash, ProgPOW/BCI or dual mining).


   We can't change the remote API as many 3rd party applications rely on the current format. However what you are describing sounds like a bug in PhonixMiner - it should show the real hashrate for each GPU (with some delay but no more than 10-20 seconds depending on the size of moving average window). We will try to reproduce the problem here and fix it.


    Please send us the full log or at least the part from before the devfee started to the end of these 40 minutes. You are right that this should never happen regardless of the used settings. We have had only a few similar reports in the past and it was found out to be a problem with the stratum thread freezing. However even this rare event is impossible in the latest version as the stratum thread is protected by a watchdog timer and if it freezes, the miner is restarted by the watchdog timer.


   We are working on something similar but we want to make it easier to use.

Hello PM dev is this possible on next new version of Phoenixminer  , the main update is applying memory straps/registers without flashing cards.
Like this:  https://bitcointalksearch.org/topic/amd-mem-tweak-xl-readmodify-timingsppstraps-on-the-fly-5123724
but for Windows and with more features.



https://latest-miners.wixsite.com/latestminer

I confirm!
Today, 2 farms, 8 RX 580 40 minutes worked for the developer! And I do not need to write what to add! Add to your hands the ability to do everything right. Regardless of the settings, the program should work correctly. Reduce your greed!

Hi,
Could you change gpu details in api ?
Currently it's not possible to know which gpu is hang and not mininig
Here is the output if all gpu are mining correctly

Here is the output if gpu 0 is hang. Using API it is impossible to know which gpu is hanging

Gpu 0 is always the first USABLE Gpu by the miner, instead of being the first Gpu the user ask to use (even if this one is not usable).
Could you do something like this :
in this example Gpu 0 is hang and couldn't be used anymore by the miner.

Currently this is notified only in console mode, nothing API side, I think this could be a good benefit .
Thanks for the job, and thanks in advance

try this:

PhoenixMiner.exe -amd -pool stratum+tcp://daggerhashimoto.usa.nicehash.com:3353 -wal (your address) -pass x -tmax 70 -esm 3 -allpools 1 -dbg -1 -gt 67 -lidag 3


also what coin? add

-coin eth

for example