Quote from: j2james on April 13, 2018, 08:24:31 AM

Quote from: PhoenixMiner on April 13, 2018, 07:09:46 AM

The -logsmaxsize option defines the max size of all log files, not a single file, so 200 MB should be adequate if you want to keep a history for the last few weeks (or months). We don't have a limit of the size of a single logfile but it may be added in the future.

Strange solution. Never seen that. For example in java there is RollingFileAppender (https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/RollingFileAppender.html) which creates new log file when current file has reached limit size. I waited to have the same functionality, and I think that not only me. If the current behaviour is like you have described, then can you please to use parameter 0 as recomendation do not delete logs (so limit is absent).

It already works like that: -logsmaxsize 0 turns off the automatic removal of oldest log files on startup. As for the limit on the size of individual log files - this is good idea and may be implemented in the future versions of the miner.

Quote from: fimatiku on April 14, 2018, 04:29:13 AM

After running PM 2.9d for few days yes it "SHOWS" higher hash rate but the time it takes to CLEAR a block for me INCREASED as apposed to running CL

some would say difficulty increased Huh

Id have to run it for 2 weeks to collect data and then switch back to CL and collect more data to eliminate that theory

As we stated many times, the best way to compare is to see the shares (assuming the same share difficulty!) over some time period (not too short to avoid luck being too much of a factor). Note that PhoenixMiner already does these calculations for you and shows you the effective hashrate, even if you switch to pools with different difficulty.

Quote from: drgrog on April 14, 2018, 09:11:44 AM

Tried Phoenix 2.8c today. Mostly good, but have a problem with the remote monitoring.

I have a basic python script using sockets to monitor all rigs and send me alerts if things go wrong.
This works with claymore, which says it uses raw TCP/IP connections (not HTTP) for remote management.
This same script does not work with Phoenix, and hangs when waiting for data from the miner.

It sends the request JSON as per the claymore API {"id":0,"jsonrpc":"2.0","method":"miner_getstat1"}
It then waits for the response, expecting {"result": ["9.3 - ETH" ... data, but it never gets any data.
It uses the socket.recv(1024) method which blocks until there is some data to be read.

The remote monitoring is enabled, and responds to HTTP requests on 3333, showing a html version of the console.
Interestingly claymore's EthMan.exe does work and can see the rigs using Phoenix.

The devs say "Phoenix miner is fully compatible with Claymore's dual miner protocol for remote monitoring and
management.", so am I correct to assume that phoenix should support the raw TCP/IP requests in JSON format?

It's a pretty simple script, that works with claymore, perhaps someone can see if I'm doing something wrong, here is a stripped down version that hangs when waiting for data from the miner.

Code:

...

Anyone else got monitoring scripts working with Phoenix? Any idea what could be going wrong?

You have to add new line (\n) after the end of your JSON request.