Topic: Phoenix - Efficient, fast, modular miner - page 32. (Read 760839 times)

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

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://[email protected]:[email protected]:8332 -k poclbm DEVICE=0 VECTORS BFI_INT FASTLOOP AGGRESSION=12 WORKSIZE=128
start /DC:\phoenix phoenix.exe -u http://[email protected]:[email protected]: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

I'm getting very strange performance with both kernels.

My command line is:
phoenix.exe -u http://[email protected]: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.

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/

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

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

1.48 is out..try that...

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:[email protected]: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!

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.

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

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

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.

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.

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.

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.

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

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:

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.

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