Hi all,
I've been tinkering with the Phoenix Miner 1.6.2 on Linux for a while. Works great by the way (Phoenix miner that is).
So, I added some options to see things differently. Mostly, I've added a log-to-file option and a different way the work queue request new work.
The reason for this change at all was that I had problem with to many work requests and not many accepted or rejected shares, and I didn't understand why, when looking at an other rig things looked very different.
So, slowly I added more stuff and now is the time to show it to more ppl...
If you like the changes, mine with the flow (or whatever
)
You can leave a comment here as well if you like.
I only have released it as a diff against phoenix miner 1.6.2 and 1.6.4.
Here is the link:
http://www.benka.com/gpl/You need to have original miners source as well
https://bitcointalksearch.org/topic/phoenix-efficient-fast-modular-miner-6458 as this patch.
Implements all the 1.6.2 options as well as the following options
Options:
# -2 --use2phase:
Use the modified 2 phase queue worker, described below
# -B --showblock:
Show the received number of blocks on status line since this miner started.
# -c --showcompact:
Show the status line in compact mode.
# -d --showdevice:
Show the platform and device this miner is using.
# -f --showfrequence
:
Set the update frequency in seconds for status line. Not used when -n is active.
# -l --logtotext :
Log output to the specified log file. Status are constructed the same way as for on-screen, but are only updated before each new work. This option can be used with the -n option to only log to file and not to any screen. Log file can be rotated externally as it is closed upon every line written.
# -N --networkdelay :
Sets the network delay. This option compensates for the time it normally take for new work to receive through the network by making the request this many seconds sooner then needed so that the miner will have the work ready when it should. This option also sets the minimum time upon network delay, as it will not go below this value. Default value is 5 seconds. Minimum is 1 second. Note that even if we set the delay to 1 second, the miner checks the network delay on the fly and re-adjusts itself to compensate for flukes in network, even if it means that the request are made sooner then expected.
# -n --noshow:
Don't show anything on screen except errors. This can be used to mine using no screen at all.
# -P --showlongpull:
Show number of received long pulls on status line (if they are used in pool). This number should normally be one less then shown blocks, but can for several reasons be less. Most obviously, when network is unstable, long pulls can be missed. The miner rely mostly on the new block signal from pool, so this can be seen as an indication of network stability.
# -p --showpercent:
Show accepted/rejected work also as percent of received work. If -w is also specified, then that output also have a percentage against received work.
# -r --showreceived:
Show received work in status line. This is updated every time requested new work are received or when long pull is received (as it also contain new work).
# -t --addblocktime :
Add specific time averages as a comma separated list to show for new block arrivals.
# -v --verbose:
Show a lot of information about the internal workings of the miner. This can be seen mostly as a debug option, as it shows several things not normally needed to get the normal work done. if -l is also specified, information is put on the log file as well. This can be different information from the one shown on screen.
# -w --showwork:
Show a detailed report of the distributions of work, how many contained at least one accepted part (ActW), rejected part (RejW), did not have any accepted part at all (UsvW), was only checked partly (WstW) and work abandoned from work queue and never checked at all (AbnW). When the -p option is used as well, these are also shown as a percentage against received work.
When we use the -2 option, we change the behavior of the work queue. It starts out by measuring the time the kernel takes to complete some work, then using that information to delay the request of new work to the end of current check, so that new work normally will be available when the check is done, but not abandon any work if a long pull should be received in the middle of the check. Obviously, if the request for new work has been sent and also received so we have a queued work and long pull comes in, we must abandon that work as it refers to the previously block, which where just solved anyway. This behavior is not fully functionary if we use this miner on a very fast rig. As the delay of the request is set to be 5 seconds below the complete check of one work, any rig with a check time of say 10 seconds or less, benefits less from this change as it takes time for the network anyway to deliver new work.
Also, there is an effort to reduce stale work by network misses, as it checks the time it takes to deliver new work as well. If the time is exceeding 5 seconds, it alter the time waiting for new work by decreasing the wait time, thus holding work in the queue and also compensating for bad network delivery. This mature over time, so that some network misses are weeded out and delays are set down to 5 seconds again. If there is a major delay, the queue size is upped one to have at least one more work ready at all time. This can happen several times to up the queue several times. This behavior is also reduced if the time to deliver decreases, even to the point the queue can be shortened down to a length of 1.
A third thing implemented is; if the network goes down for 5 minutes, the connection is closed and reopened again. This is done regardless if we are using a backup pool or not, and the active pool is always connected to. This means that other measurements to handle pool activity (with backup pool) is still in place.
The two patches are roughly the same as I discovered today that the 1.6.2 and 1.6.4 are similar, only change as far as I can see is a 2 changed for a 4 on revision.... (I can be wrong though). Well yes I was... The change in 1.6.4 is mostly in the minerutl directory, which I only change the order of 2 calls in one routine.
When looking at a nVidia rig doing 22MH/s, at bitcoinpool.com I see with v1.6.2 something like 55-65% accepted shares compared to work requested.
With this patch the acceptance rate goes up to 80-95% (even on blocks taking 2 days) using the new -2 option.
When looking at a ATI HD6770 rig doing 186MH/s, at bitcoinpool.com I see with v1.6.2 something like 85-91% accepted shares compared to work requested.
With this patch the acceptance rate goes up to 95-110% (Yes, there can be more then one solution per work, seen up to 7)
Cheers,
/Muppion 
