Thanks for the update.

I get similar as TeaRex results with an unmodified version of 1.7.0:


My command line was:

Using Ubuntu 10.04 LTS and a Geforce 240 graphic card (yea, I know it's way outdated for this)

I also noted that the reject rate is way higher with this version then with the 1.6.2 I normally use. With 1.6.2 I barely get rejects and when it does it is normally close to a long poll.

Looking closer to my output, I see that it has a strange error in there as well (at 11:09:12, 11:19:55 and 11:33:01) among others. It appears that it comes when I get a rejected result from pool.

Other things noted are that the 'New Block' output isn't always together with the 'LP: New work pushed' output.
Is it so that a new block can come without a previous long poll, or isn't the LP an indication of a new block every time (when LP is active that is)?

Cheers,

/Muppion

you can add the following lines before the start of cgminer to give the log file an unique name:

DAY=`date '+%F_%T'`
LOG=cglog-${DAY}.log

--------------------

You can then use the variable $LOG as the unique log file name for this run of the miner as in .... 2>$LOG

The different log files are named as date with time at the start of the name (as in cglog-2011-11-02_19:15:01.log).

(See date --help for more formats to use if needed)

/Muppion

Nope,
I've just hacked this together to make it work for me and just released it.
If those coding phoenix-miner see this at all they can take what the like and put it in the github.

I don't know about the 1.6.4 as I use 1.6.2 primarily. The problems seen in 1.6.2 with loosing contact with the pool is brute forced by this mod.

I use 1.6.2 because of the problems seen with 1.6.4 for time being. Those that don't have problem with 1.6.4 can also use this mod as it gives other benefits listed on first post.

/Muppion

Added a new version, -v10 for 1.6.2 and -v4 for 1.6.4.

This version introduces the -N <Network_Delay> option descibed above

/Muppion

Update:

Added new version (v7) which add a -t option to fine tune the block average output.

/Muppion

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://bitcointalk.org/index.php?topic=6458.0 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 <freq in sec>:

      Set the update frequency in seconds for status line. Not used when -n is active.

# -l --logtotext <log file name>:

      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 <Network Delay>:

      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 <times>:

      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

+2

Don't forget Puppylinux...
It also boot in Gui, sadly it only have restricted locale, but it's very nice, atleast those times I've tested it.

Post #5... Yay... Only Wait remains...

Strangly, I do see the effect of the rules here, or it's not that strange to see them, just watch...
But the effect is quite ... intresting
It's suppose to be tideus to wait, so spam et al don't want to join and hack,
yet some (as I did initially) don't get the thing about this rules .... Way to go I Say

Post #4

Well, It's what it's all about, is'nt it ;P
We all want freedom, and don't pay for it ....
It should annoy regulators instead ...

Post #3

Hi,

I've been tinkering with the Phoenix Miner 1.6.2 on Linux for a while. Workes great by the way.
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, 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 )

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/

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)

Cheers,

/Muppion

Hi, I've tried to understand this thing called bitcoin. Hopefully I will, eventually, but in the meantime why not hang out here...