Bitcoin Forum
December 11, 2016, 02:38:08 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 »
  Print  
Author Topic: Phoenix - Efficient, fast, modular miner  (Read 735301 times)
charbo
Newbie
*
Offline Offline

Activity: 7


View Profile
May 20, 2011, 02:06:59 AM
 #501

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
1481423888
Hero Member
*
Offline Offline

Posts: 1481423888

View Profile Personal Message (Offline)

Ignore
1481423888
Reply with quote  #2

1481423888
Report to moderator
1481423888
Hero Member
*
Offline Offline

Posts: 1481423888

View Profile Personal Message (Offline)

Ignore
1481423888
Reply with quote  #2

1481423888
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
May 20, 2011, 06:27:20 AM
 #502

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 Smiley

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
jedi95
Full Member
***
Offline Offline

Activity: 219


View Profile
May 20, 2011, 07:47:38 AM
 #503

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 Smiley


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.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
bitclown
Full Member
***
Offline Offline

Activity: 186


View Profile
May 20, 2011, 08:17:10 AM
 #504

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
Newbie
*
Offline Offline

Activity: 22


View Profile
May 20, 2011, 08:58:21 AM
 #505

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
Full Member
***
Offline Offline

Activity: 219


View Profile
May 20, 2011, 09:29:39 AM
 #506

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.


Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
dadittox
Newbie
*
Offline Offline

Activity: 22


View Profile
May 20, 2011, 10:04:25 AM
 #507

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 Smiley Not sure how tc will work on virtual adapter though, but I think it should.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 20, 2011, 10:12:41 AM
 #508


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
Full Member
***
Offline Offline

Activity: 219


View Profile
May 20, 2011, 10:35:40 AM
 #509

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

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
jkminkov
Hero Member
*****
Offline Offline

Activity: 534


View Profile
May 20, 2011, 01:45:15 PM
 #510

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

Bleutrade
600 dollars in one place talking - Dudes, hooray, Bitcoin against us just one, but we are growing in numbers!
phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
May 20, 2011, 05:27:54 PM
 #511

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.

blockchained.com ■ bitcointalk top posts
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
May 20, 2011, 05:31:13 PM
 #512

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  

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
check
Newbie
*
Offline Offline

Activity: 3


View Profile
May 20, 2011, 05:38:34 PM
 #513

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
Legendary
*
Offline Offline

Activity: 2002



View Profile
May 20, 2011, 06:01:45 PM
 #514

1.48 is out..try that...

BOARBEAR
Member
**
Offline Offline

Activity: 77


View Profile
May 20, 2011, 09:47:16 PM
 #515

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
Full Member
***
Offline Offline

Activity: 126



View Profile
May 20, 2011, 10:33:35 PM
 #516

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

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
jedi95
Full Member
***
Offline Offline

Activity: 219


View Profile
May 21, 2011, 12:41:54 AM
 #517

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/

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
OVerLoRDI
Member
**
Offline Offline

Activity: 60


View Profile
May 21, 2011, 06:12:25 AM
 #518

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
Member
**
Offline Offline

Activity: 70



View Profile
May 21, 2011, 08:57:57 AM
 #519

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 Smiley

Thanks

Donate if I helped you : 15sE1b7Y6rLMBwwyBLGwSBTQzvB8csUfrX

https://bitclockers.com/userbar/505d459bffeee4a0f7d6ad0ec794c61a.png
SoreGums
Member
**
Offline Offline

Activity: 116



View Profile
May 21, 2011, 10:33:44 AM
 #520

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 Smiley
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!