Phoenix - Efficient, fast, modular miner

[Inaba]

I seem to be running into a strange problem with the latest build.  It seems to be dong the idle thing, but instead of locking up, just not processing anything - there's no error generated or any apparent problems communicating with RPC (at least it's not reporting it), but its acting like it and bringing the hash rate down.

Can you post the log? Unless you get "Work queue empty, miner is idle" you probably have a different issue. That message is logged by WorkQueue so it's independent of any protocol changes. Basically it means the kernel requested work and there is nothing in the queue to give it. If this doesn't appear it means that either the queue isn't empty or the kernel is not requesting work. (this could be caused by a driver error, hardware issues, ect)

How do I do that, or do you mean just what's on the screen?  I stopped using Phoenix again because it locked up like the previous version(s) and did not recover.  Didn't look like there was much change for me on rev 99.  I can try to help you out if you tell me what you need specifically, but it's costing me $$ everytime I have 6 GH idle for hours

[1714216458]

1714216458

[1714216458]

1714216458

[jedi95]

I seem to be running into a strange problem with the latest build.  It seems to be dong the idle thing, but instead of locking up, just not processing anything - there's no error generated or any apparent problems communicating with RPC (at least it's not reporting it), but its acting like it and bringing the hash rate down.

Can you post the log? Unless you get "Work queue empty, miner is idle" you probably have a different issue. That message is logged by WorkQueue so it's independent of any protocol changes. Basically it means the kernel requested work and there is nothing in the queue to give it. If this doesn't appear it means that either the queue isn't empty or the kernel is not requesting work. (this could be caused by a driver error, hardware issues, ect)

How do I do that, or do you mean just what's on the screen?  I stopped using Phoenix again because it locked up like the previous version(s) and did not recover.  Didn't look like there was much change for me on rev 99.  I can try to help you out if you tell me what you need specifically, but it's costing me $$ everytime I have 6 GH idle for hours

I just mean the output in the console window. Do you get the message "Work queue empty, miner is idle" or not? If you don't get this you have a completely different problem.

[bitclown]

However, as explained above I can't reproduce the problem myself so I need users to test this fix. You can either download the binaries below or checkout the latest SVN revision. (98 or 99 is fine)

Still had some hangs with r99, but BitcoinPool just had some hiccups, so I'm not entirely sure where fault is yet. I threw a few coins in your general direction for the effort, though.

I'm currently using a little script to ensure Phoenix is not slacking off. Maybe it's of interest to others until this gets resolved, wherever the bug is:

Code:

#!/usr/bin/python2.7
# Run Phoenix in a loop with 'while true; do ./phoenix yada-yada-yada; echo; done'
# and this script in a separate shell to kill the currently running Phoenix instance
# when GPU load goes below set threshold for set amount of time (default under 50%
# for 30 seconds). Intended for use with one ATI GPU and one Phoenix instance.

import re
import signal
from subprocess import check_output
from os import kill
from time import sleep, strftime, localtime

interval = 1
numsamples = 30
threshold = 50
samples = []

loadreg = re.compile('GPU load :\s+(\d+)')
pidreg = re.compile('(\d+) .* phoenix.py')

while (True):
    res = check_output(['aticonfig', '--odgc'])
    samples.append(int(loadreg.findall(res)[0]))

    if (len(samples) > numsamples):
        del samples[0]

        if (max(samples) < threshold):
            res = check_output(['ps', '-a'])
            for pid in pidreg.findall(res):
                print '%s Max GPU load is below %d%%, killing %s' % (strftime('%Y-%m-%d %H:%M:%S', localtime()), threshold, pid)
                kill(int(pid), signal.SIGINT)
            samples = []

    sleep(interval)

[dadittox]

It also explains my inability to reproduce the problem because I am running on a very stable wired connection.
However, as explained above I can't reproduce the problem myself so I need users to test this fix.

jedi95, just in case you're on linux. You may want to simulate bad connection for test purposes http://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux

[jedi95]

It also explains my inability to reproduce the problem because I am running on a very stable wired connection.
However, as explained above I can't reproduce the problem myself so I need users to test this fix.

jedi95, just in case you're on linux. You may want to simulate bad connection for test purposes http://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux

My main system runs Windows 7, because I play a lot of games. The only system I have running Linux at the moment is my mining box, but that has no monitor/keyboard and the only means of managing it is SSH.

I'll try this out sometime tomorrow, since it it's somewhat annoying to modify code on the server. (can't just edit -> save -> run, have to upload it over SFTP)

I have already tired simulating server downtime, but in the case of this issue (as I understand it) the connection isn't "busy" it's lost. I tried this already be blocking the IP in my router firewall. (so it just times out, as if the server were down) The miner was able to reconnect every time, and I tested it with 3 different pools, (deepbit, slush, bitcoinpool) MultiMiner, (using RPC) and a bitcoind instance running on a remote machine.

However simply delaying packets by some amount should make this easy to reproduce.

[dadittox]

My main system runs Windows 7, because I play a lot of games. The only system I have running Linux at the moment is my mining box, but that has no monitor/keyboard and the only means of managing it is SSH.

You can try http://www.virtualbox.org/wiki/Downloads to run linux in your Windows 7 Not sure how tc will work on virtual adapter though, but I think it should.

[marcus_of_augustus]

Anybody seen a good link for ATI 11.4 driver for linux?

This one on AMD page is empty ... sigh.

http://support.amd.com/us/gpudownload/windows/previous/11/Pages/radeon_linux.aspx?os=Linux%20x86&rev=11.4

every other version has a link at present.

[jedi95]

My main system runs Windows 7, because I play a lot of games. The only system I have running Linux at the moment is my mining box, but that has no monitor/keyboard and the only means of managing it is SSH.

You can try http://www.virtualbox.org/wiki/Downloads to run linux in your Windows 7 Not sure how tc will work on virtual adapter though, but I think it should.

That's practically useless since I won't be able to mine fast enough to cause the issue without using a GPU. (remember that you don't get direct access to GPUs in a VM)

At best I can get about 20 Mhash/sec from this CPU, which will need more work and find a share about once every 3.5 mins.

[jkminkov]

i have a 2 6950 (FLASHED to 6970) in crossfire i cant pass the limit of 355 Mhash/s using this command line for each device
[ start /dC:\phoenix phoenix -v -u http://mi******@gmail.com_0:*****@www.deepbit.net:8332 -k phatk device=0 WORKSIZE=128 VECTORS BFI_INT AGGRESSION=12 ]

i was hoping with this crossfire get closer to 375 Mhash/ per gpu.

thanks in advance

phatk gives more only on ATI 5xxx GPUs, use phoenix with aggression=11 and fastloop for 6xxx

[phelix]

I *THINK* I finally figured out the idling problem and why I can't reproduce it. The current behavior is to use persistent (keep-alive) connections to the server. If the connection is busy when another request is sent, a new connection is made. However, this is limited to 2 connections. If there is an attempt to create another connection when 2 already exist then it will block until one of the other connections is closed. This never happens though, so it blocks forever with no error messages.

This explains why jondecker76 was getting the issue VERY quickly on the slow wireless adapter, because with a slow internet connection there is a much higher chance of the connection being busy when a new request needs to be sent.

It also explains my inability to reproduce the problem because I am running on a very stable wired connection.

In any case, I have temporarily removed the connection limit in order to confirm that this is indeed the cause of the problem. If this fixes the issue, then I will do a more permanent fix later.

However, as explained above I can't reproduce the problem myself so I need users to test this fix. You can either download the binaries below or checkout the latest SVN revision. (98 or 99 is fine)

[...]

sounds exactly like the problem I had. seems like 1.48 fixed it, no freezing today.

[error]

So is that why the miner suddenly stopped for several minutes? I killed and restarted it and it picked up again just fine, so if there was a network issue, it was quite transient.

Code:

[20/05/2011 12:52:55] Result: 37f7090e accepted             
[20/05/2011 12:53:13] Result: 58e28a54 accepted             
[20/05/2011 12:53:36] Warning: work queue empty, miner is idle
[20/05/2011 12:54:01] Result: a80149d0 rejected        
[0 Khash/sec] [2154 Accepted] [32 Rejected] [RPC (+LP)]^C
error@underground ~/phoenix-1.48 $ sh miner.sh
[20/05/2011 13:05:44] Phoenix 1.48 starting...
[20/05/2011 13:05:45] Connected to server
[20/05/2011 13:06:07] Result: cdfe6534 accepted  

[check]

I'm having frequent lock up problems with 1.47 on Win7 using Bitcoinpool and running on a BIOS flashed 6950.    I don't recall having these problems with some of the very early versions.  Here's the sort of messages I see when it goes off:

phoenix -u http://user:pass@bitcoinpool.com:8334/ -v -q 2 -k poclbm DEVICE=0 AGGRESSION=10 BFI_INT PLATFORM=1 WORKSIZE=128

[20/05/2011 02:00:45] New block (WorkQueue)
[20/05/2011 02:00:57] Warning: work queue empty, miner is idle
[20/05/2011 02:12:10] LP: New work pushed
[20/05/2011 02:12:10] Server gave new work; passing to WorkQueue
[20/05/2011 02:12:10] New block (WorkQueue)
....
[20/05/2011 10:17:40] Warning: work queue empty, miner is idle
[20/05/2011 10:18:03] LP: New work pushed
[20/05/2011 10:18:03] Server gave new work; passing to WorkQueue
[20/05/2011 10:18:03] New block (WorkQueue)
[20/05/2011 10:18:15] Warning: work queue empty, miner is idle
[20/05/2011 10:20:59] LP: New work pushed
[20/05/2011 10:20:59] Server gave new work; passing to WorkQueue
[20/05/2011 10:20:59] New block (WorkQueue)
[20/05/2011 10:21:12] Warning: work queue empty, miner is idle
[0 Khash/sec] [1506 Accepted] [96 Rejected] [RPC (+LP)]

This usually happens within 8-12 hours.  Closing the terminal window and restarting always seems to work, so it doesn't seem to be a pool problem. If there is a deeper level of debugging I can turn on, or something else I can do to help diagnose, I'm happy to try.  I'll also try the most current version and see if that helps.

Thanks for your effort and generosity in producing this!

[allinvain]

1.48 is out..try that...

[BOARBEAR]

acutally the idle miner problem is getting worse,im switching back to poclbm while its getting fixed
on high aggression the miner idles for about 1-2 seconds every 10-20 seconds

[nster]

acutally the idle miner problem is getting worse,im switching back to poclbm while its getting fixed
on high aggression the miner idles for about 1-2 seconds every 10-20 seconds

i had that problem with poclbm at some point, but it was due to my crossfire

[jedi95]

A temporary fix for anyone not using the compiled binaries is to just use the minerutil folder from 1.4. This doesn't support persistent connections, so it won't work correctly on Slush's pool, but it should work fine everywhere else.

Thanks to everyone who tested the 1.48 debug build, it appears the problem is elsewhere.

You can find the 1.4 release files here:
http://svn3.xp-dev.com/svn/phoenix-miner/tags/release-1.4/

[OVerLoRDI]

I'm getting very strange performance with both kernels.

My command line is:
phoenix.exe -u http://loginsauce@sauce.net:8332 -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false AGRESSION=12 WORKSIZE=128

and I'm getting exactly, with no variation, 67.28 Mhash/s on a 5870 at 975Mhz.  This is true for both kernels.  changing WORKSIZE and AGRESSION has no effect.

GPU usage is reported at roughly 60% according to GPU-Z.

standard poclbm gives me ~405 Mhash/s...

Am I doing something wrong?

I'm running SDK 2.4 on Windows 7 32bit.

[Bitcoineruk]

Hi Guys,

Is there any actual way to see if mining solo is working? - I have run bitcoin as a server and pointed my Phoenix miner at it

start /DC:\phoenix phoenix.exe -u http://user@live.co.uk:pass@127.0.0.1:8332 -k poclbm DEVICE=0 VECTORS BFI_INT FASTLOOP AGGRESSION=12 WORKSIZE=128
start /DC:\phoenix phoenix.exe -u http://user@live.co.uk:pass@127.0.0.1:8332 -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=12 WORKSIZE=128

Like the above, but always says 0 accepted, but it is showing a mh/s value and says connected to server in the DOS box?

I dont expect to find my 50BTC very soon, however, I dont want to be running my GPUs full whack for no reason.

Please help

Thanks

[SoreGums]

I'll try this out sometime tomorrow, since it it's somewhat annoying to modify code on the server. (can't just edit -> save -> run, have to upload it over SFTP)

My main is win7 and all servers are gentoo, I use WinSCP to edit files easily.
It handles: copy file locally, open in e-text editor, when file modified upload to server again, when file closes in e remove from temp dir
As such it is very much edit > save > run - of course if your server is local then maybe setup samba.

I'm using Phoenix now (started mining 4days ago using Diablo) as i can control which GPU is being used and play games/watch videos.
tiny donation sent, cheers

[bitclown]

Thanks to everyone who tested the 1.48 debug build, it appears the problem is elsewhere.

Indeed. My Phoenix instance have now been chugging along flawlessly for over 24 hours. Most splendid!