Bitcoin Forum
December 04, 2016, 12:38:26 PM *
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 734649 times)
CubedRoot
Sr. Member
****
Offline Offline

Activity: 295


View Profile
June 09, 2011, 01:37:18 AM
 #661

I am using phoenix and phatk kernel, and when I get a LP push of new work, it freezes my GPU completely.  Is there an easy solution to this?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
super6
Newbie
*
Offline Offline

Activity: 28


View Profile
June 09, 2011, 02:26:28 AM
 #662

Phoenix only identifies one of my xfire'd 6990's, in fact it might even only be identifying half of it because it lists devices as 1 instead of 2 (or 4, if it counts GPU's instead of cards). There are 2 cards there, though, and MSI afterburner sees them as does GUIMinter (poclbm). Any idea what causes this?
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 09, 2011, 03:46:25 AM
 #663

Your stale rates below are atrocious at over 3%!

My hashrate is waaaayy too low for my cards. I need some help getting them to work like they should!

Here's my hashrates


Here's my GPU Load


I have 2 machines running 2 HD6990 each with driver 11.5 and SDK 2.4 in Ubuntu 11.04

I run ./phoenix.py -u http://user.worker@pool.com:port/ -k poclbm DEVICE=0 VECTORS AGGRESSION=11 FASTLOOP=false BFI_INT

I've tried different AGGRESSION values, tried with and without FASTLOOP and VECTORS and BFI_INT but it doesn't seem to get any better than this. Agression 13 makes the machines feel slow. Haven't tried higher.

CPU load is 100% when mining.
GPU Temperatures are around 80-90 degrees.

I should be able to get 350-375 MHash/sec per worker, right? What should I do to get this?

I don't think you need the FASTLOOP=false there.  Also, I think you can push to AGGRESSION=12.  I run my 6970 (one core of yours) @ 920MHz core clock and left the memory clock at the default 1375MHz ONLY because it is my workstation that I use for work and play even when mining on Windows 7 x64 Professional.  Honestly, Phoenix 1.48 tends to cause too many stale shares compared to poclbm.py [since you will run via python directly].  With my 5850 cards, I use Phoenix 1.48 because the phatk kernel gives me more than a 3% boost and the lost of up to 1% additional to stale shares is acceptable.  I typically see 0.3% - 0.5% with poclbm against deepbit.net and now tonight, the same with BTC Guild.  Phoenix on the other hand, to the same pools, I average perhaps 1.2%-1.3% stale shares.  I sometimes see even worse stale share issues with Phoenix when used with my 6970, so I simply use poclbm.  

Phoenix phatk kernel only seems to help with the 58xx series [and maybe older], but actually is worse with the 69xx series in my experience [well, the 6970 anyway which means it will be the same for your 6990].

I would recommend trying poclbm with the following and maybe adjust your -f  value down a little every now and then to find the best performance with solid stability; many people run with -f 1 and have no issues.

via the python compiler/interpreter:

Quote
python poclbm.py -d1 --host=btcguild.com --port=8332 --user=xxx_xxxx -pass=xxxxx -v -w 128 -f 10

In spite of what other people have said, I have only seen a small but significant decline in performance by using the default worksize [remove the -w switch and it will use 256 or just -w 256], so I set it to 128.  My desktop runs with -f 30 and I see 393MH/s and my card runs at 73C-76C depending on the ambient temps and humidity (I NEVER let the temp go above 80C ... your decision how hot you are willing to run it for the long haul).  I get he same rates with phoenix, but the stale shares is a deal breaker for me on the 6970.  I should point out that I get 393MH/s with my 6970 at these settings [Aero running and two monitors on Windows 7].  Default for the 6970 is 880MHz core and 1375MHz clock and clearly the reduced that for the 6990.

I am not sure that you can clock the same rates on the 6990 [per core] as the 6970 due to the proximity of the GPUs on the board [they tend to reduce clock and/or voltage a little on the dual GPU cards (5970 and 6990 obviously).  The 6970 is one hot card at full GPU usage (meaning you need to keep it cool and it is more difficult than other cards).  Still, I believe my 920MHz core clock speed is probably quite conservative but that is because I can't really afford to risk the card on this workstation ... well, I guess I can if I am willing to throw my old MSI 570GTX OC back in which I loved but was a terrible mining card; I don't have another backup card for mining [or I would probably get it in a rig and mine with it now].

So, depending no the quality of your pool and the connection too it, you should get a solid 1% increase in performance by switching miners to poclbm.  Look at overclocking the core clock some [little at a time, and do some checking on what works for others, but don't start at their rates ... each card is different given its own micro environment and may not behave well at the clock speeds that you find, but I am sure you should be able to gain some improvement; at least 10%.  Reducing memory clock speed helps to reduce the heat as well, since mining doesn't require much from memory.  I have read the rule of thumb is 35-40% of the core clock speed, but trying that on my 5850s has not proven to work for me and I have not tried it on my 6970 due to me using it as a work station (VPN, remote desktop, email, lots of services yada yada).  BTW, I have found performance on Linux to be disappointing, but I think others can probably help you with that assuming there is a way to make the Linux drivers push the card as it does with Windows.

Experiment for a few days and baby sit it a bit when you start tinkering with the clock settings [each card may perform best with different timings] and check on stale/reject rates .. sometimes they are rejected as invalid which may mean your card is making mistakes if you push it too hard.  I spent 9 hours with my first 5850 when I first set it up for mining as I slowly tweaked the clock speeds.  Good thing too, since every now and again, it would just halt, but you couldn't necessarily tell by the fans [I could see if I was watching miner contributions at the pool website].

I hope I was of help.  Please report back on what you come up with.

If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 09, 2011, 03:57:57 AM
 #664

Sorry if I suggested poclbm miner in the Phoenix thread, I wasn't paying particular attention to which thread I was in.  Having said that, I do suggest it for 58xx cards with the phatk kernel since the performance offsets the stale share issue [when will this be fixed as I prefer phoenix over poclbm as a miner other than the stale share issue?].

If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
June 09, 2011, 04:12:25 AM
 #665

Hey, I think I figured out why some people are reporting high CPU usage at times.  I just came to realize that some CPUs have OpenCL functionality built-in to them.  In particular, the later Core2 series processors and on.  So it's highly possible that your CPU's OpenCL capability is causing it to be used for hashing as much as your GPU.  Just throwing it out there.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
gigabytecoin
Sr. Member
****
Offline Offline

Activity: 280


View Profile
June 09, 2011, 04:33:26 AM
 #666

Is there any significant performance difference between running Phoenix on Windows or Linux? I'm building a dedicated mining rig and I'd like to know if there's a particular advantage to one or the other operating system.

No, there shouldn't be.
gentakin
Member
**
Offline Offline

Activity: 98


View Profile
June 09, 2011, 01:25:46 PM
 #667

So I'd like to now if anyone else has LP problems with phoenix. I posted about it earlier, but so far I still couldn't solve the problem, so here I am again.

LP works okay right after starting phoenix. But then, after some time (it can be 5 hours or 40 minutes..) LP no longer works. I added debug outputs into the LongPoller class and figured out that the call to (twisted web) agent.request() is executed properly, as my debug output *after* this code snippet is printed correctly before LP dies:
Code:
            d = self.agent.request('GET', self.url,
                Headers({
                    'Authorization': [self.root.auth],
                    'User-Agent': [self.root.version]
                }))
            d.addBoth(self._requestComplete)

I also added debug output to _requestComplete, which is never printed after LP dies, so the last thing I see from LP is a log message about agent.request() having been called.

It seems like this happens most often when there is a long time between two found blocks, so it's like the twisted web agent times out and thus the callback is never called. However I couldn't find a maximum time that still works without breaking LP, as it has died with only 15 minutes between two blocks as well, but sometimes also manages to wait for 30 minutes for the next LP.

I've tried setting persistent=False for the agent constructor and also recreating a new agent every time a LP-request starts. It feels like this has improved the situation somewhat, but it's still happening.

I'm using Ubuntu 11.04 and phoenix r100. Smiley

1HNjbHnpu7S3UUNMF6J9yWTD597LgtUCxb
keybaud
Member
**
Offline Offline

Activity: 112


View Profile
June 09, 2011, 04:31:11 PM
 #668

PHOENIX MEMORY LEAK?

In an effort to reduce the amount of heat my PC generates, I set my copy of Windows XP to not use any Virtual Memory so it wouldn't access the hard drive as much. I have 1 GB of memory fitted to the PC and when I run 6 Phoenix clients I am using 740MB. If I leave the PC for an extended period, over 24 hours, Phoenix will start generating errors and I get an 'Out of Virtual Memory' message from Windows. I'll try and copy the error message next time, but I'd already rebooted the PC when I started to write this.

The implication here is that Phoenix has a memory leak of some kind, as there is no reason the the extra 260 MB of RAM needs to be used.
kcobra
Member
**
Offline Offline

Activity: 86


View Profile
June 09, 2011, 04:47:06 PM
 #669

When mining on a pool that supports LP, such as deepbit, do I have to pass any parameter to phoenix or the phatk kernel to enable long polling?

I'm trying to get my stale shares down. I see people saying they get less than 1% stales. I am no-where near that. On deepbit I get anywhere from 2% - 3% stale shares. On slush's pool it is sometimes even a bit higher. Of course slush's pool does not support long polling.

Any tips on getting the stale rate down? I am running 5830's oc'ed to 975mhz core, 300mhz memory. They seem stable. They run anywhere from 60c to 80c depending on the box they are in.

Thanks.
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 09, 2011, 04:57:58 PM
 #670

When mining on a pool that supports LP, such as deepbit, do I have to pass any parameter to phoenix or the phatk kernel to enable long polling?

I'm trying to get my stale shares down. I see people saying they get less than 1% stales. I am no-where near that. On deepbit I get anywhere from 2% - 3% stale shares. On slush's pool it is sometimes even a bit higher. Of course slush's pool does not support long polling.

Any tips on getting the stale rate down? I am running 5830's oc'ed to 975mhz core, 300mhz memory. They seem stable. They run anywhere from 60c to 80c depending on the box they are in.

Thanks.

No.  But use the phatk kernel so that you should get an approximately 3+% increase which will make up for the increase in stales caused by a defect in phoenix that remains unfixed.  Otherwise, use poclbm.exe to mine.

If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
keybaud
Member
**
Offline Offline

Activity: 112


View Profile
June 09, 2011, 09:13:39 PM
 #671

PHOENIX MEMORY LEAK?

In an effort to reduce the amount of heat my PC generates, I set my copy of Windows XP to not use any Virtual Memory so it wouldn't access the hard drive as much. I have 1 GB of memory fitted to the PC and when I run 6 Phoenix clients I am using 740MB. If I leave the PC for an extended period, over 24 hours, Phoenix will start generating errors and I get an 'Out of Virtual Memory' message from Windows. I'll try and copy the error message next time, but I'd already rebooted the PC when I started to write this.

The implication here is that Phoenix has a memory leak of some kind, as there is no reason the the extra 260 MB of RAM needs to be used.

I've done some poking and the problem would appear to be how Windows XP stores the details in the command prompt window. As the miner is creating a new line every few seconds and Windows remembers everything in the command prompt window, the memory required to do this will grow until you eventually get an out of memory error when the virtual memory limit is reached. Because I'd disabled virtual memory, I was reaching the limit much earlier than usual. This will also be why the hard drive was being used far more than I expected it to, as it never went into shutdown when mining with virtual memory enabled.

I don't know if this problem occurs on other versions of Windows, as I'm only using XP.
kcobra
Member
**
Offline Offline

Activity: 86


View Profile
June 09, 2011, 09:25:11 PM
 #672

When mining on a pool that supports LP, such as deepbit, do I have to pass any parameter to phoenix or the phatk kernel to enable long polling?

I'm trying to get my stale shares down. I see people saying they get less than 1% stales. I am no-where near that. On deepbit I get anywhere from 2% - 3% stale shares. On slush's pool it is sometimes even a bit higher. Of course slush's pool does not support long polling.

Any tips on getting the stale rate down? I am running 5830's oc'ed to 975mhz core, 300mhz memory. They seem stable. They run anywhere from 60c to 80c depending on the box they are in.

Thanks.

No.  But use the phatk kernel so that you should get an approximately 3+% increase which will make up for the increase in stales caused by a defect in phoenix that remains unfixed.  Otherwise, use poclbm.exe to mine.

Ahh, ok. I am running the phatk kernel with phoenix. I get ~300mh/s on each card. If it is a bug in phoenix causing the high stale rate is there some other wrapper that will run the phatk kernel. Sorry if this is a dumb question.
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 09, 2011, 09:35:14 PM
 #673

When mining on a pool that supports LP, such as deepbit, do I have to pass any parameter to phoenix or the phatk kernel to enable long polling?

I'm trying to get my stale shares down. I see people saying they get less than 1% stales. I am no-where near that. On deepbit I get anywhere from 2% - 3% stale shares. On slush's pool it is sometimes even a bit higher. Of course slush's pool does not support long polling.

Any tips on getting the stale rate down? I am running 5830's oc'ed to 975mhz core, 300mhz memory. They seem stable. They run anywhere from 60c to 80c depending on the box they are in.

Thanks.

No.  But use the phatk kernel so that you should get an approximately 3+% increase which will make up for the increase in stales caused by a defect in phoenix that remains unfixed.  Otherwise, use poclbm.exe to mine.

Ahh, ok. I am running the phatk kernel with phoenix. I get ~300mh/s on each card. If it is a bug in phoenix causing the high stale rate is there some other wrapper that will run the phatk kernel. Sorry if this is a dumb question.

I have found that phoenix with the poclbm kernel and poclbm miner perform equally as well as far as hash rates go if configured correctly.  However, phoenix with the phatk kernel gets a little more than a 3% boost on my 5850s.  The stale rate defect in phoenix seems to cost me slightly more than 1% so you can see that is is not worth moving back to poclbm.  Once phoenix fixes this defect [if they do, development seems to have gone dark lately ... probably be a new version soon], it will be premier.  Oh yes, one other issue with phoenix, it has a lot more trouble with reconnects [Comcast is doing schedule infrastructure upgrades in my neighborhood (whoa!  was first in the country on DOCSIS 3.0 and now what are they adding? Smiley) and they cut my connection this morning for about two minutes or so, when it came back up one of my two phoenix miners simply looked like it was mining at a glance, but it was showing 0MH/s, but it was responding fine to Ctrl-C to exit.  The other stayed up fine and poclbm.exe on my 6970 picked up as soon as it detected a connection [in fact, that is how I knew service was back up].

If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
AngstHase
Jr. Member
*
Offline Offline

Activity: 31


View Profile
June 10, 2011, 12:53:30 AM
 #674

Have some problems with internet reconnects and phoenix too. Falling down to 0 Mh/s sucks for dedicated miner Grin

MintCondition
Sr. Member
****
Offline Offline

Activity: 322



View Profile
June 10, 2011, 03:56:38 AM
 #675


As for askrate, it's not necessary with Phoenix because it maintains a work queue and only requests work when needed. Phoenix also ignores the askrate setting automatically for RPC servers with long polling support.

I've been playing around with Pushpool (software to run a mining pool) in combination with Phoenix, and found that the default Phoenix settings may cause some unnecessary rejected shares for slow miners on a Pushpool server that offers Long Polling. Since several Pushpool-based mining pools have recently come into existence this probably affects some users already.

The problem: By default, Phoenix miners using RPC+LP are configured to request work only when current work has been completely exhausted. For slow miners (<36MH/s) this will take longer than 120 seconds. Pushpool does not accept shares for work that was issued more than approximately 120 seconds ago (or in more detail: shares must match some previously issued work, and work older than 120 seconds is expired/forgotten regularly). This means that Phoenix workers that produce <36MH/s will work part of their time trying to produce shares that will (almost certainly) be rejected by the pool!

The immediate solution is to use Phoenix's undocumented lpaskrate command line parameter, which is the Long Poll equivalent of the askrate parameter. A more structural fix would be for the Phoenix client to change lpaskrate default value from 0 to something sensible in the range 10-119. Of course the expiry policy may also be changed by the pool operator. But the default Pushpool work expiry policy is not overly strict in my opinion; work that's over 2 minutes old misses out on a lot of recent transactions and therefore on the transaction fees these include.


If you want to tweak the askrate, (since the default is to ask only when the miner needs more work) you can use something like this:
phoenix -u http://USERNAME.WORKERNAME:PASSWORD@mining.bitcoin.cz:8332/;askrate=10 -k poclbm DEVICE=0 VECTORS AGGRESSION=3

This should only be used on pools that don't support RPC LP or MMP.


derbe
Newbie
*
Offline Offline

Activity: 2


View Profile
June 10, 2011, 09:39:31 AM
 #676

Hey guys,


i got a big problem with my 5850 Cards, i installed a fresh win7 64x system with 2x of ATI 5850 card.
Ok, i download the lastest driver catalyst driver for ati und SDK. Than the system installed this cards correct.
Up to here everything is fine.

Now i start Phoenix and it says that i only have one card (id = 0 ->GPU , and id = 1 ->CPU)
it says that at starting the programm in dos windows, before processing.

But where is my 2nd GPU? (It is full installed and also shown in msi afterbruner e.g.).
Or do i have to use a crossfireX hardware brigde? (I do not have any installed, and iam not able to active this feature at the drivers)?!

Sorry for my bad english Smiley  It is not my mother speech.
maxcorrads
Jr. Member
*
Offline Offline

Activity: 43


View Profile
June 10, 2011, 09:49:29 AM
 #677

Hey guys,


i got a big problem with my 5850 Cards, i installed a fresh win7 64x system with 2x of ATI 5850 card.
Ok, i download the lastest driver catalyst driver for ati und SDK. Than the system installed this cards correct.
Up to here everything is fine.

Now i start Phoenix and it says that i only have one card (id = 0 ->GPU , and id = 1 ->CPU)
it says that at starting the programm in dos windows, before processing.

But where is my 2nd GPU? (It is full installed and also shown in msi afterbruner e.g.).
Or do i have to use a crossfireX hardware brigde? (I do not have any installed, and iam not able to active this feature at the drivers)?!

Sorry for my bad english Smiley  It is not my mother speech.

You need to connect a monitor on the second card, or a dummy plug
derbe
Newbie
*
Offline Offline

Activity: 2


View Profile
June 10, 2011, 09:56:42 AM
 #678

Hey guys,


i got a big problem with my 5850 Cards, i installed a fresh win7 64x system with 2x of ATI 5850 card.
Ok, i download the lastest driver catalyst driver for ati und SDK. Than the system installed this cards correct.
Up to here everything is fine.

Now i start Phoenix and it says that i only have one card (id = 0 ->GPU , and id = 1 ->CPU)
it says that at starting the programm in dos windows, before processing.

But where is my 2nd GPU? (It is full installed and also shown in msi afterbruner e.g.).
Or do i have to use a crossfireX hardware brigde? (I do not have any installed, and iam not able to active this feature at the drivers)?!

Sorry for my bad english Smiley  It is not my mother speech.

You need to connect a monitor on the second card, or a dummy plug


Dam, ok now i know why i used nvida all of my life Cheesy Cheesy Cheesy
Ok i found some nice:
http://www.overclock.net/folding-home-guides-tutorials/384733-30-second-dummy-plug.html

THX for respone Wink
mosie
Newbie
*
Offline Offline

Activity: 15


View Profile
June 10, 2011, 10:08:18 AM
 #679

hi all.
 
I have litle problem:

in 1st my conf: http://forum.overclocking-tv.com/index.php?topic=351.0

in GC I have 2X HD 6990 and one first detect 9800GTX.


-k poclbm DEVICE="X" VECTORS AGGRESSION=12  BFI_INT

faild in launch.

whene I try spécifi device = fail


thanks.
keybaud
Member
**
Offline Offline

Activity: 112


View Profile
June 10, 2011, 12:54:20 PM
 #680

Hey guys,


i got a big problem with my 5850 Cards, i installed a fresh win7 64x system with 2x of ATI 5850 card.
Ok, i download the lastest driver catalyst driver for ati und SDK. Than the system installed this cards correct.
Up to here everything is fine.

Now i start Phoenix and it says that i only have one card (id = 0 ->GPU , and id = 1 ->CPU)
it says that at starting the programm in dos windows, before processing.

But where is my 2nd GPU? (It is full installed and also shown in msi afterbruner e.g.).
Or do i have to use a crossfireX hardware brigde? (I do not have any installed, and iam not able to active this feature at the drivers)?!

Sorry for my bad english Smiley  It is not my mother speech.

You need to connect a monitor on the second card, or a dummy plug


Dam, ok now i know why i used nvida all of my life Cheesy Cheesy Cheesy
Ok i found some nice:
http://www.overclock.net/folding-home-guides-tutorials/384733-30-second-dummy-plug.html

THX for respone Wink

Nothing to do with ATI or NVidia, it's a Windows limitation.
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!