Quote from: ultiman2 on January 24, 2018, 12:06:44 AM

what those two options change?
-mi when i use the default 10 i have a constant mhs, when i put 12 i have some up and down so what better?
-gt seem to not change a lot

The first option (-mi) changes the size of each "chuck" of work that is send to the GPU. The lower numbers mean generally lower and more unstable hashrate but you will be able to use your GPU for normal work without stuttering of the display, which is useful if the GPU is used for anything else than mining. Values above the default 10 aren't recommended because while they can marginally increase the hashrate, the number of stale shares will also increase and some GPUs may become unstable.
The second one (-gt), which can also be changed with + and - keys when the miner is running, is a way to fine tune the GPU for maximum hashrate. Because the memory timings of each GPU can be a little bit different (especially after BIOS mods and overclocoking/underclocking), the default value of 15 may not be the best (although we have found that it is the best for the 90% of the GPUs).
Please note that both -mi and -gt can be specified per-GPU, for example -mi 0,10,10,10,10,10 if you want only the first GPU of six GPU rig to mine with low intensity while using the PC and the display is connected to the first GPU.

Quote from: dagarair on January 24, 2018, 01:38:43 AM

One of the units crashed but did not report again to claymore manager and hash and everything looked correct. It was just scrolling dev fee disconnected and stopped or something like that. over and over and over again

Closed it and relaunched and it started to work as normal.

We have implemented a 180 second timer in version 2.5 that will stop the mining and report 0 hashrate to the manager in cases of lost connection that can't be restored. But the devfee disconnection issue is something new and will be fixed thanks to your report. Most probably the connection was lost at some short time period while the devfee was ending and some kind of race condition caused the loop.

Quote from: nitrobg on January 24, 2018, 07:42:17 AM

The miner didn't switch to the backup pool after one of ethermine's servers dropped. Needed a manual restart:

Quote from: rockk on January 24, 2018, 07:47:16 AM

today i got message unable to submit share to pool, but my other rig was connected just fine phoenix 2.4 as always. using ethminer eu.1 pool port 14444 , no failovers.

mitrobg -- maybe happend the same time with u and me also? weird.

We had the same problem at exactly the same time with eu1.ehtermine.org but our test servers reconnected successfully. Thank you for the log - from it seems that connection to the pool was restored but it never replied to the authorization request from PhoenixMiner and it didn't close the socket, so the miner was left waiting forever for the authorization from the pool. We will include a code to detect such weird pool connection issues in version 2.5.

Quote from: zeii on January 24, 2018, 01:11:46 PM

Pls add support for mining VIC without DAG switch on devfee. Thank you. Grin

We will look into it but it would probably have to wait until 2.6 as the stability improvements and fixes are with higher priority.

Quote from: yyyam2 on January 24, 2018, 02:45:03 PM

I notice there are some error "eth share timeout in xxxxx s". It happen once a while (about 3-4 hrs). I guess it is some kind of warning. What is it actually? Thanks!

After finding a share, the miner waits for a confirmation from the pool if it was accepted or rejected. Only after this confirmation, the share is included in the effective hashrate calculations and other statistics. If there is no confirmation after some (fairly long) time, the miner "writes off" the share as rejected. This message notifies you that a share that was found a few hours ago never received accept or reject response from the pool and was therefore considered rejected in the stats of the miner. There is no reason to worry about these messages if they are infrequent. If the happen too often, it means that the pool is overloaded or has same issues and doesn't respond properly to the found shares.