Bitcoin Forum

Bitcoin => Mining software (miners) => Topic started by: jedi95 on April 25, 2011, 01:18:28 AM



Title: Phoenix - Efficient, fast, modular miner
Post by: jedi95 on April 25, 2011, 01:18:28 AM
Phoenix 1 is no longer in development, please use Phoenix 2:
https://bitcointalk.org/index.php?topic=75786

Features

Here's what it has to offer:
  • It's fast - Phoenix implements the BFI_INT instruction, which can improve performance by 5-20%
  • It's as efficient as theoretically possible (that is, it doesn't discard any work unless that work would be invalid)
  • It's free, open-source software - It's available under the X11 license, and written in (fairly) well-documented and commented Python.
  • It loads kernels dynamically - If someone releases a more efficient kernel for our miner, it's as simple as dropping in the new kernel and using it.
  • It has a simple command-line interface - Obviously "simple" is subjective, but it's pretty easy to get started using.
  • It supports RPC w/LP and MMP, and provides plenty of stats.
  • It supports automatic failover by specifying a backup server with -b
-

Example usage

To connect to a pool such as Slush's using our miner and Phateus's phatk2 kernel, you would use a command line such as:
phoenix -u http://USERNAME.WORKERNAME:PASSWORD@api2.bitcoin.cz:8332/ -k phatk2 DEVICE=0 VECTORS BFI_INT AGGRESSION=4
...where DEVICE=0 instructs it to use OpenCL device #0, VECTORS has it run 2-way vectors, BFI_INT enables the BFI_INT instruction in newer ATI GPUs, and AGGRESSION can be used to tweak execution size (similar to poclbm's -f)

If you want to tweak the askrate, (since the default is 10 without LP, or none with LP enabled servers) you can use something like this:
phoenix -u http://USERNAME.WORKERNAME:PASSWORD@api2.bitcoin.cz:8332/;askrate=5 -k phatk2 DEVICE=0 VECTORS BFI_INT AGGRESSION=4

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


Download

Latest version: 1.7.5
Windows binaries (https://github.com/downloads/jedi95/Phoenix-Miner/phoenix-1.7.5.zip)
Source code/Linux release (https://github.com/jedi95/Phoenix-Miner/tarball/master) (requires Python, Twisted, and PyOpenCL)

GitHub:
https://github.com/jedi95/Phoenix-Miner


Donations

1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU


Phoenix interface
The hashrate display is an average using the most recent 16 samples by default. (configure with -a) It also automatically scales the units depending on the rate.

Accepted and rejected share counts should be pretty self-explanatory.

The protocol type indicates the type of connection:
  • RPC - A standard RPC server, such as Slush's pool or bitcoind
  • RPC (+LP) - An RPC server supporting long polling, such as deepbit.net or bitcoinpool.com
  • MMP - An MMP server, such as Multiminer.

The block change notification only appears on RPC servers that implement the X-Blocknum header and MMP servers that send the BLOCK message.
NOTE: RPC servers with long poll have a different notification.


Command line options

Phoenix arguments

 -v (verbose) - Logs additional debug messages to the console. Default is disabled.
 -q (queue size) - Sets the size of the internal work queue. Default is 1. This shouldn't need to be changed for most GPU miners.
 -a (average samples) - Sets the number of samples to use for hashrate averaging. Default is 10. You might want to lower this for longer kernel execution times. (high aggression)
 -u (URL) - Sets the URL of the work server. The correct protocol is selected based on the prefix (RPC for http://, MMP for mmp://)
 -b (Backup URL) - Sets the URL of the backup work server. The backup server will be used if the primary server is down. Works exactly like -u.
 -k (kernel) - Selects which kernel to load. Default is poclbm. All other arguments MUST come before specifying a kernel. Any arguments after -k are sent to the kernel.

Poclbm/phatk/phatk2 kernel arguments

 PLATFORM=ID - Sets the OpenCL platform to use. This isn't needed if you only have a single platform.
 DEVICE=ID - Sets the OpenCL device to use. This isn't needed if you only have a single device.
 VECTORS - Enables 2-way vectors. This may improve hashrate if enabled, but it can be slower on some hardware. Default is disabled.
 AGGRESSION=LEVEL - Sets the aggression. This allows you to control the kernel execution time to improve hashrate or reduce interface lag. Default is 4 (poclbm), 5 (phatk/phatk2).
 WORKSIZE=SIZE - Sets the worksize. Tweaking this setting may improve performance similar to poclbm's -w flag. Default is the maximum supported by the device.
 FASTLOOP - Enables fast internal loop. This improves hashrate at lower aggression levels without introducing any additional interface lag. Default is enabled.
 BFI_INT - Enables the BFI_INT instruction on newer AMD/ATI GPUs. This significantly improves hashrate. Default is enabled on phatk/phatk2, disabled on poclbm.

NOTE 1: Using FASTLOOP at higher AGGRESSION won't improve performance. However, it no longer results in stale shares. To disable FASTLOOP use FASTLOOP=false.
NOTE 2: The phatk and phatk2 kernels don't work well Nvidia GPUs. Use poclbm kernel instead.


Recommended settings

High-end ATI cards (58xx, 5970, 68xx, 69xx)

Non-dedicated (use these settings if you use the computer while mining)
-k phatk2 VECTORS BFI_INT AGGRESSION=7

Dedicated miner
-k phatk2 VECTORS BFI_INT FASTLOOP=false AGGRESSION=11


Midrange and older ATI cards (48xx, 57xx, ect)

Non-dedicated (use these settings if you use the computer while mining)
-k phatk2 VECTORS BFI_INT AGGRESSION=5

Dedicated miner
-k phatk2 VECTORS BFI_INT FASTLOOP=false AGGRESSION=9

BFI_INT only supported on 5xxx and newer
NOTE: For optimal performance use either SDK 2.1 with poclbm or SDK 2.4 with phatk2. Using phatk/phatk2 on SDK versions other than 2.4 will likely reduce performance.

These settings are intended only as a starting point, and may not be optimal for your system configuration.


Links

Multiminer thread (http://bitcointalk.org/smf/index.php?topic=5210.0)
MMP protocol specifications (https://github.com/CFSworks/multiminer/raw/master/doc/mmp.pdf)
phatk/phatk2 kernel thread (http://bitcointalk.org/smf/index.php?topic=7964.0)
Diapolo's modified phatk kernel (https://bitcointalk.org/index.php?topic=25860.0)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: xenon481 on April 25, 2011, 01:36:47 AM
This runs far far slower than poclbm on my nvidia GTX 280.

poclbm = ~50MHash/sec
phoenix = ~32MHash/sec


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: jedi95 on April 25, 2011, 01:39:34 AM
This runs far far slower than poclbm on my nvidia GTX 280.

poclbm = ~50MHash/sec
phoenix = ~32MHash/sec

That's probably the result of our changes to the poclbm OpenCL kernel. The speed tests were run on an ATI 5870. Also, you may want to try with/without VECTORS to see if it helps.

What aggression and -f values were you using for each?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: kindle on April 25, 2011, 01:55:45 AM
Hi does this support solo mining?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: xenon481 on April 25, 2011, 01:57:59 AM
This runs far far slower than poclbm on my nvidia GTX 280.

poclbm = ~50MHash/sec
phoenix = ~32MHash/sec

That's probably the result of our changes to the poclbm OpenCL kernel. The speed tests were run on an ATI 5870. Also, you may want to try with/without VECTORS to see if it helps.

What aggression and -f values were you using for each?

nvidia GTX 280

poclbm
----------------------------
Vectors off / -f 60 = ~50MH/s desktop lag barely noticeable


phoenix
----------------------------
Vectors on / Aggression Default / FastLoop off = ~29.5MH/s
Vectors off / Aggression Default / FastLoop off = ~32MH/s
Vectors off / Aggression Default / FastLoop on = ~41MH/s
Vectors off / Aggression 3 / FastLoop on = ~46MH/s desktop lag barely noticeable
Vectors off / Aggression 4 / FastLoop on = ~47.5MH/s with noticeable desktop lag
Vectors off / Aggression 5 / FastLoop on = ~49.5MH/s but quite a bit of desktop lag
Vectors off / Aggression 7 / FastLoop off = ~50MH/s but extreme desktop lag
Vectors off / Aggression 7 / FastLoop on = ~51MH/s but extreme desktop lag


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: eleuthria on April 25, 2011, 02:01:49 AM
Comparable to poclbm.py in Linux with my 5870s (using the H.x, H.y, and H == 0 mod) when using aggression 12, compared to poclbm.py with -f1.

Are you using 1024 kHash = 1 mHash, or 1000?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: jedi95 on April 25, 2011, 02:04:23 AM
Comparable to poclbm.py in Linux with my 5870s (using the H.x, H.y, and H == 0 mod) when using aggression 12, compared to poclbm.py with -f1.

Are you using 1024 kHash = 1 mHash, or 1000?

1000, so the rates should be directly comparable.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: eleuthria on April 25, 2011, 02:05:12 AM
In that case it's slightly slower (~2 mHash/sec) using Aggression 12.  It's slightly faster than base poclbm, but slower than the modified poclbm with the H.x, H.y, and H==0 modification.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: shivansps on April 25, 2011, 02:08:24 AM

nevermind.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: mskwik on April 25, 2011, 02:27:25 AM
Code looks very nice, unfortunately I get the same issues as with poclbm using it.  Hashrate is roughly as expected, but CPU usage is pegged at 100% on one core while it is running.  Guess I'll be sticking with Diablominer which also gives roughly the same rate without the CPU usage.

This is a 5770 running on Gentoo, hashrate is in the ~165-170M range depending on exact settings.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: dbitcoin on April 25, 2011, 02:28:15 AM
Long polling support not functional.
You use old and stupid restriction: LP path with same domain and port.
There is no strict description in LP first draft specification about this.
But this is already discussed and implemented in miners.

http://domain.com:port/path/ (http://domain.com:port/path/)

Full URL Supported by:
poclbm miner from beta1 vesrion
ufasoft SSE2 miner
git version of jgarzik cpuminer




Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: BitLex on April 25, 2011, 02:33:25 AM
just did a quick test on XP Cat10.12/SDK2.2

HD5570 @750MHz
poclbm -f 5 -w 128 -v gives ~72Mhash/s
phoenix VECTORS AGGRESSION=10 ~68.5Mhash/s

HD5850 @775MHz
poclbm -f 40 -w 128 -v gives ~262Mhash/s
phoenix VECTORS AGGRESSION=10 ~257.5Mhash/s

not really faster it seems,
setting Aggro higher on either card just makes the system unusable, but doesn't improve speed much.





Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: CFSworks on April 25, 2011, 02:40:17 AM
Long polling support not functional.
You use old and stupid restriction: LP path with same domain and port.
There is no strict description in LP first draft specification about this.
But this is already discussed and implemented in miners.

http://domain.com:port/path/ (http://domain.com:port/path/)

Full URL Supported by:
poclbm miner from beta1 vesrion
ufasoft SSE2 miner
git version of jgarzik cpuminer

Oops, thanks for the heads up; I didn't know about that little detail, though I would have appreciated a less flamish way of letting me know.
Full-URL support will be included in the next release.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: bolapara on April 25, 2011, 02:44:22 AM
poclbm with vectors and f=1: 385MH/s
phoenix with vectors and agg=12: 377MH/s

5870


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: jedi95 on April 25, 2011, 02:47:58 AM
We certainly appreciate everyone rushing to try it, and provide feedback. Thank you very much!

We know what the problem with speed is. Our test environment uses SDK 2.4, which didn't require a worksize since the default of 256 was providing the best results. We're adding a WORKSIZE option to the kernel right now, (an equivalent to poclbm's -w) that should help you tweak it a bit more for other SDK versions.

Thank you for your patience!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: jedi95 on April 25, 2011, 04:26:56 AM
Version 1.01 has been released.

Changes:
1. Fixed RPC LP to allow different domain and port.
2. Added WORKSIZE= kernel argument to tweak performance.
3. Other minor fixes to improve speed.

We are also working on a CUDA kernel to improve performance on Nvidia hardware.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: bolapara on April 25, 2011, 05:17:16 AM
poclbm with f=1, ws=128: 385MH/s
phoenix 1.0 with agg=12: 377MH/s
phoenix 1.01 with agg=13 ws=128: 380MH/s

ubuntu 10.10, 5870, 2.1 sdk, vectors


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: dbitcoin on April 25, 2011, 05:27:40 AM
Version 1.01 has been released.

Changes:
1. Fixed RPC LP to allow different domain and port.
2. Added WORKSIZE= kernel argument to tweak performance.
3. Other minor fixes to improve speed.

We are also working on a CUDA kernel to improve performance on Nvidia hardware.

Very good.
Added to pool download page, support for long polling enabled.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: M4v3R on April 25, 2011, 06:32:24 AM
How should I use this with deepbit.net pool, where usernames are emails? The @ symbol in email conflicts with @ separator between user/password and hostname.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: bolapara on April 25, 2011, 06:33:47 AM
How should I use this with deepbit.net pool, where usernames are emails? The @ symbol in email conflicts with @ separator between user/password and hostname.

If you're in Linux just escape the @ in the username:

Code:
http://myself\@here.net:password@hostname.net

I don't use Windows so I have no clue there.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: jedi95 on April 25, 2011, 06:36:02 AM
How should I use this with deepbit.net pool, where usernames are emails? The @ symbol in email conflicts with @ separator between user/password and hostname.

You can just use the email without worrying about the conflict.

The following works:
-u http://address@site.com:password@deepbit.net:8332


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: bolapara on April 25, 2011, 06:44:20 AM
*985/900*
poclbm with f=1, ws=128: 385MH/s
phoenix 1.0 with agg=12: 377MH/s
phoenix 1.01 with agg=13 ws=128: 380MH/s

*985/300*
poclbm with f=1, ws=128: 327MH/s
phoenix 1.01 with agg=13 ws=128: 386MH/s (!!!)

ubuntu 10.10, 5870, 2.1 sdk, vectors

I was able to finally drop my memory to 300MHz without negatively impacting MH/s.

Nice work!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: eleuthria on April 25, 2011, 06:58:13 AM
1.01 fixed performance issues thanks to adding worksize.  It's now performing on-par (hard to say if more/less) with poclbm, with the exception of memory underclocking!  Just like bolapara, I was able to drop memory clocks from 975/600 to 975/300 without hurting my MH/s!

UPDATE:  Gains of about 3 mHash/sec per 5870 while being able to drop memory from 600 to 300!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: Syke on April 25, 2011, 07:13:48 AM
DEVICE=ID - Sets the OpenCL device to use. This isn't needed if you only have a single device.
So this miner requires you to run multiple instances for multi-gpu configurations? Why not just use all available devices by default?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: CFSworks on April 25, 2011, 07:29:05 AM
DEVICE=ID - Sets the OpenCL device to use. This isn't needed if you only have a single device.
So this miner requires you to run multiple instances for multi-gpu configurations? Why not just use all available devices by default?

In the (not-too-distant) future, we'll add support for multiple kernels in a single process, like this:
-k poclbm DEVICE=1 -k poclbm DEVICE=2 -k poclbm DEVICE=3 -k poclbm DEVICE=4

It's on the agenda for me to look at, either tomorrow or Tuesday, but the kernel API supports this already. :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: allinvain on April 25, 2011, 07:42:41 AM
I'm wondering if there are any plans to write a guy front end for this miner? Or maybe the same folks that wrote poclbm-gui can add support for this miner?

I'm mining in a windows environment and I'd much prefer to have a GUI frontend that I can hide in the system tray instead of having a bunch of command prompts taking up space in the start menu. I know some of you will come up with arguments that I can hide the command prompts or group them, but in my opinion having the miner hidden in the system tray is a far superior solution.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: CFSworks on April 25, 2011, 07:56:07 AM
I'm wondering if there are any plans to write a guy front end for this miner? Or maybe the same folks that wrote poclbm-gui can add support for this miner?

I'm mining in a windows environment and I'd much prefer to have a GUI frontend that I can hide in the system tray instead of having a bunch of command prompts taking up space in the start menu. I know some of you will come up with arguments that I can hide the command prompts or group them, but in my opinion having the miner hidden in the system tray is a far superior solution.



Yes, we had plans for a GUI from the beginning. We're concentrating on speed optimizations first, though. We'll get to a GUI in about a week.
If the poclbm-gui author(s) are interested, we'd love to work with them.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: allinvain on April 25, 2011, 08:21:23 AM
I'm wondering if there are any plans to write a guy front end for this miner? Or maybe the same folks that wrote poclbm-gui can add support for this miner?

I'm mining in a windows environment and I'd much prefer to have a GUI frontend that I can hide in the system tray instead of having a bunch of command prompts taking up space in the start menu. I know some of you will come up with arguments that I can hide the command prompts or group them, but in my opinion having the miner hidden in the system tray is a far superior solution.



Yes, we had plans for a GUI from the beginning. We're concentrating on speed optimizations first, though. We'll get to a GUI in about a week.
If the poclbm-gui author(s) are interested, we'd love to work with them.

Cool stuff :) Yes it would be awesome of the poclbm-gui people got involved!

I agree that performance optimizations should come first. I'll be keeping a very close eye on this thread.

Best of luck with your project!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: Raulo on April 25, 2011, 08:28:42 AM
I've just run it on testnet and it seems that although it correctly submits a valid solution, the hash is printed incorrectly. I've generated hash:
0000000016706426
and printed was:
[25/04/2011 8:20:18] Result: 26647016 accepted

It seems calculateHash is doing something incorrectly.

Regarding hashrate, it is not faster than poclbm on my 5850/Linux/SDK2.1/Cat10.12 at stock speed but surprisingly the fastest hashrate is with 300 MHz clock, where it is quite competitive to the poclbm stock speed and it runs much cooler (poclbm slows quite a lot at this mem speed).

Edit: The calculateHash is correct but the endianness is wrong. 26647016 = 16706426 in reverse endianness.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: jedi95 on April 25, 2011, 09:10:13 AM
Version 1.1 released!

This version brings a major improvement in the form of BFI_INT support. BFI_INT is a hardware instruction on newer ATI cards that allows for a 5-20% increase in hashrate. Phoenix 1.1 implements BFI_INT in the poclbm kernel by patching the binary after it's compiled, since BFI_INT is not accessible from OpenCL.

To enable BFI_INT support just add BFI_INT to the kernel arguments.


@Raulo
Thanks for the heads-up, this will be fixed in the next version.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bolapara on April 25, 2011, 09:25:06 AM
Holy crap.  Initial results are good...  But, well, I'll wait until tomorrow to tell you how effective BFI_INT (and some more OCing) are, as long as they are stable.

Feature request: it'd be nice if we had a report of the # of HW failures in the status bar as well.  Now that I'm able to push the memory speeds down I'm trying to push the GPU speeds up further and it'd be nice to see those over time.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on April 25, 2011, 09:31:41 AM
Hi can this miner be used for solo mining? If so what is the command to place the ip address of the server? ie 192.168.1.2?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 25, 2011, 09:42:14 AM
Hi can this miner be used for solo mining? If so what is the command to place the ip address of the server? ie 192.168.1.2?

Try this as your URL: http://rpcuser:rpcpassword@192.168.1.2:8332/;askrate=15
(Replacing rpcuser and rpcpassword, of course.)

Feature request: it'd be nice if we had a report of the # of HW failures in the status bar as well.  Now that I'm able to push the memory speeds down I'm trying to push the GPU speeds up further and it'd be nice to see those over time.

That's a very good idea, and I'd certainly like to see it myself. jedi95 and I are currently discussing the most "correct" way to do this internally (and how to manage limited status bar space, and other challenges like that)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jkminkov on April 25, 2011, 10:18:47 AM
I recommend for win7 x64 users

5870@950/600

desktop use:

poclbm -f 16 -w128 -v

hasrate 355.9
gpu usage @ 99%

phoenix -u -k poclbm DEVICE=0 VECTORS AGGRESSION=7 -v FASTLOOP BFI_INT

hasrate 382.6
gpu usage @ 97%

phoenix -u -k poclbm DEVICE=0 VECTORS AGGRESSION=7 -v FASTLOOP

hasrate 348.5
gpu usage @ 97%

request feature: instead xx Accepted can you add in output - Expected Shares Per Hour(xx Accepted)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 25, 2011, 10:26:58 AM
I had to escape the ;askrate on linux or else OpenCL would say it couldn't find the device.
phoenix -u http://USERNAME.WORKERNAME:PASSWORD@mining.bitcoin.cz:8332/\;askrate=12 -k poclbm DEVICE=2 VECTORS AGGRESSION=12

Standard poclbm/poclbm-mod were giving me 317Mh/s.
Phoenix was giving me 310Mh/s.
That went up to 343.5Mh/s with BFI_INT!

If you're using askrate make sure to set it properly. Calculate (type into Google) 2^32 divided by your hashrate. So mine would be 2^32/343500000=12.5035438 (so 12)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 25, 2011, 10:50:47 AM
Has anyone tried this on a 5970 yet? I'm presuming that since a 5970 is roughly nothing more than 2 5870s on the same PCB that this miner should work just as well. I could confirm this for myself but I'm wondering if anyone has beat me to it.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 10:53:58 AM
Has anyone tried this on a 5970 yet? I'm presuming that since a 5970 is roughly nothing more than 2 5870s on the same PCB that this miner should work just as well. I could confirm this for myself but I'm wondering if anyone has beat me to it.


It should work no problem on a 5970, and with similar speed gains from BFI_INT.  :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Garrett Burgwardt on April 25, 2011, 11:23:14 AM
Apparently your miner doesn't take the argument --platform, which is something that some people need (chooses old or new version of AMD APP). Once that's fixed I'll take a look at using your miner.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 11:27:25 AM
Apparently your miner doesn't take the argument --platform, which is something that some people need (chooses old or new version of AMD APP). Once that's fixed I'll take a look at using your miner.

We don't use --platform, instead it's passed as a kernel argument.

Example of running 2 miners on the same host with different platforms: (my primary computer has 2 GTX 580s and a 5870)

For GTX 580 GPU0:
phoenix.py -u http://jedi95:password@192.168.1.2:8332 -k poclbm FASTLOOP PLATFORM=0 DEVICE=0 AGGRESSION=4

For ATI 5870:
phoenix.py -u http://jedi95:password@192.168.1.2:8332 -k poclbm FASTLOOP VECTORS BFI_INT PLATFORM=1 DEVICE=0 AGGRESSION=8


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 11:44:01 AM
I had to escape the ;askrate on linux or else OpenCL would say it couldn't find the device.
phoenix -u http://USERNAME.WORKERNAME:PASSWORD@mining.bitcoin.cz:8332/\;askrate=12 -k poclbm DEVICE=2 VECTORS AGGRESSION=12

Standard poclbm/poclbm-mod were giving me 317Mh/s.
Phoenix was giving me 310Mh/s.
That went up to 343.5Mh/s with BFI_INT!

If you're using askrate make sure to set it properly. Calculate (type into Google) 2^32 divided by your hashrate. So mine would be 2^32/343500000=12.5035438 (so 12)

Nice to see that BFI_INT is working for you!

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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: yomi on April 25, 2011, 11:53:48 AM
I am getting a 'Compilation Failed' message when I try to run it:

Code:
root@apretao:~/src/phoenix-1.1# ./phoenix.py -u http://u:p@192.168.1.44:8332/
No device specified or device not found, use DEVICE=ID to specify one of the following

    [0] AMD Sempron(tm) 140 Processor
    [1] Cypress
root@apretao:~/src/phoenix-1.1# ./phoenix.py -u http://u:p@192.168.1.44:8332/ DEVICE=1
Traceback (most recent call last):
  File "./phoenix.py", line 122, in <module>
    miner.start(options)
  File "/home/edu/src/phoenix-1.1/Miner.py", line 77, in start
    self.kernel = self.options.makeKernel(KernelInterface(self))
  File "./phoenix.py", line 111, in makeKernel
    self.kernel = kernelModule.MiningKernel(requester)
  File "kernels/poclbm/__init__.py", line 203, in __init__
    self.loadKernel(self.device)
  File "kernels/poclbm/__init__.py", line 279, in loadKernel
    self.context, kernel).build(self.defines)
  File "/usr/local/lib/python2.6/dist-packages/pyopencl-0.92-py2.6-linux-x86_64.egg/pyopencl/__init__.py", line 138, in program_build
    "Build on %s:\n\n%s" % (dev, log) for dev, log in build_logs))
pyopencl.RuntimeError: clBuildProgram failed: build program failure

Build on <pyopencl.Device 'Cypress' at 0x324aad0>:

Internal error: Compilation failed.

Before that, I also had to solve this:

Code:
Build on <pyopencl.Device 'Cypress' at 0x1b3fb60>:

sh: /bin/x86_64/clc: not found


I did it by symlinking /usr/local/bin/x86_64/clc  to /bin/x86_64/clc

Anything I might have missed?

Thanks!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on April 25, 2011, 11:57:50 AM
jedi95: Thanks for releasing this miner freely, so far the hash rates are too good to believe but I am running none the less to see if it works. I have a question, will the (H==0) mod for poclbm work here?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: marcus_of_augustus on April 25, 2011, 11:57:58 AM
Can confirm following hashrates;

linux ubuntu 10.10, SDK 2.1, fglrx 11.2, HD 5970, phoenix.py kernel=poclbm vectors aggression=12, worksize=128, gpu-clock 725, mem. clock 300 : 285 Mhash/s (same as poclbm but uses less power ~20 watts less)

and then this bolter ...
BFI_INT enabled 312 mhash/s  ! (what exactly does this flag do ? suspect it is something to do with optimising integer arithmetic ALU)

Looking good, this is just great if it works long term after some testing, can now run my rigs cooler and quieter with more speed, where's that donation address i want to throw some bitcoins at you guys!

Down clocking memory on linux is big kudos and BFI_INT is off the charts ... unfortunately once this gets widespread then difficulty is going to take another hike ~10-15% I estimate.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on April 25, 2011, 11:59:49 AM
Ops i realised its already using the (H==0) mod


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 12:04:24 PM
jedi95: Thanks for releasing this miner freely, so far the hash rates are too good to believe but I am running none the less to see if it works. I have a question, will the (H==0) mod for poclbm work here?

Already applied to the kernel  ;)

Can confirm following hashrates;

linux ubuntu 10.10, SDK 2.1, fglrx 11.2, HD 5970, phoenix.py kernel=poclbm vectors aggression=12, worksize=128, gpu-clock 725, mem. clock 300 : 285 Mhash/s (same as poclbm but uses less power ~20 watts less)

and then this bolter ...
BFI_INT enabled 312 mhash/s  ! (what exactly does this flag do ? suspect it is something to do with optimising integer arithmetic ALU)

Looking good, this is just great if it works long term after some testing, can now run my rigs cooler and quieter with more speed, where's that donation address i want to throw some bitcoins at you guys!

Down clocking memory on linux is big kudos and BFI_INT is off the charts ... unfortunately once this gets widespread then difficulty is going to take another hike ~10-15% I estimate.

BFI_INT is a hardware instruction that implements the SHA256 Ch function in a single instruction instead of 3. This is why you get a performance gain.

Donation address is:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 25, 2011, 12:11:00 PM
Anything I might have missed?

Thanks!

I must have had twice your headache setting up the ATI Stream SDK on Linux for the first time. I'm guessing you downloaded it as a single archive from ATI's site?
Try setting the ATISTREAMSDKROOT environment variable to point to the directory where you extracted the SDK, since those compilation errors are most likely the result of the Stream compiler not being able to find the Stream libraries to link against.

Also, this document (http://developer.amd.com/gpu/amdappsdk/assets/ATI_Stream_SDK_Installation_Notes.pdf) was extremely useful in getting the SDK set up. I wish I had found that before I started my install, it would have saved me a lot of trouble. ;)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on April 25, 2011, 12:18:46 PM
jedi95: Thanks for releasing this miner freely, so far the hash rates are too good to believe but I am running none the less to see if it works. I have a question, will the (H==0) mod for poclbm work here?

Already applied to the kernel  ;)

Thanks for the clarification. So far my 5850 and 5970 works well with aggression=8 when its set at 12 for my pure mining rig, the hash rate reports very very low hash rates. Is it cuz the miner is unable to report the true hashrates? Also on a 6990 there is no speed gain, with BFI_INT the hash rate drops.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: marcus_of_augustus on April 25, 2011, 12:20:42 PM
Is it really dependent upon the Twisted package?

It is not installed on my system but phoenix appears to be running fine.

Edit: sorry it is there, listed as package "python-twisted" on ubuntu 10.10 (also there are other "python-twisted-*" packages in default installation twisted stack)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 12:25:30 PM
Is it really dependent upon the Twisted package?

It is not installed on my system but phoenix appears to be running fine.

I don't see how that's possible since we make extensive use of Twisted in Phoenix. The entire miner is based around a Twisted reactor. Without it you won't be able to send or receive work, much less actually mine.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: xlcus on April 25, 2011, 12:50:35 PM
So far my 5850 and 5970 works well with aggression=8 when its set at 12 for my pure mining rig, the hash rate reports very very low hash rates. Is it cuz the miner is unable to report the true hashrates?
Seing a similar thing here on my 5750...

Aggression=12 : 141.75 Mhash/sec
Aggression=8 : 143.96 Mhash/sec


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: xlcus on April 25, 2011, 12:57:40 PM
In fact Aggression=7 seems to be the sweet spot for me...

144.98 Mhash/sec


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on April 25, 2011, 01:00:02 PM
I am running 9 now..seems to max out the core at 99% and at the same time the fastest hash rate


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: keybaud on April 25, 2011, 01:06:47 PM
My HD5870 at 950/300 was originally hashing on my Win7 machine at 355 MH/s, but with Phoenix I'm now getting a reported 394 MH/s.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 25, 2011, 01:26:58 PM
I had to escape the ;askrate on linux or else OpenCL would say it couldn't find the device.
phoenix -u http://USERNAME.WORKERNAME:PASSWORD@mining.bitcoin.cz:8332/\;askrate=12 -k poclbm DEVICE=2 VECTORS AGGRESSION=12

Standard poclbm/poclbm-mod were giving me 317Mh/s.
Phoenix was giving me 310Mh/s.
That went up to 343.5Mh/s with BFI_INT!

If you're using askrate make sure to set it properly. Calculate (type into Google) 2^32 divided by your hashrate. So mine would be 2^32/343500000=12.5035438 (so 12)

Nice to see that BFI_INT is working for you!

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.

Any numbers on efficiency vs poclbm and -mod?  Any idea whether this would lighten the work loads on pool servers too?

Also, I know BFI_INT most likey won't work on CPU's, but have you explored using any other of these ideas for CPU mining since there are probably still quite a few CPU miners out there (no matter how futile).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Cheeseman on April 25, 2011, 01:29:38 PM
I'm seeing around a 10% increase in speeds on my dual 5870 rig.

965/300 5870 on poclbm - 360 mhash
965/300 5870 on Phoenix - 390 mhash

910/300 5870 on poclbm - 330 mhash
910/300 5870 on Phoenix - 365 mhash

Working on Deepbit with long polling. Much lower temps and power consumption as well.

Thanks jedi, great work.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jkminkov on April 25, 2011, 01:36:54 PM
 Any idea whether this would lighten the work loads on pool servers too?

I see increased number of rejected units, probably because current work is not being dropped but reported to server and rejected, happens right after long pool message


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 25, 2011, 01:49:43 PM
 Any idea whether this would lighten the work loads on pool servers too?

I see increased number of rejected units, probably because current work is not being dropped but reported to server and rejected, happens right after long pool message

I'm not seeing any increase since I've been running it. Perhaps it is work that is submitted right before LP is checked so it's rejected by the server because of new data?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 25, 2011, 01:57:28 PM
Some numbers for all to meditate upon:

Radeon 5970
Core clock 850 Mhz
Memory Clock 300 MHz

Aggression level 7 with the BFI_INT turned on

Getting 346 Mhash/sec for each GPU core!! Pretty nice improvement over the 317 I used to get with poclbm! :) So overall I'm happy

Maybe it is just me but I get the impression that the GPUs aren't "working as hard" with this miner as the temps are a bit lower than with poclbm yet I get higher performance.

So far it has been 5 min running this miner and the hashing rate is averaging around 347 Mhash/sec.




Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: bolapara on April 25, 2011, 02:45:57 PM
Updating with new results...

*985/900*
poclbm with f=1, ws=128: 385MH/s
phoenix 1.0 with agg=12: 377MH/s
phoenix 1.01 with agg=13, ws=128: 380MH/s

*985/300*
poclbm with f=1, ws=128: 327MH/s
phoenix 1.01 with agg=13 ws=128: 386MH/s

*1010/300*
phoenix 1.01 with agg=13, ws=128, BFI_INT: 437MH/s (!!!)

ubuntu 10.10, 5870, 2.1 sdk, vectors

Since I was able to bring down temps by going to 300MHz memory clock, I was able to bump up the GPU clock to 1010MHz and with BFI_INT I am getting 437MH/s.  It's run for about 7-8 hours so far without issues.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: xlcus on April 25, 2011, 02:58:59 PM
Getting quite a lot of these errors...

Code:
[25/04/2011 15:57:05] Disconnected from server
[RPC (+LP)]Unhandled error in Deferred:
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 354, in _startRunCallbacks
    self._runCallbacks()
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 371, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 330, in _continue
    self.unpause()
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 325, in unpause
    self._runCallbacks()
--- <exception caught here> ---
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 371, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "/home/xlcus/bitcoin/phoenix-1.1/minerutil/RPCProtocol.py", line 244, in <lambda>
    d.addErrback(lambda x: self._failure())
  File "/home/xlcus/bitcoin/phoenix-1.1/minerutil/RPCProtocol.py", line 307, in _failure
    self._setLongPollingPath(None)
  File "/home/xlcus/bitcoin/phoenix-1.1/minerutil/RPCProtocol.py", line 174, in _setLongPollingPath
    self.activeLongPoll.cancel()
exceptions.AttributeE

I'm running the linux version on Ubuntu, with a 5750, connected to deepbit.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 25, 2011, 03:05:48 PM
You have to bios flash to get those lower clocks available?

I have a Sapphire 5970 - any suggested bios out there?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 25, 2011, 03:09:41 PM
You have to bios flash to get those lower clocks available?

I have a Sapphire 5970 - any suggested bios out there?

You mean the memory clocks down to 300? No no flash is necessary AFAIK. If you use windows go and grab MSI afterburner. Search this mining section for a thread that's dedicated to lowering mem clocks. There are certain steps you need to take to get the mem clocks that low - don't worry they're not hard. I'm about to go to sleep here so I'm sorry but I can't paste a direct link to the thread - normally I would....



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: ghost on April 25, 2011, 03:13:48 PM
You have to bios flash to get those lower clocks available?

I have a Sapphire 5970 - any suggested bios out there?

You mean the memory clocks down to 300? No no flash is necessary AFAIK. If you use windows go and grab MSI afterburner. Search this mining section for a thread that's dedicated to lowering mem clocks. There are certain steps you need to take to get the mem clocks that low - don't worry they're not hard. I'm about to go to sleep here so I'm sorry but I can't paste a direct link to the thread - normally I would....



Is Windows the only way to do this?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 25, 2011, 03:21:45 PM
Nope, you can do it in Linux as well.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: OgiDogi on April 25, 2011, 03:24:18 PM
 Any idea whether this would lighten the work loads on pool servers too?

I see increased number of rejected units, probably because current work is not being dropped but reported to server and rejected, happens right after long pool message

I'm not seeing any increase since I've been running it. Perhaps it is work that is submitted right before LP is checked so it's rejected by the server because of new data?
That happens to me every time after the LP message and I get even 2 rejected results every now and then. Roughly 4% rejected results. I've tried to attach an image but the server says some folder is full or probably attaching files is forbidden but here it is on Imageshack:

http://img863.imageshack.us/img863/9981/rejected.jpg


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 25, 2011, 03:29:02 PM
Doesn't let me choose lower than 1000 mem clock in linux


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bolapara on April 25, 2011, 03:32:53 PM
Doesn't let me choose lower than 1000 mem clock in linux

I use this tool:

http://kde-apps.org/content/show.php/ATI+Overclocking+Utility+X64?content=107457 (http://kde-apps.org/content/show.php/ATI+Overclocking+Utility+X64?content=107457)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 25, 2011, 03:37:49 PM
Darn - don't use KDE - XFCE -- thanks though

I'll post my info

5970 at 805/1000

poclbm (from git) = 316 Mh/s (-v -w128 -f2)

phoenix = 311 (VECTORS=on AGGRESSION=10 WORKSIZE=128 FASTLOOP)
phoenix = 343 (same as above with BFI_INT added)

This will be widespread by this evening and difficulty will go up for sure.

Wonder if mrb_'s miner is posting numbers this fast?



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bolapara on April 25, 2011, 03:43:37 PM
Not using KDE myself either.  It's dependencies are just QT and QT Networking, iirc.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 25, 2011, 03:44:24 PM
OK - will try that when i get home this evening


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 25, 2011, 04:02:39 PM
Get it directly here. http://sourceforge.net/projects/amdovdrvctrl/
There is a .deb that will work with Ubuntu 10.10 here:
http://sourceforge.net/projects/amdovdrvctrl/files/deb%20binaries/

The packages libwxbase2.8-0 and libwxgtk2.8-0 need to be installed before this as dependencies before installing the amdovdrvctrl program.

Then you need to configure a OverDrive file to execute like the following (courtesy of Raulo):

Code:
<?xml version="1.0" encoding="utf-8"?>
<OVERDRIVE_PROFILE>
  <PERFORMANCE_LEVEL level="2" gpu="85000" mem="30000" voltage="1088"/>
  <PERFORMANCE_LEVEL level="1" gpu="55000" mem="30000" voltage="1038"/>
  <PERFORMANCE_LEVEL level="0" gpu="15700" mem="30000" voltage="1000"/>
  <FAN_SETTING percentage="AUTO"/>
  <FAN_CTRL enabled="yes"/>
  <FAN_CTRL_CURVE type="0"/>
  <FAN_CTRL_POINT nr="0" temperature="2000" percentage="0"/>
  <FAN_CTRL_POINT nr="1" temperature="4000" percentage="2500"/>
  <FAN_CTRL_POINT nr="2" temperature="6000" percentage="5000"/>
  <FAN_CTRL_POINT nr="3" temperature="8000" percentage="7500"/>
  <FAN_CTRL_POINT nr="4" temperature="10000" percentage="10000"/>
  <MONITOR_SAMPLE_TIME interval="10"/>
  <COLOR_PROFILE enabled="no" longitude="-13.000000" latitude="52.000000" color_temp_day="130000" color_temp_night="68000" transition="30"/>
</OVERDRIVE_PROFILE>

Warning: Do not use this file without verifying the settings or changing them for your card. Running this program with the wrong settings can kill your card.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 25, 2011, 04:05:38 PM
@grndzero - thanks!

Can you use a range besides the 300?

Code:
jw@Krypton:~$ aticonfig --odgc --adapter=all

Adapter 0 - ATI Radeon HD 5900 Series
                            Core (MHz)    Memory (MHz)
           Current Clocks :    805           1000
             Current Peak :    805           1000
  Configurable Peak Range : [550-1000]     [1000-1500]
                 GPU load :    99%

Adapter 1 - ATI Radeon HD 5900 Series
                            Core (MHz)    Memory (MHz)
           Current Clocks :    805           1000
             Current Peak :    805           1000
  Configurable Peak Range : [550-1000]     [1000-1500]
                 GPU load :    99%

EDIT - Need to learn how to install .deb packages manually.  I am new to Ubuntu (knew Gentoo better - sorta)  ;)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 25, 2011, 04:08:25 PM
I've had AMDOverdriveCtl for a week and just got around to trying it out. Man does it make a difference!

900/1000

poclbm - 317Mh/s
phoenix - 343Mh/s

900/300

poclbm - 293Mh/s
phoenix - 360Mh/s!

I also got to drop my fan speed from 80% to 60% (much less noisy) to keep the same temp ~70C!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 25, 2011, 04:10:52 PM
I put a 120mm fan on top of the 5970 - allows me to turn down the fan to 50% and keep temps around 70

The GPU is in a 4u case so it is easy to lay the fan on it


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 25, 2011, 04:12:20 PM
@grndzero - thanks!

Can you use a range besides the 300?


Yes, I actually started at 600 and stepped it down to 300, but even when I put 600 in the config file amdconfig showed 300 as the bottom point. Some people have said that theirs wouldn't go all the way down to 300 without locking up.

I also hard coded the fan speed in my file instead of AUTO and turned off fan control.

EDIT - Need to learn how to install .deb packages manually.  I am new to Ubuntu (knew Gentoo better - sorta)  ;)

From Terminal:
sudo apt-get install libwxbase2.8-0 libwxgtk2.8-0
sudo dpkg -i packagename.deb


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bolapara on April 25, 2011, 04:20:02 PM
Get it directly here. http://sourceforge.net/projects/amdovdrvctrl/

That is different than what I mentioned above but apparently works for some.  For me, that program just segfaults.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 04:29:15 PM
 Any idea whether this would lighten the work loads on pool servers too?

I see increased number of rejected units, probably because current work is not being dropped but reported to server and rejected, happens right after long pool message

I'm not seeing any increase since I've been running it. Perhaps it is work that is submitted right before LP is checked so it's rejected by the server because of new data?
That happens to me every time after the LP message and I get even 2 rejected results every now and then. Roughly 4% rejected results. I've tried to attach an image but the server says some folder is full or probably attaching files is forbidden but here it is on Imageshack:

http://img863.imageshack.us/img863/9981/rejected.jpg

Currently Phoenix doesn't interrupt sending results to the server when new work is pushed. Those rejected shares were probably sent or in the process of being sent when the LP push was received. This does not reduce the number of accepted shares compared to other miners because the kernel starts on the new work within a fraction of a second of the long poll returning.

I know that poclbm clears its result queue when a long poll is received, so the best way to compare it to Phoenix is to look at the total accepted shares rather than the percentage.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: yomi on April 25, 2011, 04:39:36 PM

I must have had twice your headache setting up the ATI Stream SDK on Linux for the first time. I'm guessing you downloaded it as a single archive from ATI's site?
Try setting the ATISTREAMSDKROOT environment variable to point to the directory where you extracted the SDK, since those compilation errors are most likely the result of the Stream compiler not being able to find the Stream libraries to link against.

Thanks, that did it!

Also, this document (http://developer.amd.com/gpu/amdappsdk/assets/ATI_Stream_SDK_Installation_Notes.pdf) was extremely useful in getting the SDK set up. I wish I had found that before I started my install, it would have saved me a lot of trouble. ;)

Nice document, very interesting, thanks again.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: eleuthria on April 25, 2011, 04:43:23 PM
Absolutely amazing work.  With the new BFI_INT flag, my 5870s are churning out work at 420-421 mHash/sec each!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: luffy on April 25, 2011, 05:17:04 PM
i confirm noticable increase with 5xxx cards, but the same keys can't give anything to 6950/70!
very good job guys, well done. hopefully the 6xxx cards will get the same increase with a later revision  ;)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: [Tycho] on April 25, 2011, 05:19:51 PM
Looks like you aren't receiving private messages from me, so i'm writing here.

Your miner inherited an old poclbm bug (or just recreated it) - reading pool's answer takes very long time with your miner, about ~200 ms and up to 2 sec in some cases - i see this in my pool's log. When we discussed this with m0mchil, he managed to fix it and now this delay is close to 0 ms.

Two possible causes of this:
1) Python bug - reading HTTP headers by one byte at a time ( http://bugs.python.org/issue1542407 )
2) TCP_NODELAY not used (looks like the main cause).

This may also help:
http://code.google.com/p/httplib2/issues/detail?id=91
http://code.google.com/p/httplib2/issues/detail?id=28

I'm not sure which one was the fix, but something should help :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Posidon on April 25, 2011, 05:40:43 PM
A bit of a noob question here, but is there a particular directory in Windows 7 that Phoenix must be extracted to in order for it to function.  I can't seem to get the program to open properly, it just flashes the command prompt and closes.  I currently have it extracted to my desktop.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: [Tycho] on April 25, 2011, 05:45:52 PM
A bit of a noob question here, but is there a particular directory in Windows 7 that Phoenix must be extracted to in order for it to function.  I can't seem to get the program to open properly, it just flashes the command prompt and closes.  I currently have it extracted to my desktop.
There is no GUI, you should supply some command-line arguments for it to work.
Start a command prompt (cmd) or some FAR-like file manager and try to run it from there.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Dezeer on April 25, 2011, 06:04:39 PM
Should the command line report finished workunits when solo mining, like poclbm-gui does or does it only show output when it finds a block? Now it looks like it's doing "nothing" as it only shows the hashrate.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: anatolikostis on April 25, 2011, 06:49:55 PM
From 266 mhash to 296 mhash - not bad, not bad !
 :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Littleshop on April 25, 2011, 07:00:07 PM
Windows 7 64 bit problem here:

I extracted to c:\ph and am running the command with arguements but I get Failed to connect, retrying....

Are there other components required?

The only software on the machine is the full ATI drivers and GUIminer (which I have closed)



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: stillfire on April 25, 2011, 07:02:52 PM
Trying to get it to run on Mac OS X. It worked once with DEVICE=0 VECTORS AGGRESSION=7 but after stopping it to try other parameters it stopped working with the error "[25/04/2011 15:59:52] FATAL kernel error: Failed to compile OpenCL kernel!". Looking in the generated crash log there's this:


Code:
Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000101fc3000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib                   0x00007fff87fa7506 strtol_l + 75
1   ...pple.ATIRadeonX2000GLDriver      0x000000011502632f glrCompDeleteProgram + 4895
2   ...pple.ATIRadeonX2000GLDriver      0x0000000115026535 glrCompDeleteProgram + 5413
...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Posidon on April 25, 2011, 07:08:10 PM
A bit of a noob question here, but is there a particular directory in Windows 7 that Phoenix must be extracted to in order for it to function.  I can't seem to get the program to open properly, it just flashes the command prompt and closes.  I currently have it extracted to my desktop.
There is no GUI, you should supply some command-line arguments for it to work.
Start a command prompt (cmd) or some FAR-like file manager and try to run it from there.

Looks like I figured out how to do it through the command prompt.  Thanks.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 07:30:55 PM
Trying to get it to run on Mac OS X. It worked once with DEVICE=0 VECTORS AGGRESSION=7 but after stopping it to try other parameters it stopped working with the error "[25/04/2011 15:59:52] FATAL kernel error: Failed to compile OpenCL kernel!". Looking in the generated crash log there's this:


Code:
Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000101fc3000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib                   0x00007fff87fa7506 strtol_l + 75
1   ...pple.ATIRadeonX2000GLDriver      0x000000011502632f glrCompDeleteProgram + 4895
2   ...pple.ATIRadeonX2000GLDriver      0x0000000115026535 glrCompDeleteProgram + 5413
...

OSX uses its own OpenCL implementation, which might cause problems if you try to use VECTORS or BFI_INT. Try running without those and see if it works.

Windows 7 64 bit problem here:

I extracted to c:\ph and am running the command with arguements but I get Failed to connect, retrying....

Are there other components required?

The only software on the machine is the full ATI drivers and GUIminer (which I have closed)


What command line arguments are you using?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: stillfire on April 25, 2011, 07:50:38 PM
Oddly, I can't seem to get it to work without using VECTORS. I get a segmentation fault/bus error without it. The other weird thing is that I can't run Phoenix twice without deleting the compilation output. E.g.

Code:
$ python phoenix.py -v -u XXX DEVICE=0 VECTORS AGGRESSION=2 FASTLOOP
[25/04/2011 16:44:12] FATAL kernel error: Failed to compile OpenCL kernel!

$ rm kernels/poclbm/*.elf
$ python phoenix.py -v -u XXX DEVICE=0 VECTORS AGGRESSION=2 FASTLOOP
[25/04/2011 16:44:45] Connected to server
[25/04/2011 16:44:45] Server gave new work; passing to WorkQueue

Exactly the same command seems to work if I first delete *.elf. Very mysterious. Almost like there's a bug in pyopencl on the Mac where it fails to delete the previous object file or something like that.

Anyhow now I got it to work but unfortunately it runs at or around 50 Mhash/s instead of while Diablo miner hits 80 Mhash/s on my Radeon HD 4870. The upside is that with AGGRESSION=2 it is possible to run it in the background - with Diablo even -f 120 renders the system very jerky indeed. So maybe I'll run with phoenix for a while even at a slower rate since it's much less annoying. :)

Thanks for writing this. The code looks great.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Littleshop on April 25, 2011, 07:51:10 PM
Windows 7 64 bit problem here:

I extracted to c:\ph and am running the command with arguements but I get Failed to connect, retrying....

Are there other components required?

The only software on the machine is the full ATI drivers and GUIminer (which I have closed)


What command line arguments are you using?

c:\ph>phoenix.exe -u http://littleshop@miner1:mypasshere@btcmine.com:8332/ -k poclbm DEVICE=0 AGGRESSION=3
[25/04/2011 14:51:18] Failed to connect, retrying...
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: stillfire on April 25, 2011, 07:55:49 PM
Turns out I can get 60Mhash/s with AGGRESSION=3 on my Mac Pro without making the desktop too jerky. Feels like a nice compromise.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: BitLex on April 25, 2011, 08:28:14 PM
just did a quick test on XP Cat10.12/SDK2.2

HD5570 @750MHz
poclbm -f 5 -w 128 -v gives ~72Mhash/s
phoenix VECTORS AGGRESSION=10 ~68.5Mhash/s

HD5850 @775MHz
poclbm -f 40 -w 128 -v gives ~262Mhash/s
phoenix VECTORS AGGRESSION=10 ~257.5Mhash/s

not really faster it seems,
setting Aggro higher on either card just makes the system unusable, but doesn't improve speed much.

phoenix1.1 test using WORKSIZE=128 and BF_INT

HD5570 ~76Mhash/s
HD5850 ~286Mhash/s

which is a nice improvement on that 5850,
however, the downside is a real bad ratio of 'Rejected' hashes,
>2% on the 5850 and 10% on the 5570.
 
another quick test on a different system/card (5850@900MHz) didn't improve speed at all (~313Mhash/s on both, poclbm and phoenix), which also seems kinda strange.

 


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: grndzero on April 25, 2011, 08:33:16 PM
another quick test on a different system/card (5850@900MHz) didn't improve speed at all (~313Mhash/s on both, poclbm and phoenix), which also seems kinda strange.

That is really wierd. My 5850's went from 317 @ 900/1000 to 343 by just changing from poclbm to phoenix.

Try dropping the worksize. I just added it to mine and it slowed it down.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Raulo on April 25, 2011, 08:46:38 PM
jedi95,

Are you going to create a git repository for phoenix? It would be much easier to track changes. I also did some local modifications (e.g., I run the miner with difficulty 1) and it would be much easier to apply them with git.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: ghost on April 25, 2011, 08:57:21 PM
I was just going to mention the usefulness of a git repo. +1 from me


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TenthReality on April 25, 2011, 09:05:17 PM
Seeing a much higher rejection rate here, most specifically when the LP hands off a new piece of work.   More than 50% of the time when that happens my first result is rejected. The same appears to be holding across 6 cards (5970 down to 5830's).  Copy/paste of results w/ pruning is as follows:

Code:
[25/04/2011 16:59:38] Result: 6a71879e accepted
[25/04/2011 16:59:57] LP: New work pushed
[25/04/2011 17:00:06] Result: 01b8fa68 rejected
[25/04/2011 17:00:13] Result: bf28fa45 accepted
*snip*
[25/04/2011 17:02:06] Result: 13646ef1 accepted
[25/04/2011 17:02:16] LP: New work pushed
[25/04/2011 17:02:26] Result: 9bc866ef rejected


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 25, 2011, 09:21:09 PM
I am at about .7% rejected -- more than I would like to see  :(


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TenthReality on April 25, 2011, 09:26:38 PM
Math wise, the extra rejected are being massively offset by the increased speeds of the hashing.  Still seeing about 11% over just poclbm even with the rejection rates.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 25, 2011, 09:26:56 PM
Looks like you aren't receiving private messages from me, so i'm writing here.

Your miner inherited an old poclbm bug (or just recreated it) - reading pool's answer takes very long time with your miner, about ~200 ms and up to 2 sec in some cases - i see this in my pool's log. When we discussed this with m0mchil, he managed to fix it and now this delay is close to 0 ms.

I'm the primary maintainer of all the code in the minerutil package, which looks like it may be the culprit. Did you send me a PM too? I didn't get one either.

Quote
Two possible causes of this:
1) Python bug - reading HTTP headers by one byte at a time ( http://bugs.python.org/issue1542407 )
2) TCP_NODELAY not used (looks like the main cause).

What's interesting is RPCProtocol doesn't use any Python HTTP libraries, it's all done through Twisted;
so while it could be a problem in Twisted, I don't think the linked bug is the answer.

The lack of TCP_NODELAY is interesting. Doesn't that only disable Nagle's algorithm, which affects sends?
How would it delay received data?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 25, 2011, 09:31:13 PM
jedi95,

Are you going to create a git repository for phoenix? It would be much easier to track changes. I also did some local modifications (e.g., I run the miner with difficulty 1) and it would be much easier to apply them with git.

I originally wanted to put it in a git repository when we started the project, but the setup was more complex than svn's.
We'd be happy to migrate now, however our classes depend on svn's revision numbers for versioning in a few places.
Does anybody know if there's a direct analog in git?

Until then, feel free to send us patch files for review. :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: marcus_of_augustus on April 25, 2011, 09:32:54 PM
Under-clocking mem. clock on Linux can be down simply using the little tool linked to in this thread.
http://bitcointalk.org/index.php?topic=4806.msg74527#msg74527

 Read what "Ian" has to say ... you just have to move the slider down to 300 (or whatever you choose) and when you go back to "$aticonfig --odgc --adapter=all" on CLI then low mem. speeds will be available ... then do the "aticonfig" command for clock speed you want (all at your own risk of course).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: EgoPaintedGrey on April 25, 2011, 09:33:33 PM
Well, running -k poclbm DEVICE=0 VECTORS AGGRESSION=13 BFI_INT with my 5870 @980/300

With poclbm (gui) and the fix I was getting 376 M hash/sec.
With Phoenix I´m getting 412 M hash/sec.

What is the Max aggresision value I can use?
I´m getting this message sometimes  Kernel error: Unusual behavior from OpenCL. Hardware problem? Is this happening due to a non stable oc?
Should I be running any other command?



BTW, GRAET WORK!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Raulo on April 25, 2011, 09:45:23 PM

I originally wanted to put it in a git repository when we started the project, but the setup was more complex than svn's.
We'd be happy to migrate now, however our classes depend on svn's revision numbers for versioning in a few places.
Does anybody know if there's a direct analog in git?

Until then, feel free to send us patch files for review. :)

There is a git svn interface, you can setup a git repository on, e.g. github, and sync it with your internal subversion repository.
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
I used to use subversion and after learning git, I find it much better.

My patches would probably not interest general audience. I corrected the endianness bug (in an ugly way for those who know python better) by printing
Code:
hexHash[6]+hexHash[7]+hexHash[4]+hexHash[5]+hexHash[2]+hexHash[3]+hexHash[0]+hexHash[1]
instead of hexhash[-8:].
I also removed checking the target (so the calculation is always difficulty 1) and removed some printing so it will not clutter my logs.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitjet on April 25, 2011, 09:49:20 PM
Im getting a ton of "work queue empty, minder is idle" messages

im on a 5970 flags are -k poclbm DEVICE=0 VECTORS AGGRESSION=14 BFI_INT



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 09:50:16 PM
Well, running -k poclbm DEVICE=0 VECTORS AGGRESSION=13 BFI_INT with my 5870 @980/300

With poclbm (gui) and the fix I was getting 376 M hash/sec.
With Phoenix I´m getting 412 M hash/sec.

What is the Max aggresision value I can use?
I´m getting this message sometimes  Kernel error: Unusual behavior from OpenCL. Hardware problem? Is this happening due to a non stable oc?
Should I be running any other command?

BTW, GRAET WORK!

"Kernel error: Unusual behavior from OpenCL. Hardware problem?"

This means that the OpenCL kernel returned a nonce that supposedly met the target of 1, but when this nonce is verified on the CPU it does not. This usually means your overclock is unstable.


Im getting a ton of "work queue empty, minder is idle" messages

im on a 5970 flags are -k poclbm DEVICE=0 VECTORS AGGRESSION=14 BFI_INT


What server/pool are you connecting to? This usually indicates that the server is not responding to requests for work in a timely manner. This can also happen if you use a queue size that's too small. (default of 1 should work for basically any GPU currently, unless you set it to 0 this probably isn't the issue)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 25, 2011, 09:51:17 PM
I seem to only get a max usage of 30% on my GPU.

Edit: 6950 with shaders unlocked.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 25, 2011, 09:52:18 PM
Im getting a ton of "work queue empty, minder is idle" messages

im on a 5970 flags are -k poclbm DEVICE=0 VECTORS AGGRESSION=14 BFI_INT

That's interesting. Are you mining solo or in a pool? If so, what pool?
You may need to speak with your pool operator about this.

Could you post the URL you are using? (edit out the username and password)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: [Tycho] on April 25, 2011, 09:54:11 PM
What's interesting is RPCProtocol doesn't use any Python HTTP libraries, it's all done through Twisted;
so while it could be a problem in Twisted, I don't think the linked bug is the answer.
The lack of TCP_NODELAY is interesting. Doesn't that only disable Nagle's algorithm, which affects sends?
How would it delay received data?
I didn't saw your source yet and can only see the results at my side, sorry.
It means that the reason for that delay is different. Look for a log fragment in PM.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitjet on April 25, 2011, 10:04:02 PM
Im getting a ton of "work queue empty, minder is idle" messages

im on a 5970 flags are -k poclbm DEVICE=0 VECTORS AGGRESSION=14 BFI_INT

That's interesting. Are you mining solo or in a pool? If so, what pool?
You may need to speak with your pool operator about this.

Could you post the URL you are using? (edit out the username and password)

deepbit. But the problem seems to be gone when I lower my aggression to 12. Does this mean my miner is trying to work even faster at 14 but can not due to limitations getting work?

Im getting ~362mhps per core on 5970. Best I could do on poclbm is 330.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: EgoPaintedGrey on April 25, 2011, 10:09:56 PM
deepbit. But the problem seems to be gone when I lower my aggression to 12. Does this mean my miner is trying to work even faster at 14 but can not due to limitations getting work?

Im getting ~362mhps per core on 5970. Best I could do on poclbm is 330.

After reading your post I tried Aggression=14 on deepbit too. Warning: work queue empty, miner is idle. With 13 it´s running fine.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bongo on April 25, 2011, 10:11:19 PM
Decent increase ~10%  ;D, only question is, is it doing anything? Mining solo I only get :

[26/04/2011 01:07:52] Server gave new work; passing to WorkQueue
[26/04/2011 01:08:02] Server gave new work; passing to WorkQueue
[26/04/2011 01:08:13] Server gave new work; passing to WorkQueue
[26/04/2011 01:08:24] Server gave new work; passing to WorkQueue
[404.10 Mhash/sec] [0 Accepted] [0 Rejected] [RPC]

Is it normal to get 0 Accepted while solo?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 25, 2011, 10:18:43 PM
Decent increase ~10%  ;D, only question is, is it doing anything? Mining solo I only get :

[26/04/2011 01:07:52] Server gave new work; passing to WorkQueue
[26/04/2011 01:08:02] Server gave new work; passing to WorkQueue
[26/04/2011 01:08:13] Server gave new work; passing to WorkQueue
[26/04/2011 01:08:24] Server gave new work; passing to WorkQueue
[404.10 Mhash/sec] [0 Accepted] [0 Rejected] [RPC]

Is it normal to get 0 Accepted while solo?

Yeah can take a week or more to generate while solo.  Was unaware LP worked with solo though?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 10:27:47 PM
Decent increase ~10%  ;D, only question is, is it doing anything? Mining solo I only get :

[26/04/2011 01:07:52] Server gave new work; passing to WorkQueue
[26/04/2011 01:08:02] Server gave new work; passing to WorkQueue
[26/04/2011 01:08:13] Server gave new work; passing to WorkQueue
[26/04/2011 01:08:24] Server gave new work; passing to WorkQueue
[404.10 Mhash/sec] [0 Accepted] [0 Rejected] [RPC]

Is it normal to get 0 Accepted while solo?

Yeah can take a week or more to generate while solo.  Was unaware LP worked with solo though?

This is normal, we will be adding a debug message indicating when difficulty 1 shares are found but not submitted. (like when solo mining) Since you have -v enabled you will be able to see these messages.

Also, bitcoind doesn't support LP, so you might want to specify an askrate.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 25, 2011, 10:30:35 PM
Any idea why it's not maxing out my gpu jedi tried it with all different flags.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 10:33:35 PM
Any idea why it's not maxing out my gpu jedi tried it with all different flags.

I don't have a 69xx card to test with, so I couldn't say for sure.

Do other miners load the card to 100%?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 25, 2011, 10:38:15 PM
Any idea why it's not maxing out my gpu jedi tried it with all different flags.

I don't have a 69xx card to test with, so I couldn't say for sure.

Do other miners load the card to 100%?

Yeah they do I guess I'll wait for feedback from others who have a 69xx card.  Thanks for the response if it would use 100% it seems it would be about 30 mhash/s faster


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 10:44:47 PM
Any idea why it's not maxing out my gpu jedi tried it with all different flags.

I don't have a 69xx card to test with, so I couldn't say for sure.

Do other miners load the card to 100%?

Yeah they do I guess I'll wait for feedback from others who have a 69xx card.  Thanks for the response if it would use 100% it seems it would be about 30 mhash/s faster

The only similar behavior I can produce on a 5870 is low GPU usage with AGGRESSION=1 or not specified. Try using AGGRESSION=7 if you haven't already.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 25, 2011, 10:54:15 PM
Any idea why it's not maxing out my gpu jedi tried it with all different flags.

I don't have a 69xx card to test with, so I couldn't say for sure.

Do other miners load the card to 100%?

Yeah they do I guess I'll wait for feedback from others who have a 69xx card.  Thanks for the response if it would use 100% it seems it would be about 30 mhash/s faster

The only similar behavior I can produce on a 5870 is low GPU usage with AGGRESSION=1 or not specified. Try using AGGRESSION=7 if you haven't already.

I tried 10, 12, I even put it up to 5,000 lol but will try 7 real quick thanks.

Edit: errm it might help if I spelled "aggression" right lol it works now sorry for the bother.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dust on April 25, 2011, 11:02:22 PM
I seem to only get a max usage of 30% on my GPU.

Edit: 6950 with shaders unlocked.
Same problem with a 5970, only about 40% GPU load.  I've tried a variety of settings.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 25, 2011, 11:03:53 PM
I seem to only get a max usage of 30% on my GPU.

Edit: 6950 with shaders unlocked.
Same problem with a 5970, only about 40% GPU load.  I've tried a variety of settings.



For me I spelled "aggression" wrong I typed aggresion try that with default aggression it only uses about a third.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: samsarulz on April 25, 2011, 11:05:13 PM
I get some strange error, after a Warnung appears and says "work queue empty, miner is idle"

http://img820.imageshack.us/img820/1577/errorphoenix.gif (http://img820.imageshack.us/i/errorphoenix.gif/)

Uploaded with ImageShack.us (http://imageshack.us)

I´m using this command line in a bat file

start /DC:\Bitcoin\phoenix-1.1 phoenix -v -u http://samsarulz666@gmail.com:mypasshere@deepbit.net:8332 -k poclbm device=0 WORKSIZE=128 VECTORS AGGRESSION=7 FASTLOOP BFI_INT

I´am running a XFX HD6950 with shaders unlocked (1536sp) at 840 OC GPU

with guiminer = average 320 Mhash/s
with phoenix = average  349 Mhash/s

So is a very noticeable improve!

Thanks


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: OVerLoRDI on April 25, 2011, 11:05:51 PM
Saw similar increases with my 5870s as others have.

My 6970s saw either no increase or decrease in performance depending on the flags.

Also so no increase on my 5770.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dust on April 25, 2011, 11:10:35 PM
I seem to only get a max usage of 30% on my GPU.

Edit: 6950 with shaders unlocked.
Same problem with a 5970, only about 40% GPU load.  I've tried a variety of settings.



For me I spelled "aggression" wrong I typed aggresion try that with default aggression it only uses about a third.
Haha I did the same thing: "AGRESSION" Solved.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 25, 2011, 11:17:26 PM
Hehe we are so smart S.M.R.T.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: fasti on April 25, 2011, 11:35:46 PM
I got 6950 default FW, 840core 759memory (too much hazzle to swap between ~300 and 1250 for gaming, when it crashes randomly when I'm taking it to 300)

Using this one for afk/sleep mining:
326 98%gpu 84c 40%fans(2)
-u http://username:password@miningsite:port/ -k poclbm DEVICE=0 VECTORS AGGRESSION=7 FASTLOOP BFI_INT WORKSIZE=64

General use + videos:
321 (313-318 while watching) 97%gpu 83c 39%fans(2)
-u http://username:password@miningsite:port/ -k poclbm DEVICE=0 VECTORS AGGRESSION=6 FASTLOOP BFI_INT WORKSIZE=64

Gaming:
301 while not gaming(810core, 1250memory)
-u http://username:password@miningsite:port/ -k poclbm DEVICE=0 VECTORS AGGRESSION=5 FASTLOOP BFI_INT WORKSIZE=64
Tips: you wan't to disable shadows as much as possible, they take lots of gpu power for such a tiny gaming experience. Also using lesser directx version might have a huge impact.

AGGRESSION from 7 onwards gain 99%gpu and ~1Mhash/s per step up to 10, then it becomes so slow to update it's own hash rate and something else so don't know... got it showing up to 330Mhash/s with 840core 759memory.

WORKSIZE=64 or 128 doesn't seem to be any different at all so I chose the lesser number, 256 is very bad thou, drops Mhash/s to ~270.
What does this actually do anyway?

This is giving me 12% more hash power than poclbm.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 25, 2011, 11:47:44 PM
I got 6950 default FW, 840core 759memory (too much hazzle to swap between ~300 and 1250 for gaming, when it crashes randomly when I'm taking it to 300)

Using this one for afk/sleep mining:
326 98%gpu 84c 40%fans(2)
-u http://username:password@miningsite:port/ -k poclbm DEVICE=0 VECTORS AGGRESSION=7 FASTLOOP BFI_INT WORKSIZE=64

General use + videos:
321 (313-318 while watching) 97%gpu 83c 39%fans(2)
-u http://username:password@miningsite:port/ -k poclbm DEVICE=0 VECTORS AGGRESSION=6 FASTLOOP BFI_INT WORKSIZE=64

Gaming:
301 while not gaming(810core, 1250memory)
-u http://username:password@miningsite:port/ -k poclbm DEVICE=0 VECTORS AGGRESSION=5 FASTLOOP BFI_INT WORKSIZE=64
Tips: you wan't to disable shadows as much as possible, they take the lots of gpu power for such a tiny gaming experience. Also using lesser directx version might have a huge impact.

AGGRESSION from 7 onwards gain 99%gpu and ~1Mhash/s per step up to 10, then it becomes so slow to update it's own hash rate and something else so don't know... got it showing up to 330Mhash/s with 840core 759memory.

WORKSIZE=64 or 128 doesn't seem to do anything at all so I chose the lesser number, 256 is very bad thou, drops Mhash/s to ~270.
What does this actually do anyway?

This is giving me 12% more hash power than poclbm.

Just a tip: FASTLOOP is bad above ~AGGRESSION=8. At higher speeds it won't significantly improve performance and it causes the slow hashrate display updating.

Also, it's good to see that BFI_INT improves performance and works correctly on a 69xx card.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: [Tycho] on April 26, 2011, 12:30:27 AM
What's interesting is RPCProtocol doesn't use any Python HTTP libraries, it's all done through Twisted;
so while it could be a problem in Twisted, I don't think the linked bug is the answer.

The lack of TCP_NODELAY is interesting. Doesn't that only disable Nagle's algorithm, which affects sends?
How would it delay received data?
Please, read this:
http://code.google.com/p/httplib2/issues/detail?id=28
http://code.google.com/p/httplib2/issues/detail?id=91

Quote
During some tests I made, I measured some very long delays in replies to HTTP POST using httplib2.
It turns out the delays are caused by Nagle algorithm, and that performance can be greatly improved by setting TCPNODELAY, which disables Nagle's algorithm.
Quote
Nagle vs delayed ack issues have been around for a while. The correct way to fix this is NOT to set TCPNODELAY but to fix httplib2 to issue the header and body as a combined write. This way small commands are issued in a single packet as the gods of TCP intended. Large commands are sent in multiple packets right away as Nagle doesn't apply in that case.

The TCPNODELAY fix is a workaround, but it results in inefficient bandwidth use.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: OVerLoRDI on April 26, 2011, 12:43:28 AM
Got it working properly with my 6970s.  My cards are oc'd to 970mhz with watercooling.  I went from ~375Mhash/s to 405-410Mhash/s.

This sir is epic.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: drgr33n on April 26, 2011, 02:10:45 AM
NNNIIIIICCCEEEE :D

Debian sid
Catalyst v11.3
ATI APP SDK v2.4
xfx 5830 overclocked
core=900MHz mem=900MHz

poclbm -v -w 128 -f0  = 245000kh/s GPU 75 C @ 95% load

phoenix -k poclbm device=0 WORKSIZE=128  AGGRESSION=12  BFI_INT VECTORS = 265000kh/s GPU 68.50 C @ 99% load

that's a 20000kh/s gain and a drop in temp !!!!  As soon as I get my next bitcoins I shall be donating to you sir :D

EDIT:

With the trunk version 267Mh/s :D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: samsarulz on April 26, 2011, 02:29:03 AM
I solved my problem, by simply shutting down utorrent and the windows firewall.

Now Running at 373 Mhash with 880/310 OC on my 6950@6970

Thanks!

See ya!

ps: works fine with deepbit


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 26, 2011, 03:19:35 AM
Version 1.2 has been released.

This version fixes several bugs and improves performance.

Changes:
1. Fixed unhandled exceptions during kernel compilation
2. Fixed hashrate displaying a nonzero value when the miner is idle
3. Code cleanup to remove some unused imports.
4. Minor kernel tweak - possible 1-2 Mhash/sec gain
5. Fixed endianness of hash in accepted/rejected messages


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 26, 2011, 03:28:19 AM
wow..nice! performance is up to 350 Mhash/sec for me  (5970 at 850 Mhz 300 MHz mem)



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Miner-TE on April 26, 2011, 03:31:04 AM
Ditto's ....  5780 @ 970/300.  went from ~350 Mh/s to 400-410.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Garrett Burgwardt on April 26, 2011, 03:39:58 AM
Must be doing something wrong - 6990 gets worse performance here than with poclbm, high aggression, BFI_INT, everything setup as it should be I think. 11.4 drivers, stream 2.4, 7 x64 Ultimate. Any suggestions?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 26, 2011, 03:55:35 AM
Must be doing something wrong - 6990 gets worse performance here than with poclbm, high aggression, BFI_INT, everything setup as it should be I think. 11.4 drivers, stream 2.4, 7 x64 Ultimate. Any suggestions?

EDIT: My bad, didn't notice you already tried higher aggression.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Garrett Burgwardt on April 26, 2011, 03:58:27 AM
Must be doing something wrong - 6990 gets worse performance here than with poclbm, high aggression, BFI_INT, everything setup as it should be I think. 11.4 drivers, stream 2.4, 7 x64 Ultimate. Any suggestions?

For reference, here is my argument I'm passing:

START /DC:\Users\Garrett\Desktop\miner2 phoenix.exe -u http://redacted@mining.bitcoin.cz:8332/ -k poclbm PLATFORM=0 DEVICE=0 VECTORS AGGRESSION=10 -v BFI_INT WORKLOAD=128
START /DC:\Users\Garrett\Desktop\miner2 phoenix.exe -u http://redacted@mining.bitcoin.cz:8332/ -k poclbm PLATFORM=0 DEVICE=1 VECTORS AGGRESSION=10 -v BFI_INT WORKLOAD=128


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 26, 2011, 04:11:21 AM
Must be doing something wrong - 6990 gets worse performance here than with poclbm, high aggression, BFI_INT, everything setup as it should be I think. 11.4 drivers, stream 2.4, 7 x64 Ultimate. Any suggestions?

For reference, here is my argument I'm passing:

START /DC:\Users\Garrett\Desktop\miner2 phoenix.exe -u http://redacted@mining.bitcoin.cz:8332/ -k poclbm PLATFORM=0 DEVICE=0 VECTORS AGGRESSION=10 -v BFI_INT WORKLOAD=128
START /DC:\Users\Garrett\Desktop\miner2 phoenix.exe -u http://redacted@mining.bitcoin.cz:8332/ -k poclbm PLATFORM=0 DEVICE=1 VECTORS AGGRESSION=10 -v BFI_INT WORKLOAD=128

It's WORKSIZE= not WORKLOAD=


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Garrett Burgwardt on April 26, 2011, 04:13:03 AM
Ah, that did it! Thanks!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: samsarulz on April 26, 2011, 04:19:43 AM
try adding "fastloop" y play with this and the aggressive function.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: travex on April 26, 2011, 04:42:47 AM
Version 1.2 with Long pool supported, thx mate, great work so far :P


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: eleuthria on April 26, 2011, 04:44:56 AM
Another amazing release, went from 421-422 mHash/sec to 423-424 mHash/sec on my 5870s (Aggression 13, Vectors, 128 Worksize, BFI_INT, using 975/300 @ 0.950v).

Just a suggestion, update your original post with the changelog/updates so we can find out what's new without searching through the various replies within the thread.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 26, 2011, 05:37:01 AM
It seems to commonly reject the the generation immediately after a LP new block is that normal?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 26, 2011, 05:40:27 AM
It seems to commonly reject the the generation immediately after a LP new block is that normal?

Hmm, that's odd. This is not happening for me. I've also noticed that 1.2 produces far fewer rejected results - the ratio of accepted to rejected is much lower now.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 26, 2011, 05:42:22 AM
It seems to commonly reject the the generation immediately after a LP new block is that normal?

Hmm, that's odd. This is not happening for me. I've also noticed that 1.2 produces far fewer rejected results - the ratio of accepted to rejected is much lower now.



I guess it could just be a coincidence but literally every one of my rejected ones came immediately following a LP new block.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 26, 2011, 05:45:18 AM
It seems to commonly reject the the generation immediately after a LP new block is that normal?

Hmm, that's odd. This is not happening for me. I've also noticed that 1.2 produces far fewer rejected results - the ratio of accepted to rejected is much lower now.



I guess it could just be a coincidence but literally every one of my rejected ones came immediately following a LP new block.

Can you post some screenshots maybe? Also what arguments are you passing to the miner? paste them here...perhaps there is something wrong with usage?



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: luffy on April 26, 2011, 05:49:53 AM
great software! for sure the guys worth a donation :)
keep up the good work!
now the net force is reaching 1Th/s!!!!!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 26, 2011, 05:56:03 AM
http://img824.imageshack.us/img824/1774/screenshot20110426at151.png



I actually looked again and there was 1 that wasn't immediately following the LP but still only one.  Sorry had to do it in RDP.

here is my batch script start
/DC:\bitcoin\phoenix phoenix.exe -u http://xxxx:xxxx@www.bitcoinpool.com:8334/  DEVICE=1 BFI_INT  AGGRESSION=12 -k poclbm


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 26, 2011, 06:03:05 AM
http://img824.imageshack.us/img824/1774/screenshot20110426at151.png



I actually looked again and there was 1 that wasn't immediately following the LP but still only one.  Sorry had to do it in RDP.

here is my batch script start
/DC:\bitcoin\phoenix phoenix.exe -u http://xxxx:xxxx@www.bitcoinpool.com:8334/  DEVICE=1 BFI_INT  AGGRESSION=12 -k poclbm

That is odd indeed. Perhaps this is a bug with LP support. I'm wish slush's pool and I just remembered that he doesn't use LP so I never noticed this issue. Sorry for the misinformation. When I replied to your post the first time I forgot about slush's lack of LP support.

I'm curious why you haven't enabled the VECTORS variable? Does that setting slow mining down?

Also what card are you running and at what speed? Overclocked?

I think this may be an issue with LP support and not something hardware/configuration related.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: demonofelru on April 26, 2011, 06:34:08 AM
Yeah vectors seemed to slow my hashes down on a 6950 with shaders unlocked vcore 1.15 core 935 mem 500


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: alexmat on April 26, 2011, 07:04:11 AM
poclbm: 5870 @ 900/900 => 344Mh/s
phoenix: 5870 @ 900/300 => 375Mh/s

Very nice  8)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: OUTSIDE on April 26, 2011, 07:05:34 AM
Incredible!

My 5850's does now 325-330MH/s (before 295-300) and the 6970 does now 420-425MH/s!!! (before 380)

Thx for all!

ByE!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jkminkov on April 26, 2011, 07:09:11 AM
Im getting a ton of "work queue empty, minder is idle" messages

im on a 5970 flags are -k poclbm DEVICE=0 VECTORS AGGRESSION=14 BFI_INT



VECTORS AGGRESSION=10 -v FASTLOOP BFI_INT WORKSIZE=128

idle messages gone when I dropped AGGRESSION to 10


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: martok on April 26, 2011, 07:42:47 AM
Hi,

Any way to track the source (git/svn)?

Also, quick feature request. Could you add a feature similar to poclbm --rate 30. So rather than displaying a screen progress, every 30 seconds it timestamps a progress message. That way I can do phoenix.py > logfile and get something sensible.

Excellent software btw.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: anatolikostis on April 26, 2011, 07:46:54 AM
Incredible!

My 5850's does now 325-330MH/s (before 295-300) and the 6970 does now 420-425MH/s!!! (before 380)
syntax - "vectors=on" or just "vectors"?
overclock - @850/1100 or higher?
 


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 26, 2011, 07:50:51 AM
syntax - "vectors=on" or just "vectors"?

I made the options parser very lenient on syntax. Take your pick of any of the following:

VECTORS=on
VECTORS=true
VECTORS=yes
VECTORS=t
VECTORS=y
VECTORS
VeCtORs=TRuE

...anything else will disable it. Same goes for BFI_INT.

Any way to track the source (git/svn)?
There's SVN here (http://svn3.xp-dev.com/svn/phoenix-miner/trunk/), but we might occasionally commit untested and horribly broken things there, so use it at your own risk.

Also, quick feature request. Could you add a feature similar to poclbm --rate 30. So rather than displaying a screen progress, every 30 seconds it timestamps a progress message. That way I can do phoenix.py > logfile and get something sensible.
I like the idea; how about if we added an option to log to a file directly from Phoenix? (And logging to - disables console output and logs directly to stdout instead.)
Something like: phoenix.py -l mining.log
Not sure what the best way to specify the rate is, though.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tiberiandusk on April 26, 2011, 08:29:18 AM
went from 334 Mhash/s to 388 Mhash/s. Overclocked some more and I'm getting 409 Mhash/s with mem at 300 and core at 975 on my 5870. temp is 76-77c with fan at 75%.  This is fantastic! Great work!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on April 26, 2011, 08:29:40 AM

I like the idea; how about if we added an option to log to a file directly from Phoenix? (And logging to - disables console output and logs directly to stdout instead.)
Something like: phoenix.py -l mining.log
Not sure what the best way to specify the rate is, though.

Hi I think logging to file is a great Idea. Monitoring it from the web would be a breeze!!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 26, 2011, 09:21:30 AM
Hi I think logging to file is a great Idea. Monitoring it from the web would be a breeze!!

There's also Multiminer, which jedi95 and I use for our cluster's status page (http://129.82.65.171:8882/).
Multiminer's already quite usable and Phoenix already has builtin support for it; all you would have to do is download and
set up Multiminer, connect your Phoenix clients to it with an mmp:// URL, and write a .rpy script that would display info
on your miners. (I'd release ours, but the code is in desperate need of cleanup, and I'd have to okay it with jedi95 first.)

I'll post clearer instructions on how to do that when I fully test and release Multiminer 1.4, which has support for long polling.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Kick on April 26, 2011, 10:49:43 AM
Can't seem to get this to work. When i extract the zip i get a folder and phoenix.exe

when i tried running the exe, the cmd window goes up then disappears.

I tried xp sp2 and vista sp2 compatibility mode

ran as admin

im on win7 x64

11.4 preview catalyst.

6950 unlocked and 5870 on the rig.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: commlinx on April 26, 2011, 11:03:37 AM
when i tried running the exe, the cmd window goes up then disappears.
You'll need command line parameters, for example I have a file start_phoenix.cmd that contains the following:

phoenix -u http://username.minername:mypass@mining.bitcoin.cz:8332/;askrate=10 -k poclbm DEVICE=0 VECTORS AGGRESSION=7 FASTLOOP BFI_INT

Check the first page for the parameters, I've of course changed my password etc. For a dual setup you'll also want a 2nd file with DEVICE=1 to start on the 2nd GPU. If the above fails you can also add a line containing pause at the end so you can see what the error is before the window disappers.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: xxToaDxx on April 26, 2011, 11:55:54 AM
what version is needed SDK?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 26, 2011, 12:33:45 PM
Can't seem to get this to work. When i extract the zip i get a folder and phoenix.exe

when i tried running the exe, the cmd window goes up then disappears.

I tried xp sp2 and vista sp2 compatibility mode

ran as admin

im on win7 x64

11.4 preview catalyst.

6950 unlocked and 5870 on the rig.

It's not a graphical application ... you need to open a command prompt and run it that way.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: keybaud on April 26, 2011, 12:44:41 PM
Can't seem to get this to work. When i extract the zip i get a folder and phoenix.exe

when i tried running the exe, the cmd window goes up then disappears.

I tried xp sp2 and vista sp2 compatibility mode

ran as admin

im on win7 x64

11.4 preview catalyst.

6950 unlocked and 5870 on the rig.

It's not a graphical application ... you need to open a command prompt and run it that way.

or just create  Miner.bat as a text file in the same folder.

Type or paste the following, editing everything within "" to your values.

phoenix -u http://"user":"password"@"pool":"port"/ -k poclbm DEVICE=0 VECTORS AGGRESSION=7 -v FASTLOOP BFI_INT

Double click the Miner.bat file to run or create a Windows short-cut and stick it wherever you want to run it from.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Grinder on April 26, 2011, 01:42:10 PM
Or create a shortcut to phoenix.exe and edit it to add the parameters.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: proudhon on April 26, 2011, 01:45:56 PM
HIS 6990 @ 850MHz
Windows 7x64
poclbm-gui = 615Mhash/s
phoenix = 666Mhash/s

I'm using the following:

phoenix -v -u http://username@internet.com:password@deepbit.net:8332/ -k poclbm device=1 worksize=128 vectors aggression=10 bfi_int

That's a nice ~8% increase.  The only bummer is that I still get 100% CPU usage.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 26, 2011, 01:47:33 PM
HIS 6990 @ 850MHz
Windows 7x64
poclbm-gui = 615Mhash/s
phoenix = 666Mhash/s

I'm using the following:

phoenix -v -u http://username@internet.com:password@deepbit.net:8332/ -k poclbm device=1 worksize=128 vectors aggression=10 bfi_int

That's a nice ~8% increase.  The only bummer is that I still get 100% CPU usage.



I get that too with a 5970 too. What's up with that? I'm surprised nobody has found a fix for this.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: proudhon on April 26, 2011, 01:54:20 PM
HIS 6990 @ 850MHz
Windows 7x64
poclbm-gui = 615Mhash/s
phoenix = 666Mhash/s

I'm using the following:

phoenix -v -u http://username@internet.com:password@deepbit.net:8332/ -k poclbm device=1 worksize=128 vectors aggression=10 bfi_int

That's a nice ~8% increase.  The only bummer is that I still get 100% CPU usage.



I forgot to mention that I'm using Catalyst 11.4 and SDK 2.4.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 26, 2011, 01:57:18 PM
11.3 with SDK 2.3 ..same problem


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Timon2010 on April 26, 2011, 02:02:19 PM
Incredible!

My 5850's does now 325-330MH/s (before 295-300) and the 6970 does now 420-425MH/s!!! (before 380)

Thx for all!

ByE!

Hi Outside!

Regarding Phoenix miner:
I also have a HD6970 so I am interested in what arguments you do put in command line for it.
What GPUclock and MEMclock are you using? And you using Windows/Linux?
Thanks!

Regards,
Timon


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: ghost on April 26, 2011, 02:07:02 PM
I'm getting "Failed to connect, retrying..." errors. I have python-twisted installed and my network connection is fine. Any ideas?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: samsarulz on April 26, 2011, 02:08:51 PM
Now with Phoenix 1.2 I´m having 352 Mhash/s with 800/310 (stock with low mem freq), But if I go wild with a 880/310 OC, I don´t see a big difference, because i get only 372 Mhash/s.

Is thsi normal ? Thanks

By the way I´m running a HD 6950 2gb @1536sp


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 26, 2011, 02:10:38 PM
Bump your mem clock - that is likely too low for a 6950...

My 6950 at 935/700 is at 400Mh/s


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: clonedone on April 26, 2011, 02:38:30 PM
HIS 6990 @ 850MHz
Windows 7x64
poclbm-gui = 615Mhash/s
phoenix = 666Mhash/s

I'm using the following:

phoenix -v -u http://username@internet.com:password@deepbit.net:8332/ -k poclbm device=1 worksize=128 vectors aggression=10 bfi_int

That's a nice ~8% increase.  The only bummer is that I still get 100% CPU usage.



I have a rig with 3 6990's do i still use this for each one?
or should I change the workload since it has three video cards?
Honestly im not sure how workload works =/


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: ghost on April 26, 2011, 02:39:18 PM
I'm getting "Failed to connect, retrying..." errors. I have python-twisted installed and my network connection is fine. Any ideas?

Turns out this was only happening with slushs pool, I switched to deepbit and it is working fine.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: proudhon on April 26, 2011, 02:55:48 PM
HIS 6990 @ 850MHz
Windows 7x64
poclbm-gui = 615Mhash/s
phoenix = 666Mhash/s

I'm using the following:

phoenix -v -u http://username@internet.com:password@deepbit.net:8332/ -k poclbm device=1 worksize=128 vectors aggression=10 bfi_int

That's a nice ~8% increase.  The only bummer is that I still get 100% CPU usage.



I have a rig with 3 6990's do i still use this for each one?
or should I change the workload since it has three video cards?
Honestly im not sure how workload works =/

I'm not sure.  I only have a single 6990.  For me, I have to run two command prompts with 'device=0' in the first and 'device=1' in the second.  You might need to use 'platform' in your command line, but I'm not sure about that.  I'm thinking you'd need 6 command prompts where the first two would look like this:

phoenix -v -u http://username@internet.com:password@deepbit.net:8332/ -k poclbm platform=0 device=0 worksize=128 vectors aggression=10 bfi_int

phoenix -v -u http://username@internet.com:password@deepbit.net:8332/ -k poclbm platform=0 device=1 worksize=128 vectors aggression=10 bfi_int

The next pair would use 'platform=1' and then the next pair would use 'platform=2'.  Hopefully somebody can confirm this or correct it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Timon2010 on April 26, 2011, 03:03:28 PM
Bump your mem clock - that is likely too low for a 6950...

My 6950 at 935/700 is at 400Mh/s


I have 6970, using Win 7 64, and with 935/900 Mhz I only get ~353 Mhash/s with this command line: -k poclbm DEVICE=0 AGGRESSION=7 -v FASTLOOP BFI_INT
Highest rate I've seen is 362 Mhash/s.

Confusing, does OS and/or server location affect the hashrate?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: OUTSIDE on April 26, 2011, 03:24:44 PM
Incredible!

My 5850's does now 325-330MH/s (before 295-300) and the 6970 does now 420-425MH/s!!! (before 380)

Thx for all!

ByE!

Hi Outside!

Regarding Phoenix miner:
I also have a HD6970 so I am interested in what arguments you do put in command line for it.
What GPUclock and MEMclock are you using? And you using Windows/Linux?
Thanks!

Regards,
Timon


If I not remember wrong...

phoenix -v -u http://username@internet.com:password@deepbit.net:8332/ -k poclbm device=0 worksize=128 (or 64) vectors aggression=10 (or 12) bfi_int

And I get 420MH/s aprox

Clocks: 1000/340

I will try later higher mem clocks... with poclbm lower is better, but I don't know which is better with phoenix

ByE!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Timon2010 on April 26, 2011, 03:53:19 PM
Thanks, after some tweaking I am getting some higher rate, upto 380.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: eleuthria on April 26, 2011, 04:21:46 PM
I'm getting "Failed to connect, retrying..." errors. I have python-twisted installed and my network connection is fine. Any ideas?

Turns out this was only happening with slushs pool, I switched to deepbit and it is working fine.

I'm actually having the same problem on one of my rigs.  For some reason it will not connect to slush's pool (tried multiple login credentials), but will connect to bitcoinpool and deepbit just fine.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 26, 2011, 04:32:09 PM
I'm getting "Failed to connect, retrying..." errors. I have python-twisted installed and my network connection is fine. Any ideas?

Turns out this was only happening with slushs pool, I switched to deepbit and it is working fine.

I'm actually having the same problem on one of my rigs.  For some reason it will not connect to slush's pool (tried multiple login credentials), but will connect to bitcoinpool and deepbit just fine.

I just tested with:

phoenix.py -u http://jedi95.worker:password@mining.bitcoin.cz:8332 -k poclbm FASTLOOP VECTORS BFI_INT PLATFORM=1 DEVICE=0 AGGRESSION=8

It works fine for me. What command line are you using?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: ghost on April 26, 2011, 04:37:26 PM
I'm getting "Failed to connect, retrying..." errors. I have python-twisted installed and my network connection is fine. Any ideas?

Turns out this was only happening with slushs pool, I switched to deepbit and it is working fine.

I'm actually having the same problem on one of my rigs.  For some reason it will not connect to slush's pool (tried multiple login credentials), but will connect to bitcoinpool and deepbit just fine.

What's odd is I have two identical computers. One will connect to slushes just fine, the other won't. I've tried using different workers and even creating a new worker on slushes website.

Here is the command I am running:
phoenix.py -u http://username.worker:password@mining.bitcoin.cz:8332 -k poclbm DEVICE=0 VECTORS=on AGGRESSION=10 WORKSIZE=64 FASTLOOP BFI_INT


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 26, 2011, 04:42:50 PM
That's a nice ~8% increase.  The only bummer is that I still get 100% CPU usage.

ATI's implementation of OpenCL (but not nVidia's if I recall...) on Windows likes to use the CPU a lot,
for some reason. This is not a problem with any miner. You'll probably see 100% CPU use on any OpenCL app
you try to run on that card.

The next pair would use 'platform=1' and then the next pair would use 'platform=2'.  Hopefully somebody can confirm this or correct it.

Speaking of ATI's implementation vs. nVidia's implementation, that's how you switch between them.
If you have multiple "platforms" installed, (which usually only happens when you have both nVidia and ATI cards in the same system),
Phoenix will require you to tell it which platform you want to use.
If it's not yelling at you to select a platform, you can get away with not setting it. To Phoenix (and the rest of the OS in general), a 5970
is no different from putting two 5870s in your system, so if you were to run a dual-5970 rig, you would address all 4 GPUs with DEVICE=0...3

Confusing, does OS and/or server location affect the hashrate?
I'm not sure what you mean about "server location" - where on the mining rig you extracted Phoenix? No, there's no reason that would affect hashrate.
Or did you mean the distance between your mining rig and the pool server? That shouldn't affect hashrate either, since Phoenix queues work.
OS does affect hashrate. It seems ATI Stream runs faster on Linux than elsewhere.

I just tested with:

phoenix.py -u http://jedi95.worker:password@mining.bitcoin.cz:8332 -k poclbm FASTLOOP VECTORS BFI_INT PLATFORM=1 DEVICE=0 AGGRESSION=8

It works fine for me. What command line are you using?

Don't forget to include an askrate if you're on any [RPC] server! (You are fine excluding it on [MMP] and [RPC (+LP)] servers)

Something to note about how Phoenix parses URLs: You must include the trailing / if you want to use an askrate.
Why?
Phoenix sees http://mining.bitcoin.cz:8332;askrate=10 as this:
Hostname: mining.bitcoin.cz
Port: 8332;askrate=10
Path: NONE
Parameters: NONE
Will have problems loading the page.

Phoenix sees http://mining.bitcoin.cz:8332/;askrate=10 as this:
Hostname: mining.bitcoin.cz
Port: 8332
Path: /
Parameters: ;askrate=10
Will work correctly.

This is a problem with how urlparse parses the URL internally and I'm thinking of a way to better handle this now.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Cryptoman on April 26, 2011, 04:59:48 PM
I'm having some problems getting phoenix to run under OpenSUSE 11.3.  First I got this error:

Code:
ImportError: cannot import name IBodyProducer

It turns out that the version of twisted in the OpenSUSE repository is only 8.2.  ::)  Installing twisted 11.0 fixes that problem.  However, now I get:

Code:
[26/04/2011 12:36:06] FATAL kernel error: Failed to load OpenCL kernel!

I've been running poclbm for months, so I obviously have OpenCL.  Do I need a symlink?

Here's my command line:

Code:
./phoenix.py -u http://user:pass@127.0.0.1:8332 -k poclbm DEVICE=0 VECTORS AGGRESSION=7 FASTLOOP BFI_INT WORKSIZE=64

[EDIT] Solved.  I was using the wrong device number.  DEVICE=0 refers to the CPU.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: mjsbuddha on April 26, 2011, 05:14:35 PM
has anyone figure out how to connect this to deepbit? -u http://address@site.com.minername:password@deepbit.net:8332 doesnt work because it thinks my login is address@site and my miner is com.minername.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: proudhon on April 26, 2011, 05:31:38 PM
has anyone figure out how to connect this to deepbit? -u http://address@site.com.minername:password@deepbit.net:8332 doesnt work because it thinks my login is address@site and my miner is com.minername.

You need to use this:

http://address@site.com:password@deepbit.net:8332


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: mjsbuddha on April 26, 2011, 05:41:52 PM
has anyone figure out how to connect this to deepbit? -u http://address@site.com.minername:password@deepbit.net:8332 doesnt work because it thinks my login is address@site and my miner is com.minername.

You need to use this:

http://address@site.com:password@deepbit.net:8332

yeah i know that works but you cant specify a miner that way. there's no way to connect and specify a miner? I have 8 GPU's and I'd like to know which is doing what.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: eleuthria on April 26, 2011, 06:04:30 PM
For deepbit, use the email address with the underscore for the worker (so:  email_address@blah.com_1, _2, _3, etc).  There is no '.miner' required on deepbit.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: mjsbuddha on April 26, 2011, 06:19:06 PM
For deepbit, use the email address with the underscore for the worker (so:  email_address@blah.com_1, _2, _3, etc).  There is no '.miner' required on deepbit.
ah. perfect. thanks


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: sniper_sniperson on April 26, 2011, 08:42:05 PM
What's exactly doing PLATFORM=ID option?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 26, 2011, 09:45:53 PM
What's exactly doing PLATFORM=ID option?

Short answer:
The PLATFORMS=ID switch is to specify which platform ID on your system you want to use.
It's only important if you have multiple OpenCL devices in your system, from different vendors (mixing AMD/ATI and
nVidia cards in one system, for example.)
If you only have one platform on your system, you don't have to specify it. If you have multiple platforms,
Phoenix will tell you that it is needed. So, don't worry about it. :)

Long answer:
OpenCL is a standard developed by Khronos.
The "core" of OpenCL was not created by AMD/ATI nor nVidia, although they probably contribute to its development.
The problem is that, even though OpenCL is common, AMD/ATI and nVidia have different ideas about how to go about
bridging the gap between OpenCL and GPU. AMD/ATI gets from OpenCL to raw GPU code in a different way from how
nVidia does it, which makes nVidia's version of OpenCL totally incompatible with AMD/ATI cards and vice versa.

This can cause a serious problem when there is a system with some nVidia and some AMD/ATI cards in it: One vendor's
version of OpenCL will not work with another vendor's card, so Khronos needed a way of making sure independent
versions could exist on the same system. Their solution was to use an "installable client driver" (ICD) for each vendor.
So, when you install both AMD/ATI's OpenCL and nVidia's OpenCL, they exist as separate "platforms." One accesses
the AMD/ATI cards, the other accesses the nVidia cards.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: foxmulder on April 26, 2011, 09:59:53 PM
Great miner, donated   :).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 26, 2011, 10:37:05 PM
Seeing many more rejected shares than with poclbm - averaging around 2% over the past 24 hours.  This is on a 5970, 6950 and 5770 (a good mix of hardware).

One thing I found is 2 (and up to 4) consecutive rejected shares.  It seems this happens within about a 10-15 second time frame.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: travex on April 26, 2011, 10:38:11 PM
I've just realized that with phoenix miner, I dont even have to turn my bitcoin client on ! Lol ?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 26, 2011, 10:46:19 PM
Seeing many more rejected shares than with poclbm - averaging around 2% over the past 24 hours.  This is on a 5970, 6950 and 5770 (a good mix of hardware).

One thing I found is 2 (and up to 4) consecutive rejected shares.  It seems this happens within about a 10-15 second time frame.

Poclbm clears its result queue when work is received from a new block. Phoenix uses Twisted to send results asynchronously, which makes this difficult. No computation time is wasted, it's just that Phoenix doesn't cancel sending already found nonces like poclbm.

This is something we will fix if we can find a good solution to it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: marcus_of_augustus on April 26, 2011, 10:56:40 PM

Good work on the miner guys ... donation coming your way.

PS: I don't know to love you or hate you for single-handedly making the network hashrate 10-15% bigger.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on April 26, 2011, 11:10:33 PM
using  -v -u http://pooluser@miner:pass@btcmine.com:8332 -k poclbm device=0 WORKSIZE=128 VECTORS AGGRESSION=8 FASTLOOP BFI_INT

HD6870 from 238 to 271!
HD6850 from 211 to 233!

Excelent job! interface lags like hell... but i can hadle it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: zzzd on April 26, 2011, 11:17:37 PM
are rejected the same as stale shares?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Raulo on April 26, 2011, 11:20:47 PM
are rejected the same as stale shares?

Rejected shares are either stale or invalid. But unless you have broken hardware (or overclocked too much) or buggy software which would result in invalid solutions, rejected ones are stale.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BitLex on April 26, 2011, 11:42:57 PM
i get this message everytime i start phoenix on ubuntu:
Code:
/home/noodles/phoenix-1.2/KernelInterface.py:139: DeprecationWarning: struct integer overflow masking is deprecated
  hashInput = pack('>76sI', staticData, nonce)
/home/noodles/phoenix-1.2/KernelInterface.py:148: DeprecationWarning: struct integer overflow masking is deprecated
  formattedResult = pack('<76sI', range.unit.data[:76], nonce)
it just spits out that warning and starts to work anyway,

but from time to time, a miner just stops after work queue is empty, like it did about 1hour ago:
Code:
[27/04/2011 00:20:39] Result: 83228c5b accepted             
[27/04/2011 00:20:39] Warning: work queue empty, miner is idle
and i have to restart it (and again get the warning shown above)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: ghost on April 27, 2011, 12:00:54 AM
The problems I was having with slushes pool have gone away and it will now connect. I noticed this was happening with other miners as well so I don't think this was ever anything specific to Phoenix.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 27, 2011, 01:08:38 AM
I've just realized that with phoenix miner, I dont even have to turn my bitcoin client on ! Lol ?

To mine in a pool? You shouldn't have to turn your Bitcoin client on at all unless you're mining solo.
The pool just benefits from your contributed computing power and pays you a % cut. You don't have
to leave Bitcoin up to receive the payments either.


Good work on the miner guys ... donation coming your way.

PS: I don't know to love you or hate you for single-handedly making the network hashrate 10-15% bigger.


Thanks! And don't worry, I think I hate us too. :D

are rejected the same as stale shares?

Rejected shares are either stale or invalid. But unless you have broken hardware (or overclocked too much) or buggy software which would result in invalid solutions, rejected ones are stale.

"Rejected" can be any number of things, it just means the system you were mining for (a pool server
or your Bitcoin client) rejected the work. A Bitcoin client will reject only on invalid or stale, but a pool
could reject for other reasons (duplicate work, account setting errors, internal server problem, etc.)

However, since invalid work is prevented by a double-check in Phoenix (even with unstable hardware),
and duplicate work won't occur unless the kernel has bugs that would cause that, they're usually
going to be stale... unless there are bugs.

So, pretty much the wordy version of what Raulo just said. ;D

i get this message everytime i start phoenix on ubuntu:
Code:
/home/noodles/phoenix-1.2/KernelInterface.py:139: DeprecationWarning: struct integer overflow masking is deprecated
  hashInput = pack('>76sI', staticData, nonce)
/home/noodles/phoenix-1.2/KernelInterface.py:148: DeprecationWarning: struct integer overflow masking is deprecated
  formattedResult = pack('<76sI', range.unit.data[:76], nonce)
it just spits out that warning and starts to work anyway,

but from time to time, a miner just stops after work queue is empty, like it did about 1hour ago:
Code:
[27/04/2011 00:20:39] Result: 83228c5b accepted             
[27/04/2011 00:20:39] Warning: work queue empty, miner is idle
and i have to restart it (and again get the warning shown above)

Now that's an interesting error! I'm guessing this is Python 2.7? We haven't done any testing on 2.7 yet.
A little Googling should tell me what's going on with the DeprecationWarnings; it's nothing serious, but apparently
we're doing something in there that the Python team prefers we not do in the future, so we'll fix that in 1.3.

As for the work queue stalling, which should be totally unrelated to the warnings...
What's your aggression set at? Sometimes the aggression is so high that it runs the queue clean out of work on
every loop. We're working on this, but for now you can use -q 2 or -q 3 to increase the size of the queue so that
doesn't happen in the future.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BitLex on April 27, 2011, 02:17:59 AM
What's your aggression set at?
aggression is set to 8,
didn't stop since, i'll try to set it lower or set the -q if it does again.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Noitev on April 27, 2011, 06:31:14 AM
itd be cool if this miner showed what difficulty ech potential hash > or = to 1 would solve. so like "347 diff not met/ not sent, 2 diff not met/ not sent etc.. be more interesting to see how close each potential hash is... lol


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 27, 2011, 07:01:21 AM
itd be cool if this miner showed what difficulty ech potential hash > or = to 1 would solve. so like "347 diff not met/ not sent, 2 diff not met/ not sent etc.. be more interesting to see how close each potential hash is... lol

Neat idea, but it's probably not practical enough to add to the main code. Being open-source software, you're free to modify it to add that feature yourself, but I don't think it would help enough people to make it worthwhile.

If you're curious anyway: the displayed hex when submitting shares is actually the fifth, sixth, seventh, and eighth bytes of the share hashes. You can calculate the difficulty from that by dividing 4294967040 by the hex displayed.

For example, 3351e8c0 becomes 861006016; 4294967040/861006016 = 4.988 difficulty.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shackleford on April 27, 2011, 07:27:21 AM
As for the work queue stalling, which should be totally unrelated to the warnings...
What's your aggression set at? Sometimes the aggression is so high that it runs the queue clean out of work on
every loop. We're working on this, but for now you can use -q 2 or -q 3 to increase the size of the queue so that
doesn't happen in the future.

I receive the miner is idle message as well. I get it when going from anything above Aggression 13 (about 408Mh for me). I know people are saying that anything above 10 was unnecessary but what I was seeing was a bump in hash every time I raised it to the point where the dos window would not update the hash rate. In my mind just because it doesn't say it's hashing higher does not mean it isn't. -q 2 or 3 made no difference in the idle messages.

Great work, just the other day I was trying to push my card and this miner takes me further than I thought possible while being stable.
Tipped


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: pizzaman on April 27, 2011, 08:28:57 AM
Started today with a 5970 XFX Black Edition, stock firmware, oc 805/1200. I'm not completely sure about all the settings and oc yet and these are my results.

Running solo two parallel phoenixes with :
Code:
phoenix.exe -u http://xxxx:xxxx@localhost:8332 PLATFORM=0 DEVICE=0 -k poclbm VECTORS WORKSIZE=128 BFI_INT AGGRESSION=10 -v
phoenix.exe -u http://xxxx:xxxx@localhost:8332 PLATFORM=0 DEVICE=1 -k poclbm VECTORS WORKSIZE=128 BFI_INT AGGRESSION=10 -v
guiminer 290x2~580Mh/s  with -v -d 0 -f 1 -w128
phoenix 330x2~660Mh/s  at 90degC
Is this normal?:
Code:
[27/04/2011 18:18:36] Result didn't meet full difficulty, not sending
[27/04/2011 18:18:47] Result didn't meet full difficulty, not sending
[27/04/2011 18:18:48] Server gave new work; passing to WorkQueue
[27/04/2011 18:18:59] Result didn't meet full difficulty, not sending
[27/04/2011 18:19:01] Server gave new work; passing to WorkQueue
.
.
.
[27/04/2011 18:20:24] Result didn't meet full difficulty, not sending
[27/04/2011 18:20:31] Result didn't meet full difficulty, not sending
[27/04/2011 18:20:33] Server gave new work; passing to WorkQueue

A bit puzzled about all those not sending warnings.
[27/04/2011 18:20:44] Result didn't meet full difficulty, not sending
[27/04/2011 18:20:47] Server gave new work; passing to WorkQueue
[331.20 Mhash/sec] [0 Accepted] [0 Rejected] [RPC]


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 27, 2011, 08:34:05 AM
Started today with a 5970 XFX Black Edition, stock firmware, oc 805/1200. I'm not completely sure about all the settings and oc yet and these are my results.

Running solo two parallel phoenixes with :
Code:
phoenix.exe -u http://xxxx:xxxx@localhost:8332 PLATFORM=0 DEVICE=0 -k poclbm VECTORS WORKSIZE=128 BFI_INT AGGRESSION=10 -v
phoenix.exe -u http://xxxx:xxxx@localhost:8332 PLATFORM=0 DEVICE=1 -k poclbm VECTORS WORKSIZE=128 BFI_INT AGGRESSION=10 -v
guiminer ~580Mh/s
phoenix ~590Mh/s
Is this normal?:
Code:
[27/04/2011 18:18:36] Result didn't meet full difficulty, not sending
[27/04/2011 18:18:47] Result didn't meet full difficulty, not sending
[27/04/2011 18:18:48] Server gave new work; passing to WorkQueue
[27/04/2011 18:18:59] Result didn't meet full difficulty, not sending
[27/04/2011 18:19:01] Server gave new work; passing to WorkQueue
.
.
.
[27/04/2011 18:20:24] Result didn't meet full difficulty, not sending
[27/04/2011 18:20:31] Result didn't meet full difficulty, not sending
[27/04/2011 18:20:33] Server gave new work; passing to WorkQueue

A bit puzzled about all those not sending warnings.
[27/04/2011 18:20:44] Result didn't meet full difficulty, not sending
[27/04/2011 18:20:47] Server gave new work; passing to WorkQueue
[331.20 Mhash/sec] [0 Accepted] [0 Rejected] [RPC]

That's normal. -v turns on "verbose mode" which shows you debug messages. That mode is mostly
intended for when you're trying to hunt down a problem with your miner.
EDIT: Those "not sending" debug messages are part of the normal behavior of Phoenix. In
reality, the poclbm kernel actually reports only difficulty=1 hashes to the Phoenix system. It is then
up to Phoenix to check if it meets full network difficulty. When that check fails (as it will most of the
time), it flags it as a debug message and continues on its way.

Everything else is fine, but since you're mining solo, you might want an askrate so your miner
switches sooner after the blocks change. Changing your miners to this should do the trick:
Code:
phoenix.exe -u http://xxxx:xxxx@localhost:8332/;askrate=10 PLATFORM=0 DEVICE=0 -k poclbm VECTORS WORKSIZE=128 BFI_INT AGGRESSION=10
phoenix.exe -u http://xxxx:xxxx@localhost:8332/;askrate=10 PLATFORM=0 DEVICE=1 -k poclbm VECTORS WORKSIZE=128 BFI_INT AGGRESSION=10


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TurdHurdur on April 27, 2011, 08:42:18 AM
So, what's the average donation been?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 27, 2011, 08:47:13 AM
So, what's the average donation been?

Feel free to look at the address in BlockExplorer... 129ZQG33GmqYRVSCw2hw7zmDUCvvMsuGbC (http://blockexplorer.com/address/129ZQG33GmqYRVSCw2hw7zmDUCvvMsuGbC)

That 10 came as a surprise, but it's otherwise been pretty modest, although we're grateful for the support!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Grinder on April 27, 2011, 08:54:12 AM
Problem is that because everybody will use this miner from now on, the difficulty will rise and soon the payout will be the same as with the old miners. It does make the bitcoin network more secure, though.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 27, 2011, 09:02:27 AM
We have identified a possible cause of the increased invalid/stale/rejected shares.

The FASTLOOP setting has the kernel do 8 internal loops before getting additional work from the main queue. This process is not interrupted when new work is pushed through LP or otherwise, so using this option can extend the amount of time the miner spends running stale work. This should not be a problem is FASTLOOP is used as intended with AGGRESSION set to 8 or lower. (since the total delay is less than a second)

With higher AGGRESSION settings FASTLOOP can extend the time it takes the kernel to get new work to more than 10 seconds.

The issue is worsened slightly by a minor bug in the Phoenix framework which will be addressed in 1.3.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 27, 2011, 10:15:06 AM
i get this message everytime i start phoenix on ubuntu:
Code:
/home/noodles/phoenix-1.2/KernelInterface.py:139: DeprecationWarning: struct integer overflow masking is deprecated
  hashInput = pack('>76sI', staticData, nonce)
/home/noodles/phoenix-1.2/KernelInterface.py:148: DeprecationWarning: struct integer overflow masking is deprecated
  formattedResult = pack('<76sI', range.unit.data[:76], nonce)
it just spits out that warning and starts to work anyway,

but from time to time, a miner just stops after work queue is empty, like it did about 1hour ago:
Code:
[27/04/2011 00:20:39] Result: 83228c5b accepted             
[27/04/2011 00:20:39] Warning: work queue empty, miner is idle
and i have to restart it (and again get the warning shown above)

To follow up: Apparently the DeprecationWarning is something a little bit more serious. For some reason, PyOpenCL is returning
either a negative nonce, or one greater than 2^32. The NumPy array that nonces get placed in is designated as a uint32 array.
There is absolutely no way that should be possible... and yet it's happening.
Maybe there's a bug in your version of PyOpenCL or NumPy? I have absolutely no idea what's wrong, sorry.

However, I don't think this is a benign issue, it could be seriously impacting your hashrate and/or ability to send in shares. We'll probably
have to have a more in-depth conversation via PM about this... I'm just as interested in getting to the bottom of this as you are.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 27, 2011, 10:40:13 AM
Version 1.3 has been released.

Changes:

1. Kernel performance improvements on ATI hardware without BFI_INT enabled (3-10 Mhash/sec)
2. Added warning on startup if FASTLOOP is enabled with AGGRESSION set to 9 or higher
3. The kernel's work cache is cleared when a new block is started (reduces invalid/stale)
4. Results are checked against the current block before being sent (prevents sending stale work if the block changed while the kernel was processing it)
5. Various minor bugfixes


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: molecular on April 27, 2011, 10:52:28 AM
congrats on your miner: insane speed!

One question: I'm using phoenix to mine solo on one GPU, on slush's pool on the other. The slush one report "working on block #" when switching to a new block. The miner connected to my local bitcoin (solo) doesn't do that. Why not?





Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 27, 2011, 11:10:21 AM
congrats on your miner: insane speed!

One question: I'm using phoenix to mine solo on one GPU, on slush's pool on the other. The slush one report "working on block #" when switching to a new block. The miner connected to my local bitcoin (solo) doesn't do that. Why not?


This message is only displayed when the RPC server sends X-Blocknum in the header. A local bitcoin or bitcoind instance doesn't provide it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 27, 2011, 11:11:22 AM
As jedi95 said, Slush's pool has an extra header in the response that indicates the block number, which is simply displayed in the Phoenix output.
bitcoind doesn't give this header during getwork() responses, (and, as of this writing, nor do any of the other pools), but when I have time to
sit down and adjust the internals a bit, I can make it query the solo Bitcoin client for its block number.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: molecular on April 27, 2011, 11:13:21 AM
congrats on your miner: insane speed!

One question: I'm using phoenix to mine solo on one GPU, on slush's pool on the other. The slush one report "working on block #" when switching to a new block. The miner connected to my local bitcoin (solo) doesn't do that. Why not?


This message is only displayed when the RPC server sends X-Blocknum in the header. A local bitcoin or bitcoind instance doesn't provide it.

Aaawright. Thanks for clearing that up for me.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on April 27, 2011, 11:52:51 AM
Hi I have a question, you mentioned that it is good to set an askrate=10 when mining solo due to the possible change in block. I recalled that the default for poclbm or diablo was 5. Does the askrate for phoenix use the same scale system as the other 2? Additionally, does the askrate=5 potentially cause the miner to work incompletely. For example, if the miner has not completely hash the current work and the new work arrives dumping the current work mid way, and this cycle continues. Would it affect the probability of finding a solution?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 27, 2011, 12:21:40 PM
Hi I have a question, you mentioned that it is good to set an askrate=10 when mining solo due to the possible change in block. I recalled that the default for poclbm or diablo was 5. Does the askrate for phoenix use the same scale system as the other 2? Additionally, does the askrate=5 potentially cause the miner to work incompletely. For example, if the miner has not completely hash the current work and the new work arrives dumping the current work mid way, and this cycle continues. Would it affect the probability of finding a solution?

Work (2^32 nonces) is always checked completely unless the block changes before the entire range of nonces is checked. In terms of full getwork responses, if the queue is already full when more work is received the oldest work is discarded. This doesn't affect the chances of finding a block, since it's just as likely that the new work contains a solution.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Raulo on April 27, 2011, 12:26:47 PM
In terms of full getwork responses, if the queue is already full when more work is received the oldest work is discarded.
This doesn't affect the chances of finding a block, since it's just as likely that the new work contains a solution.

What if the work queue is half full and new getwork with new midstate is received?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 27, 2011, 12:47:24 PM
In terms of full getwork responses, if the queue is already full when more work is received the oldest work is discarded.
This doesn't affect the chances of finding a block, since it's just as likely that the new work contains a solution.

What if the work queue is half full and new getwork with new midstate is received?

Do you mean a new getwork with a new previous block hash? Because midstate would change on
every new getwork regardless of whether it's based on a new block or not.

When a getwork with a new previous block comes in, however, the queue instantly purges itself
and tries to prevent the Phoenix kernel from running any of the old work (regardless of whether it's full or half-full).
This can result in the devices going idle for a short period of time, if Phoenix can't restock its queue fast enough to
feed them all with new work... but it's better than having them work on shares that are just going to get
dropped on the floor the moment they are received by the pool server, at any rate. ;)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Inaba on April 27, 2011, 12:49:52 PM
So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on April 27, 2011, 12:57:53 PM
So taken together can it be summarize that askrate=10 is sufficient and the same as askrate=5?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: William Reed on April 27, 2011, 01:00:38 PM
So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.


I think vectors are defined just "VECTORS" not "VECTORS=on". That might solve the performance issue.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Raulo on April 27, 2011, 01:12:29 PM
Do you mean a new getwork with a new previous block hash? Because midstate would change on
every new getwork regardless of whether it's based on a new block or not.

I'm curious how both situations are handled.

Quote
When a getwork with a new previous block comes in, however, the queue instantly purges itself
and tries to prevent the Phoenix kernel from running any of the old work (regardless of whether it's full or half-full).

Does it mean that the work is dropped only if the hash of previous block changes (good idea), otherwise new getwork is just added to the queue? I'm not sure how bitcoin daemon would handle a proof-of-work for old midstate that have current prevblock (e.g. in case of only merkleroot changed due to new transactions). Would it  be accepted?



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Inaba on April 27, 2011, 01:14:07 PM
So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.


I think vectors are defined just "VECTORS" not "VECTORS=on". That might solve the performance issue.

Yeah, I tried it both ways with the same result.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: luffy on April 27, 2011, 01:18:30 PM
if you lower the aggression? perhaps to 10


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: William Reed on April 27, 2011, 01:21:50 PM
So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.


I think vectors are defined just "VECTORS" not "VECTORS=on". That might solve the performance issue.

Yeah, I tried it both ways with the same result.


How many GPUs are you running? Are they all mining? How much CPU are they hogging? You could also try putting the miner in verbose mode (with -v flag) to see any possible errors.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Inaba on April 27, 2011, 01:34:33 PM
How many GPUs are you running? Are they all mining? How much CPU are they hogging? You could also try putting the miner in verbose mode (with -v flag) to see any possible errors.

3 Miners (two are poclbm) on 3 5870's.  CPU usage is virtually nothing... 0.35 0.13 0.21

No errors shown with the -v flag.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: luffy on April 27, 2011, 01:51:41 PM
Is there a possibility for 6xxx series cards to have a unique command (like BFI_INT) to make them more profitable than 5xxx?
i wonder....


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: drgr33n on April 27, 2011, 02:06:03 PM
muchas gracias senor

With today's version my stale shares has dropped from 3.5% to 0% :D !! As for the comment about BFI_INT for 6XXX cards. Phoenix runs exactly the same as poclbm without BFI_INT on my xfx 5830 xxx edition. With it I get the extra boost and it steadily sits around 267MH/s.

I'm runing debian sid with catalyst 11.3 installed via the ATI packages, fglrx version 8.831.2-110308a-115935C-ATI and AMD APP v2.4.

oh and todays version of phoenix from trunk :D.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 27, 2011, 04:53:26 PM
So I am running this on a stock 5870 and I am getting almost exactly the same hashrate as poclbm.  Has poclbm been updated or is there something wrong with my command line for phoenix.

I'm using:

./phoenix.py -u <url> -k poclbm VECTORS=on BFI_INT AGGRESSION=13 WORKSIZE=128 DEVICE=1

Should I be using something different?  Getting 365 Mh/s in both poclbm and phoenix.


Try different AGGRESSION .. 12 was better than 13 or 11 for me.
Try lowering the WORKSIZE to 64, and try it without it completely.

Adding WORKSIZE, not matter what size, dropped my speed 10 Mh/s. I haven't had a problem running without it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 27, 2011, 06:09:12 PM


Adding WORKSIZE, not matter what size, dropped my speed 10 Mh/s. I haven't had a problem running without it.

If not specified it defaults to your cards spec -- probably increased from 128 to 256 I would guess.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: frankiebits on April 27, 2011, 06:57:29 PM
Thank you sir, got my vapor x 5870 from 375 to 415 without any changes to hardware settings. Here is what works for me if anyone is interested

phoenix -u http://email@gmail.com:password@deepbit.net:8332/ -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=10 WORKSIZE=2056


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: EgoPaintedGrey on April 27, 2011, 06:58:28 PM
Changed from 1.2 to 1.3 and it started sending Warning: work queue empty, miner is idle. :s.
If I run 1.2 it doesn´t happen.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 27, 2011, 07:18:51 PM
Changed from 1.2 to 1.3 and it started sending Warning: work queue empty, miner is idle. :s.
If I run 1.2 it doesn´t happen.



So far I have only seen mine do that right before a Long Poll update when a block was found.

What were the circumstances? Was it right before or after a Long Poll Update? What pool are you using?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tripper22 on April 27, 2011, 07:22:42 PM
Nice work guys! I get the following warning messages right after I start up my miners (version 1.3).

KernelInterface.py:195: DeprecationWarning: struct integer overflow masking is deprecated hashInput = pack('>76sI', staticData, nonce)

KernelInterface.py:210: DeprecationWarning: struct integer overflow masking is deprecated formattedResult = pack('<76sI', nr.unit.data[:76], nonce)

But it seems to work great after the warnings. I'm using Ubuntu 10.10 SDK 2.1 with four 5870's.

Thanks in advance for any help.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: travex on April 27, 2011, 09:42:37 PM
Hi guys, what is the command line for mining solo ?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dbitcoin on April 27, 2011, 10:19:47 PM
Code:
Unhandled error in Deferred:
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 354, in _startRunCallbacks
    self._runCallbacks()
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 371, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 330, in _continue
    self.unpause()
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 325, in unpause
    self._runCallbacks()
--- <exception caught here> ---
  File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 371, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "/phoenix-1.3/minerutil/RPCProtocol.py", line 244, in <lambda>
    d.addErrback(lambda x: self._failure())
  File "/phoenix-1.3/minerutil/RPCProtocol.py", line 307, in _failure
    self._setLongPollingPath(None)
  File "/phoenix-1.3/minerutil/RPCProtocol.py", line 174, in _setLongPollingPath
    self.activeLongPoll.cancel()
exceptions.AttributeError: Deferred instance has no attribute 'cancel'


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 27, 2011, 10:51:38 PM
Changed from 1.2 to 1.3 and it started sending Warning: work queue empty, miner is idle. :s.
If I run 1.2 it doesn´t happen.



A possible cause of this has been determined and it has been fixed in the latest SVN revision. In certain cases a new block being received would case the kernel to request work form the queue twice.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: marcus_of_augustus on April 27, 2011, 10:53:28 PM
Thank you sir, got my vapor x 5870 from 375 to 415 without any changes to hardware settings. Here is what works for me if anyone is interested

phoenix -u http://email@gmail.com:password@deepbit.net:8332/ -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=10 WORKSIZE=2056


Really WORKSIZE=2056

should that be 256?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 27, 2011, 11:48:26 PM
Does it mean that the work is dropped only if the hash of previous block changes (good idea), otherwise new getwork is just added to the queue? I'm not sure how bitcoin daemon would handle a proof-of-work for old midstate that have current prevblock (e.g. in case of only merkleroot changed due to new transactions). Would it  be accepted?

Actually, bitcoind changes the merkle root on every getwork, since the extraNonce (which is inside the coinbase transaction) is incremented every time.
It caches the trees for every merkle root in RAM and, when a successful proof-of-work solution is found, finds the corresponding tree to attach to the block.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on April 27, 2011, 11:55:23 PM
holy ...
from 274 to 300 Mhash/s 6870 1038/345 , win7


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: qed on April 27, 2011, 11:57:41 PM
Changed from 1.2 to 1.3 and it started sending Warning: work queue empty, miner is idle. :s.
If I run 1.2 it doesn´t happen.



I had the same problem, in both versions 1.2 and version 1.3.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 28, 2011, 12:08:52 AM
Thank you sir, got my vapor x 5870 from 375 to 415 without any changes to hardware settings. Here is what works for me if anyone is interested

phoenix -u http://email@gmail.com:password@deepbit.net:8332/ -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=10 WORKSIZE=2056


Really WORKSIZE=2056

should that be 256?

This won't cause problems since invalid WORKSIZE settings are automatically corrected (by rounding down to the nearest valid setting, which is this case would be 256)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Inaba on April 28, 2011, 02:30:25 AM
So I'm trying to run this on one of my Windows boxes and it's giving me the error "Could not locate the specified kernel!"  how do I specify where it should be looking and what do I need in the directory?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tiberiandusk on April 28, 2011, 03:48:52 AM
So I'm trying to run this on one of my Windows boxes and it's giving me the error "Could not locate the specified kernel!"  how do I specify where it should be looking and what do I need in the directory?

You need to open the command line window and change the directory to the folder you have phoenix in. Then just type in the commands and flags posted above for the pool you are using and your video card.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: xanadu on April 28, 2011, 04:21:49 AM
I happened to have the kill-o-watt connected to one of my miners so I jotted down some notes:

Baseline (system up, nothing running) 165w, running solo:
poclbm, 5870, 316Mhash, Start 305w@51C, Finish 315w@76C
Phoenix, 5870, 350Mhash, Start 290w@52c, Finish 309w@75C
Phoenix, 5870 w/MSI Afterburner 965/300, 397Mhash, finish 318w@75C (didn't wait for the card to cool down this time).

And in the end I fired up the 5970 and the 5870 and had all three GPUs running under Phoenix and the system stabilized at 550w, not bad for ~900 Mhashs.

System is a MSI motherboard with low-end AMD Semperon CPU and Vista Ultimate running in 32bit mode.

-X


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: eleuthria on April 28, 2011, 04:49:48 AM
Great job fixing the stale shares with 1.3.  Since switching to the new version I've only had 11 stales out of 9373, and I'm pretty sure 4 of the 11 are from when I was switching my mining room over to an 8-port switch (more rigs on the way, mwahhahah!).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Internet151 on April 28, 2011, 08:22:58 AM
It seems like if a pool goes down for over 15 minutes or so, phoenix stops trying to reconnect. Is there anything I can do about that? (bitcoinpool.com had some trouble tonight)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Timon2010 on April 28, 2011, 08:41:53 AM
Any chance you can hide the cmd-window to the tray when minimize it instead of to taskbar?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Xer on April 28, 2011, 09:15:56 AM
Any chance you can hide the cmd-window to the tray when minimize it instead of to taskbar?


http://www.askvg.com/how-to-minimize-an-application-to-system-tray-in-windows/



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: sniper_sniperson on April 28, 2011, 11:31:16 AM
What's exactly doing PLATFORM=ID option?

Short answer:
The PLATFORMS=ID switch is to specify which platform ID on your system you want to use.
It's only important if you have multiple OpenCL devices in your system, from different vendors (mixing AMD/ATI and
nVidia cards in one system, for example.)
If you only have one platform on your system, you don't have to specify it. If you have multiple platforms,
Phoenix will tell you that it is needed. So, don't worry about it. :)

Long answer:
OpenCL is a standard developed by Khronos.
The "core" of OpenCL was not created by AMD/ATI nor nVidia, although they probably contribute to its development.
The problem is that, even though OpenCL is common, AMD/ATI and nVidia have different ideas about how to go about
bridging the gap between OpenCL and GPU. AMD/ATI gets from OpenCL to raw GPU code in a different way from how
nVidia does it, which makes nVidia's version of OpenCL totally incompatible with AMD/ATI cards and vice versa.

This can cause a serious problem when there is a system with some nVidia and some AMD/ATI cards in it: One vendor's
version of OpenCL will not work with another vendor's card, so Khronos needed a way of making sure independent
versions could exist on the same system. Their solution was to use an "installable client driver" (ICD) for each vendor.
So, when you install both AMD/ATI's OpenCL and nVidia's OpenCL, they exist as separate "platforms." One accesses
the AMD/ATI cards, the other accesses the nVidia cards.

So .. any ideas how to use phoenix with the followin scheme:

first slot - 5870
second slot - 5970

cause Catalyst reports that second GPU on 5970 is disabled:
Quote
Primary Adapter      
Graphics Card Manufacturer   Powered by AMD   
Graphics Chipset   ATI Radeon HD 5800 Series   
Device ID   6898   
Vendor   1002   
   
Subsystem ID   21E6   
Subsystem Vendor ID   1458   
   
Graphics Bus Capability   PCI Express 2.0   
Maximum Bus Setting   PCI Express 2.0 x8   
   
BIOS Version   012.019.000.008   
BIOS Part Number   113-C00801-011     
BIOS Date   2010/03/01   
   
Memory Size   1024 MB   
Memory Type   GDDR5   
   
Core Clock in MHz   950 MHz   
Memory Clock in MHz   1250 MHz   
Total Memory Bandwidth in GByte/s   160.0 GByte/s   
   
   
Linked Adapter       
Graphics Card Manufacturer   Powered by AMD   
Graphics Chipset   ATI Radeon HD 5900 Series   
Device ID   689C   
Vendor   1002   
   
Subsystem ID   C000   
Subsystem Vendor ID   174B   
   
Graphics Bus Capability   PCI Express 2.0   
Maximum Bus Setting   PCI Express 2.0 x8   
   
BIOS Version   012.020.000.014   
BIOS Part Number   113-C01OCS-AC1     
BIOS Date   2010/05/30   
   
Memory Size   1024 MB   
Memory Type   GDDR5   
   
Core Clock in MHz   735 MHz   
Memory Clock in MHz   1010 MHz   
Total Memory Bandwidth in GByte/s   129.3 GByte/s   
   
   
Disabled Adapter       
Graphics Card Manufacturer   Powered by AMD   
Graphics Chipset   ATI Radeon HD 5900 Series   
Device ID   689C   
Vendor   1002   
   
Subsystem ID   C000   
Subsystem Vendor ID   174B   
   
Graphics Bus Capability   PCI Express 2.0   
Maximum Bus Setting   PCI Express 2.0 x8   
   
BIOS Version   012.020.000.019   
BIOS Part Number   113-C01OCM-AC1     
BIOS Date   2010/05/30   
   
Memory Size   1024 MB   
Memory Type   GDDR5   
   
Core Clock in MHz   735 MHz   
Memory Clock in MHz   1010 MHz   
Total Memory Bandwidth in GByte/s   129.3 GByte/s   

and no chance to start phoenix or pocblm with device # parameter since the only active is number 0. Second is the cpu.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Kick on April 28, 2011, 12:25:31 PM
What's exactly doing PLATFORM=ID option?

Short answer:
The PLATFORMS=ID switch is to specify which platform ID on your system you want to use.
It's only important if you have multiple OpenCL devices in your system, from different vendors (mixing AMD/ATI and
nVidia cards in one system, for example.)
If you only have one platform on your system, you don't have to specify it. If you have multiple platforms,
Phoenix will tell you that it is needed. So, don't worry about it. :)

Long answer:
OpenCL is a standard developed by Khronos.
The "core" of OpenCL was not created by AMD/ATI nor nVidia, although they probably contribute to its development.
The problem is that, even though OpenCL is common, AMD/ATI and nVidia have different ideas about how to go about
bridging the gap between OpenCL and GPU. AMD/ATI gets from OpenCL to raw GPU code in a different way from how
nVidia does it, which makes nVidia's version of OpenCL totally incompatible with AMD/ATI cards and vice versa.

This can cause a serious problem when there is a system with some nVidia and some AMD/ATI cards in it: One vendor's
version of OpenCL will not work with another vendor's card, so Khronos needed a way of making sure independent
versions could exist on the same system. Their solution was to use an "installable client driver" (ICD) for each vendor.
So, when you install both AMD/ATI's OpenCL and nVidia's OpenCL, they exist as separate "platforms." One accesses
the AMD/ATI cards, the other accesses the nVidia cards.

So .. any ideas how to use phoenix with the followin scheme:

first slot - 5870
second slot - 5970

   

and no chance to start phoenix or pocblm with device # parameter since the only active is number 0. Second is the cpu.
[/quote]

you need a dummy plug or another monitor to plug into the card


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: drgr33n on April 28, 2011, 02:21:53 PM
What's exactly doing PLATFORM=ID option?

Short answer:
The PLATFORMS=ID switch is to specify which platform ID on your system you want to use.
It's only important if you have multiple OpenCL devices in your system, from different vendors (mixing AMD/ATI and
nVidia cards in one system, for example.)
If you only have one platform on your system, you don't have to specify it. If you have multiple platforms,
Phoenix will tell you that it is needed. So, don't worry about it. :)

Long answer:
OpenCL is a standard developed by Khronos.
The "core" of OpenCL was not created by AMD/ATI nor nVidia, although they probably contribute to its development.
The problem is that, even though OpenCL is common, AMD/ATI and nVidia have different ideas about how to go about
bridging the gap between OpenCL and GPU. AMD/ATI gets from OpenCL to raw GPU code in a different way from how
nVidia does it, which makes nVidia's version of OpenCL totally incompatible with AMD/ATI cards and vice versa.

This can cause a serious problem when there is a system with some nVidia and some AMD/ATI cards in it: One vendor's
version of OpenCL will not work with another vendor's card, so Khronos needed a way of making sure independent
versions could exist on the same system. Their solution was to use an "installable client driver" (ICD) for each vendor.
So, when you install both AMD/ATI's OpenCL and nVidia's OpenCL, they exist as separate "platforms." One accesses
the AMD/ATI cards, the other accesses the nVidia cards.

So .. any ideas how to use phoenix with the followin scheme:

first slot - 5870
second slot - 5970

cause Catalyst reports that second GPU on 5970 is disabled:
Quote
Primary Adapter      
Graphics Card Manufacturer   Powered by AMD   
Graphics Chipset   ATI Radeon HD 5800 Series   
Device ID   6898   
Vendor   1002   
   
Subsystem ID   21E6   
Subsystem Vendor ID   1458   
   
Graphics Bus Capability   PCI Express 2.0   
Maximum Bus Setting   PCI Express 2.0 x8   
   
BIOS Version   012.019.000.008   
BIOS Part Number   113-C00801-011     
BIOS Date   2010/03/01   
   
Memory Size   1024 MB   
Memory Type   GDDR5   
   
Core Clock in MHz   950 MHz   
Memory Clock in MHz   1250 MHz   
Total Memory Bandwidth in GByte/s   160.0 GByte/s   
   
   
Linked Adapter       
Graphics Card Manufacturer   Powered by AMD   
Graphics Chipset   ATI Radeon HD 5900 Series   
Device ID   689C   
Vendor   1002   
   
Subsystem ID   C000   
Subsystem Vendor ID   174B   
   
Graphics Bus Capability   PCI Express 2.0   
Maximum Bus Setting   PCI Express 2.0 x8   
   
BIOS Version   012.020.000.014   
BIOS Part Number   113-C01OCS-AC1     
BIOS Date   2010/05/30   
   
Memory Size   1024 MB   
Memory Type   GDDR5   
   
Core Clock in MHz   735 MHz   
Memory Clock in MHz   1010 MHz   
Total Memory Bandwidth in GByte/s   129.3 GByte/s   
   
   
Disabled Adapter       
Graphics Card Manufacturer   Powered by AMD   
Graphics Chipset   ATI Radeon HD 5900 Series   
Device ID   689C   
Vendor   1002   
   
Subsystem ID   C000   
Subsystem Vendor ID   174B   
   
Graphics Bus Capability   PCI Express 2.0   
Maximum Bus Setting   PCI Express 2.0 x8   
   
BIOS Version   012.020.000.019   
BIOS Part Number   113-C01OCM-AC1     
BIOS Date   2010/05/30   
   
Memory Size   1024 MB   
Memory Type   GDDR5   
   
Core Clock in MHz   735 MHz   
Memory Clock in MHz   1010 MHz   
Total Memory Bandwidth in GByte/s   129.3 GByte/s   

and no chance to start phoenix or pocblm with device # parameter since the only active is number 0. Second is the cpu.

On a linux based OS just run aticonfig --adapter=all --initial and restart x. poclbm should see both cards now.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 28, 2011, 02:27:34 PM
In windows if you don't want to use a dummy plug you can just switch the monitor cable from the primary to the secondary and the secondary card should then be immediately visible to OpenCL apps. I would build a dummy cable cause I'm lazy and don't want to be flippin cables....


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: qed on April 28, 2011, 02:40:07 PM
In windows if you don't want to use a dummy plug you can just switch the monitor cable from the primary to the secondary and the secondary card should then be immediately visible to OpenCL apps. I would build a dummy cable cause I'm lazy and don't want to be flippin cables....

Not working on Windows 7 and catalyst 11.4. The desktop is becoming blanj and you wont be able to start any program.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on April 28, 2011, 02:43:06 PM
In windows if you don't want to use a dummy plug you can just switch the monitor cable from the primary to the secondary and the secondary card should then be immediately visible to OpenCL apps. I would build a dummy cable cause I'm lazy and don't want to be flippin cables....

Not working on Windows 7 and catalyst 11.4. The desktop is becoming blanj and you wont be able to start any program.

Odd. Then again I tried it with 11.3 - works fine. What happens when I switch the cable to the secondary card is I get a windows desktop. The catalyst drivers should detect the secondary display and create a secondary desktop. If not you may have to manually create a desktop. Also bear in mind this is WITHOUT crossfire enabled. Crossfire may introduce additional details into the picture.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: B!0HaZard on April 28, 2011, 02:51:25 PM
Hey guys!

I've been using the GUI created by Kiv (http://bitcointalk.org/index.php?topic=3878.0) and I heard Phoenix is faster, so naturally I'm trying this, despite having no experience with cmd prompts.
As expected, I can't seem to figure out how to launch it  :-[

This is what I've got so far (some mix between this thread and a guide for m0mchil's software):
Code:
start /DC:\Bitcoin phoenix -u http://"mymail@site.com:password"@deepbit.net:8332/ -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=7
It tries to launch, but tells me that it "failed to patch kernel" :(

I've tried a couple of variations thereof, but it doesn't seem to work.

Any idea what's wrong?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: legoman786 on April 28, 2011, 02:53:27 PM
Hello,

I'm new here. Found Bitcoins off a forum I frequent. I know the answer I'm looking for is here, but after almost an hour of searching for it, I can't seem to find it.

I have m0mchil’s miner, and got that running. However, I heard that people are getting better results with the Phoenix miner. Thing is... I can't get it running >______<

As I said, I know the answer is here, but I seem to have missed it.

How do I get the Phoenix miner running in a Windows 7 64-bit environment?

ATI 4850, BTW.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitjet on April 28, 2011, 02:59:30 PM
In windows if you don't want to use a dummy plug you can just switch the monitor cable from the primary to the secondary and the secondary card should then be immediately visible to OpenCL apps. I would build a dummy cable cause I'm lazy and don't want to be flippin cables....

Not working on Windows 7 and catalyst 11.4. The desktop is becoming blanj and you wont be able to start any program.

Odd. Then again I tried it with 11.3 - works fine. What happens when I switch the cable to the secondary card is I get a windows desktop. The catalyst drivers should
 detect the secondary display and create a secondary desktop. If not you may have to manually create a desktop. Also bear in mind this is WITHOUT crossfire enabled. Crossfire may introduce additional details into the picture.

Yes if you can cross fire those cards the 3rd gpu will become visable to the system.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: qed on April 28, 2011, 03:02:23 PM
Hey guys!

I've been using the GUI created by Kiv (http://bitcointalk.org/index.php?topic=3878.0) and I heard Phoenix is faster, so naturally I'm trying this, despite having no experience with cmd prompts.
As expected, I can't seem to figure out how to launch it  :-[

This is what I've got so far (some mix between this thread and a guide for m0mchil's software):
Code:
start /DC:\Bitcoin phoenix -u http://"mymail@site.com:password"@deepbit.net:8332/ -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=7
It tries to launch, but tells me that it "failed to patch kernel" :(

I've tried a couple of variations thereof, but it doesn't seem to work.

Any idea what's wrong?

Did you try to add a "cd C:\Bitcoin" on top of that?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: B!0HaZard on April 28, 2011, 03:17:49 PM
Hey guys!

I've been using the GUI created by Kiv (http://bitcointalk.org/index.php?topic=3878.0) and I heard Phoenix is faster, so naturally I'm trying this, despite having no experience with cmd prompts.
As expected, I can't seem to figure out how to launch it  :-[

This is what I've got so far (some mix between this thread and a guide for m0mchil's software):
Code:
start /DC:\Bitcoin phoenix -u http://"mymail@site.com:password"@deepbit.net:8332/ -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=7
It tries to launch, but tells me that it "failed to patch kernel" :(

I've tried a couple of variations thereof, but it doesn't seem to work.

Any idea what's wrong?

Did you try to add a "cd C:\Bitcoin" on top of that?

How do you mean?

Like this?
Code:
cd C:\Bitcoin phoenix -u http://"mymail@site.com:password"@deepbit.net:8332/ -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=7[/code


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: legoman786 on April 28, 2011, 03:23:54 PM
I got it to work. I forgot to define the device. rofl.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: qed on April 28, 2011, 03:27:13 PM
Hey guys!

I've been using the GUI created by Kiv (http://bitcointalk.org/index.php?topic=3878.0) and I heard Phoenix is faster, so naturally I'm trying this, despite having no experience with cmd prompts.
As expected, I can't seem to figure out how to launch it  :-[

This is what I've got so far (some mix between this thread and a guide for m0mchil's software):
Code:
start /DC:\Bitcoin phoenix -u http://"mymail@site.com:password"@deepbit.net:8332/ -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=7
It tries to launch, but tells me that it "failed to patch kernel" :(

I've tried a couple of variations thereof, but it doesn't seem to work.

Any idea what's wrong?

Did you try to add a "cd C:\Bitcoin" on top of that?

How do you mean?

Like this?
Code:
cd C:\Bitcoin phoenix -u http://"mymail@site.com:password"@deepbit.net:8332/ -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=7[/code


I meant:

Code:
cd C:\Bitcoin
C:\Bitcoin phoenix -u http://"mymail@site.com:password"@deepbit.net:8332/ -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=7


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: B!0HaZard on April 28, 2011, 03:34:25 PM
Well, that seemed to fix one issue (the window that told me that the kernel wasn't patched would disappear immediately), but I'm still getting "Failed to patch kernel".


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tripper22 on April 28, 2011, 04:37:35 PM
It seems like if a pool goes down for over 15 minutes or so, phoenix stops trying to reconnect. Is there anything I can do about that? (bitcoinpool.com had some trouble tonight)

Shouldn't the miners always be trying to connect to the pool or server? Can you guys provide a fix for this please? Thanks and keep up the good work.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Inaba on April 28, 2011, 06:34:20 PM
So I'm trying to run this on one of my Windows boxes and it's giving me the error "Could not locate the specified kernel!"  how do I specify where it should be looking and what do I need in the directory?

You need to open the command line window and change the directory to the folder you have phoenix in. Then just type in the commands and flags posted above for the pool you are using and your video card.

That's what I was doing.  Removing the -k poclbm seems to have solved the problem.  If you try to specify the kernel in the windows version, even if it's the default one, it will fail.  Letting it default to poclbm seems to work fine though.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 28, 2011, 07:02:37 PM
Well, that seemed to fix one issue (the window that told me that the kernel wasn't patched would disappear immediately), but I'm still getting "Failed to patch kernel".

What hardware are you running? The "Failed to patch kernel" error means that applying the BFI_INT patch failed. (likely because you are using unsupported hardware)



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on April 28, 2011, 07:21:57 PM
Hey guys!

I've been using the GUI created by Kiv (http://bitcointalk.org/index.php?topic=3878.0) and I heard Phoenix is faster, so naturally I'm trying this, despite having no experience with cmd prompts.
As expected, I can't seem to figure out how to launch it  :-[

This is what I've got so far (some mix between this thread and a guide for m0mchil's software):
Code:
start /DC:\Bitcoin phoenix -u http://"mymail@site.com:password"@deepbit.net:8332/ -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=7
It tries to launch, but tells me that it "failed to patch kernel" :(

I've tried a couple of variations thereof, but it doesn't seem to work.

Any idea what's wrong?

Remove QUOTATION ""  phoenix -u http://mymail@site.com:password@deepbit.net...................


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 28, 2011, 10:14:32 PM
Shouldn't the miners always be trying to connect to the pool or server? Can you guys provide a fix for this please? Thanks and keep up the good work.

Bah, that was an oversight on my part. :-[ Sorry.
I have fixed it and the next release won't have that problem anymore.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slurch on April 28, 2011, 11:42:35 PM
For what it's worth, this absolutely garners this noob's seal of approval. Went from 260 to 285 MHash (give or take) on my 5830 using:

;askrate=10 -k poclbm VECTORS BFI_INT FASTLOOP AGGRESSION=7 DEVICE=1 on Slush's Pool.

Clocked at 950/400 on my actual computer (not a dedicated rig). Way to go! :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slurch on April 28, 2011, 11:50:51 PM
I got it to work. I forgot to define the device. rofl.

I did the same thing, and the command box popped up so fast I couldn't see what the issue was...has to manually go and launch the program. :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TheShoura on April 28, 2011, 11:56:38 PM
need help w/ performance

phoenix.exe PLATFORM=1 DEVICE=0 -u http://xxx@gmail.com:xxx@deepbit.net:8332 -k poclbm VECTORS BFI_INT AGGRESSION=8 WORKSIZE=256

I'm maxing out at 290 Mhash/s where as poclbm was doing 290-305...

I tried increasing aggression but my pc locks up instantly.

poclbm also crashes my system but i think it was heat related the 1 time it happened, im still testing


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 29, 2011, 12:00:01 AM
I got it to work. I forgot to define the device. rofl.

I did the same thing, and the command box popped up so fast I couldn't see what the issue was...has to manually go and launch the program. :)

Hmm... Sage advice: If you use .bat or .cmd scripts, put the word pause at the bottom, on a line by itself.
That way it waits for a keypress before closing the window on you. :)
jedi95 should probably put that in the first post.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slurch on April 29, 2011, 12:14:38 AM
I got it to work. I forgot to define the device. rofl.

I did the same thing, and the command box popped up so fast I couldn't see what the issue was...has to manually go and launch the program. :)

Hmm... Sage advice: If you use .bat or .cmd scripts, put the word pause at the bottom, on a line by itself.
That way it waits for a keypress before closing the window on you. :)
jedi95 should probably put that in the first post.

Batch file modified. Noob level decreased by 1. :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JWU42 on April 29, 2011, 02:27:53 AM
need help w/ performance

phoenix.exe PLATFORM=1 DEVICE=0 -u http://xxx@gmail.com:xxx@deepbit.net:8332 -k poclbm VECTORS BFI_INT AGGRESSION=8 WORKSIZE=256

I'm maxing out at 290 Mhash/s where as poclbm was doing 290-305...

I tried increasing aggression but my pc locks up instantly.

poclbm also crashes my system but i think it was heat related the 1 time it happened, im still testing

Try dropping the worksize to 128 ?

What card?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: melchior on April 29, 2011, 03:47:36 AM
I have been working on running the phoenix miner on a suse 11.2x86_64 and I have run into some issues.
I have been able to make phoenix run on windows systems with these worker accounts. I am able to run the poclbm client on the the suse sytem. But I was getting the IBODY error discussed earlier. Which lead me to downloading and compiling the newest version of Twisted. It installed and appears to install and work. But when I try to run phoenix-1.3 I get the following:

phoenix-1.3 # ./phoenix.py -u http://xxxxx.xxxx@xxxxx.net:xxxxxxx@deepbit.net:8332 -k poclbm DEVICE=1 VECTORS BFI_INT
Traceback (most recent call last):
  File "./phoenix.py", line 29, in <module>
    import minerutil
  File "/home/bill/Downloads/phoenix-1.3/minerutil/__init__.py", line 25, in <module>
    from RPCProtocol import RPCClient
  File "/home/bill/Downloads/phoenix-1.3/minerutil/RPCProtocol.py", line 26, in <module>
    from twisted.web import http, client
ImportError: cannot import name http


Device 1 is a ati 5850 in this case and it works with pocibm client. I have looked at the RPCProtocol.py it appears to be having issue importing http and client from twisted.web. Any ideas what I am missing, was there any special options I should have set when I compiled beside:
python setup.py build install

Thank you for your any assistance you can provide,
-Melchior


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TheShoura on April 29, 2011, 03:50:36 AM
need help w/ performance

phoenix.exe PLATFORM=1 DEVICE=0 -u http://xxx@gmail.com:xxx@deepbit.net:8332 -k poclbm VECTORS BFI_INT AGGRESSION=8 WORKSIZE=256

I'm maxing out at 290 Mhash/s where as poclbm was doing 290-305...

I tried increasing aggression but my pc locks up instantly.

poclbm also crashes my system but i think it was heat related the 1 time it happened, im still testing

Try dropping the worksize to 128 ?

What card?


5970 @ 800Mhz, I tried 128, it was slower


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: M4v3R on April 29, 2011, 05:33:56 AM
Is there any way for an external script to query Phoenix about current/average hashrate, via some form of RPC? It would be great to monitor these.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: eleuthria on April 29, 2011, 05:36:07 AM
Is there any way for an external script to query Phoenix about current/average hashrate, via some form of RPC? It would be great to monitor these.

Would love to know if that's possible as well.  I just finished hacking together a special script in poclbm where it logs the performance stats every 10 seconds to a network shared file which I is parsed by my webserver for a portable status page on my iPhone.  Works great, but I feel like I'm jumping through extra hoops.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: B!0HaZard on April 29, 2011, 05:43:56 AM
Remove QUOTATION ""  phoenix -u http://mymail@site.com:password@deepbit.net...................

That was just to show that I'd put my info there.

Well, that seemed to fix one issue (the window that told me that the kernel wasn't patched would disappear immediately), but I'm still getting "Failed to patch kernel".

What hardware are you running? The "Failed to patch kernel" error means that applying the BFI_INT patch failed. (likely because you are using unsupported hardware)

I'm running an HD 5850 with Cat 11.4.

That's what I was doing.  Removing the -k poclbm seems to have solved the problem.  If you try to specify the kernel in the windows version, even if it's the default one, it will fail.  Letting it default to poclbm seems to work fine though.

I think this was the answer I was looking for.

Anyway, thanks for the help guys, but the guiminer now supports BFI_INT, so I won't have to change now. Maybe I'll be back if you make more improvements.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on April 29, 2011, 06:39:37 AM
So I'm trying to run this on one of my Windows boxes and it's giving me the error "Could not locate the specified kernel!"  how do I specify where it should be looking and what do I need in the directory?

You need to open the command line window and change the directory to the folder you have phoenix in. Then just type in the commands and flags posted above for the pool you are using and your video card.

That's what I was doing.  Removing the -k poclbm seems to have solved the problem.  If you try to specify the kernel in the windows version, even if it's the default one, it will fail.  Letting it default to poclbm seems to work fine though.

I deny this
phoenix.exe -u http://1KaSXG6ncuriX2MXpsFohT7eELNQJSiS1E:x@pool.bitcoin.dashjr.org:8337/ -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=10
This is what in the bat file which is in phoenix-1.3 folder & it runs perfectly for me.
Win7 32


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: sniper_sniperson on April 29, 2011, 06:46:07 AM
In windows if you don't want to use a dummy plug you can just switch the monitor cable from the primary to the secondary and the secondary card should then be immediately visible to OpenCL apps. I would build a dummy cable cause I'm lazy and don't want to be flippin cables....

Not working on Windows 7 and catalyst 11.4. The desktop is becoming blanj and you wont be able to start any program.

Odd. Then again I tried it with 11.3 - works fine. What happens when I switch the cable to the secondary card is I get a windows desktop. The catalyst drivers should detect the secondary display and create a secondary desktop. If not you may have to manually create a desktop. Also bear in mind this is WITHOUT crossfire enabled. Crossfire may introduce additional details into the picture.

Funny cause the problem gone in Windows and FreeBSD when putting the XFire bridge  ???


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on April 29, 2011, 07:19:20 AM
Is there any way for an external script to query Phoenix about current/average hashrate, via some form of RPC? It would be great to monitor these.

Would love to know if that's possible as well.  I just finished hacking together a special script in poclbm where it logs the performance stats every 10 seconds to a network shared file which I is parsed by my webserver for a portable status page on my iPhone.  Works great, but I feel like I'm jumping through extra hoops.

You might be interested in my other project, Multiminer, which we use for our (jedi95 and I) cluster's status page (http://129.82.65.171:8882/). I have a Windows download here (http://cloud.github.com/downloads/CFSworks/multiminer/multiminer-1.4.zip) (or you can get the source off GitHub (https://github.com/CFSworks/multiminer)) and it's pretty easy to run:

multiminer --admin-user=admin --admin-pass=admin101 --web-port=80 --url=http://PoolUsername:PoolPassword@PoolHost:8332/

Then change your Phoenix URLs to mmp://admin:admin101@localhost?name=NameForThisWorker (Phoenix already supports the protocol)
And finally you can throw JSON-RPC requests at http://admin:admin101@localhost - try listconnections() to see your worker status.
You can also put an index.html in "www" and have it do some JQuery magic to view your workers.

The only drawback is Multiminer doesn't have its own logs (yet), but you will know it's working when your miners pick up work and start mining through it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: MrGaSp on April 29, 2011, 01:12:49 PM
poclbm
-w 64 --platform 0 -f 1
~340MH/s

Phoenix
-k poclbm VECTORS BFI_INT AGGRESSION=7 PLATFORM=0 DEVICE=1 WORKSIZE=64
~420-430 MH/s



...
oO


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: molecular on April 29, 2011, 02:01:06 PM
poclbm
-w 64 --platform 0 -f 1
~340MH/s

Phoenix
-k poclbm VECTORS BFI_INT AGGRESSION=7 PLATFORM=0 DEVICE=1 WORKSIZE=64
~420-430 MH/s

You know there's a new poclbm version out (20110428), which is matching phoenix' speed for me.

Competition is great!

Thanks to all coders, great work.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nelisky on April 29, 2011, 02:28:22 PM
I see
Code:
-k poclbm
everywhere... is there an alternative, or a need to specify this when using phoenix?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: molecular on April 29, 2011, 02:35:33 PM
I see
Code:
-k poclbm
everywhere... is there an alternative, or a need to specify this when using phoenix?
There's currently only one kernel supplied, poclbm. It's in the kernel directory.

I assume you could put your own kernels in that directory and select it with the -k switch.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Grinder on April 29, 2011, 03:11:20 PM
I see
Code:
-k poclbm
everywhere... is there an alternative, or a need to specify this when using phoenix?
No and no, but everybody just copies everybody elses setup, so this kind of thing spreads quickly. It's the same thing as the bat/cmd-file everybody makes to start the client even though a short cut would be easier.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: M4v3R on April 29, 2011, 04:44:24 PM
Thanks CFSworks! Using your tool I was able to get some information in nice HTML format:

http://bit.ly/iBcfJR

(to get fan speed and temperatures I hacked my version of WebServer.py in multiminer to get those stats for me).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on April 30, 2011, 11:59:11 AM
What's odd is I have two identical computers. One will connect to slushes just fine, the other won't. I've tried using different workers and even creating a new worker on slushes website.

Here is the command I am running:
phoenix.py -u http://username.worker:password@mining.bitcoin.cz:8332 -k poclbm DEVICE=0 VECTORS=on AGGRESSION=10 WORKSIZE=64 FASTLOOP BFI_INT

I have exactly the same problem. Except that I have three mining rigs, one head node and two slaves. They all connect through the head node to the internet and slush's pool. And it is so strange that only one slave node can always connect to the pool, and others two have always connections problems. And it's always the same one that works.

And they all have identical configuration. Both slaves are running from 8GB usb stick, which are exact copies of each other. Their mobos+GPUs+CPUs+everything are identical.

so strange.

It's even more strange, that when I try running phoenix, the diablo miner (which runs on other GPUs on same machine) is immediately starting to have connection problems too! And neither phoenix, nor diablo can connect. When I stop phoenix then diablo reconnects and continues to run just fine.

I think it is something with the network protocol used by phoenix.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on April 30, 2011, 12:29:52 PM
What's odd is I have two identical computers. One will connect to slushes just fine, the other won't. I've tried using different workers and even creating a new worker on slushes website.

Here is the command I am running:
phoenix.py -u http://username.worker:password@mining.bitcoin.cz:8332 -k poclbm DEVICE=0 VECTORS=on AGGRESSION=10 WORKSIZE=64 FASTLOOP BFI_INT

I have exactly the same problem. Except that I have three mining rigs, one head node and two slaves. They all connect through the head node to the internet and slush's pool. And it is so strrange that only one slave node can always connects to the pool, and others two have always connections problems. And it's always the same one that works.

And they all have identical configuration. Both slaves are running from 8GB usb stick, which are exact copies of each other. Their mobos+GPUs+CPUs+everything are identical.

so strange.

It's even more strange, that when I try running phoenix, the diablo miner (which runs on other GPUs on same machine) is immediately starting to have connection problems too! And neither phoenix, nor diablo can connect. When I stop phoenix then diablo reconnects and continues to run just fine.

I think it is something with the network protocol used by phoenix.

I so far heard phoenix.EXE only. why u running phoenix.py. You using linux?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on April 30, 2011, 12:40:51 PM
I so far heard phoenix.EXE only. why u running phoenix.py. You using linux?

I run this:

./phoenix.py -u http://u:pass@178.79.147.99:8332/ -k poclbm DEVICE=1 VECTORS AGGRESSION=13 BFI_INT WORKSIZE=64

yes, that's debian linux


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on April 30, 2011, 12:45:32 PM
I'm using r52. Command line -k poclbm DEVICE=3 VECTORS AGGRESSION=12 BFI_INT to bitcoinpoool

I was watching my client when a block was found and this showed up:

[30/04/2011 05:34:29] Result: 2cc5cc87 accepted
[30/04/2011 05:34:41] Result: 7f1bf205 accepted
[30/04/2011 05:35:08] Warning: work queue empty, miner is idle
[0 Khash/sec] [3526 Accepted] [11 Rejected] [RPC (+LP)]Unhandled error in Deferred:
Traceback (most recent call last):
Failure: twisted.internet.error.TimeoutError: User timeout caused connection failure.                    [30/04/2011 05:35:52] LP: New work pushed
[30/04/2011 05:37:50] Result: 3c452343 accepted
[30/04/2011 05:38:15] Result: d748a495 accepted
[30/04/2011 05:38:17] LP: New work pushed
[30/04/2011 05:38:37] Result: d9857987 rejected

[360.61 Mhash/sec] [3555 Accepted] [16 Rejected] [RPC (+LP)]

On 2 of the clients they picked back up and kept on going. On the 3rd it just stopped processing. After 30s I stopped and restarted it manually and it started chugging away without a problem.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: sniper_sniperson on April 30, 2011, 08:03:40 PM
And they all have identical configuration. Both slaves are running from 8GB usb stick, which are exact copies of each other

Tell me that you changed IP addresses of slave nodes... And it's good to tell what is the distribution you're using on them.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on April 30, 2011, 09:31:16 PM
And they all have identical configuration. Both slaves are running from 8GB usb stick, which are exact copies of each other

Tell me that you changed IP addresses of slave nodes... And it's good to tell what is the distribution you're using on them.
of course I did :) otherwise they would not connect to master node and to my vtun lan. That's debian squeeze Linux min3 2.6.32-5-686 #1 SMP Fri Dec 10 16:12:40 UTC 2010 i686 GNU/Linux

EDIT: and diablo's runs just fine, for many months already.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: FairUser on April 30, 2011, 10:01:55 PM
I just wanted to stop in and say that the phoenix miner kicks ass.  I'm getting about 20+ Mhash/s more than our miner (poclbm-mod).

Again, I'm glad to see that someone else understands the concept of efficiency, and I love that fact that it support long polling with our pool.

Anyone using your miner is more than welcome in our bitcoinpool(.com).
 :D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on April 30, 2011, 11:29:14 PM
Version 1.4 released.

Changes:
- Fixed bug that caused "Work queue empty, miner is idle" on block changes.
- Fixed bug with RPC+LP servers when using some older versions of Twisted.
- Askrate now defaults to 10 for RPC servers without LP (previously it would request work only when needed, which can be >30 seconds on slower hardware)
- Fixed a dumb bug in RPC where it would stop trying to reconnect if it lost connection to a LP enabled server.
- Fixed error in some cases when the kernel's work cache is cleared on block change.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: Veldy on May 01, 2011, 03:37:07 AM
We certainly appreciate everyone rushing to try it, and provide feedback. Thank you very much!

We know what the problem with speed is. Our test environment uses SDK 2.4, which didn't require a worksize since the default of 256 was providing the best results. We're adding a WORKSIZE option to the kernel right now, (an equivalent to poclbm's -w) that should help you tweak it a bit more for other SDK versions.

Thank you for your patience!


I know that this is a little old now, but I thought I would throw in one stat.  With poclbm, -w 128 peforms FAR better than -w 256 on the 6970 and almost certainly the same goes for the 6990.  Are there any ATI/AMD cards out there that actually work better with 256 used?

This may have more to do with the type of work being done than with the hardware, SDK or capabilities of the card, but I am just hypothesizing about that.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: twich12 on May 01, 2011, 04:45:42 AM
quick noob question... what should my command line look like for solo mining with phoenix 1.3?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner
Post by: jedi95 on May 01, 2011, 05:10:56 AM
We certainly appreciate everyone rushing to try it, and provide feedback. Thank you very much!

We know what the problem with speed is. Our test environment uses SDK 2.4, which didn't require a worksize since the default of 256 was providing the best results. We're adding a WORKSIZE option to the kernel right now, (an equivalent to poclbm's -w) that should help you tweak it a bit more for other SDK versions.

Thank you for your patience!


I know that this is a little old now, but I thought I would throw in one stat.  With poclbm, -w 128 peforms FAR better than -w 256 on the 6970 and almost certainly the same goes for the 6990.  Are there any ATI/AMD cards out there that actually work better with 256 used?

This may have more to do with the type of work being done than with the hardware, SDK or capabilities of the card, but I am just hypothesizing about that.

With SDK 2.4 I get better results on my 5870 with 256 worksize vs 128. This option was added so users could pick the optimal worksize for their own configuration as with poclbm.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on May 01, 2011, 05:55:03 AM
I tired around with 3-5 hours to see the difference btw 128 & 256 worksize with pocblm some 4-5 weeks back.
Even though -w256 gives more hash, i got ~3Mhash more from 269MH to 273MH, the number of shares submitted per hour get reduced.
-W128 mines with 1-5 less Mhash, but the number of shares submitted was more.
So, on end the number of shares submitted only speaks.
Have to test worksize 256 & 128 with phoenix.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on May 01, 2011, 09:42:59 AM
You might be interested in my other project, Multiminer, which we use for our (jedi95 and I) cluster's status page (http://129.82.65.171:8882/). I have a Windows download here (http://cloud.github.com/downloads/CFSworks/multiminer/multiminer-1.4.zip) (or you can get the source off GitHub (https://github.com/CFSworks/multiminer)) and it's pretty easy to run:

multiminer --admin-user=admin --admin-pass=admin101 --web-port=80 --url=http://PoolUsername:PoolPassword@PoolHost:8332/

Then change your Phoenix URLs to mmp://admin:admin101@localhost?name=NameForThisWorker (Phoenix already supports the protocol)
And finally you can throw JSON-RPC requests at http://admin:admin101@localhost - try listconnections() to see your worker status.
You can also put an index.html in "www" and have it do some JQuery magic to view your workers.

The only drawback is Multiminer doesn't have its own logs (yet), but you will know it's working when your miners pick up work and start mining through it.

Hi CFSworks, I am intrigue by how to get this to run locally on my bitcoind server. I was testing out with different askrates and found this post which seems like a efficient way to distribute work to the miners. My question is if I have a pc running bitcoind server, should I run the multiminer on that server? Also what are the --admin-user and --admin-pass indicating? Are they the bitcoin.config file password? Also I dont plan to display this information on a webpage as I do not have a webserver running, so does that mean that I dont have to run web port 80? Thanks!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on May 01, 2011, 09:55:33 AM
Hi CFSworks, I am intrigue by how to get this to run locally on my bitcoind server. I was testing out with different askrates and found this post which seems like a efficient way to distribute work to the miners. My question is if I have a pc running bitcoind server, should I run the multiminer on that server? Also what are the --admin-user and --admin-pass indicating? Are they the bitcoin.config file password? Also I dont plan to display this information on a webpage as I do not have a webserver running, so does that mean that I dont have to run web port 80? Thanks!

Glad to hear you're interested!

The --url argument works exactly the same way as -u in Phoenix. In fact, it uses the exact same code, so anything usable with Phoenix works with that.
The admin-user and admin-pass arguments specify the administrator account on Multiminer, which can be used to log workers into the server and, since it is an administrator, hit Multiminer with JSON-RPC queries.

In short, you would use something like this:
multiminer --admin-user=admin --admin-pass=admin101 --web-port=80 --url=http://BitcoinUsername:BitcionPassword@localhost:8332/
EDIT: You can also specify a parameter like -b 30 and it will send 1/4 the work to each miner, which is a bit more efficient. You'd have to play with it a little though.
EDIT: As with Phoenix 1.4, the default askrate is 10, but you can change it with ;askrate=X, as in Phoenix.

And then you would connect Phoenix to Multiminer via MMP, with this URL: mmp://admin:admin101@localhost?name=SomeName

Of course, you are free to change the username and password for the admin account.

It's also worth noting that Multiminer is a complete webserver (the web-port=80 makes it run on the default HTTP port) that serves pages from the "www" directory, which means you can put a stats page in there to quickly see how your miners are doing, which is what jedi95 and I did.
You can also hit it with JSON-RPC requests. It's compatible with RPC miners (although it doesn't offer long-polling yet)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on May 01, 2011, 10:14:26 AM

Glad to hear you're interested!

The --url argument works exactly the same way as -u in Phoenix. In fact, it uses the exact same code, so anything usable with Phoenix works with that.
The admin-user and admin-pass arguments specify the administrator account on Multiminer, which can be used to log workers into the server and, since it is an administrator, hit Multiminer with JSON-RPC queries.

In short, you would use something like this:
multiminer --admin-user=admin --admin-pass=admin101 --web-port=80 --url=http://BitcoinUsername:BitcionPassword@localhost:8332/
EDIT: You can also specify a parameter like -b 30 and it will send 1/4 the work to each miner, which is a bit more efficient. You'd have to play with it a little though.
EDIT: As with Phoenix 1.4, the default askrate is 10, but you can change it with ;askrate=X, as in Phoenix.

And then you would connect Phoenix to Multiminer via MMP, with this URL: mmp://admin:admin101@localhost?name=SomeName

Of course, you are free to change the username and password for the admin account.

It's also worth noting that Multiminer is a complete webserver (the web-port=80 makes it run on the default HTTP port) that serves pages from the "www" directory, which means you can put a stats page in there to quickly see how your miners are doing, which is what jedi95 and I did.
You can also hit it with JSON-RPC requests. It's compatible with RPC miners (although it doesn't offer long-polling yet)

Hi thanks for the prompt and comprehensive guide. Please advice on my current bat file, I have the client reporting that failed to connect retrying.

Server
start /DD:\multiminer-1.4 multiminer.exe --admin-user=btc --admin-pass=asdqwe --web-port=80 -b 30 --url=btc:asdqwe:8332/

Client

start /DZ:\Dropbox\BTC\phoenix phoenix.exe -u mmp://btc:asdqwe@192.168.1.8?5850/ DEVICE=0 VECTORS AGGRESSION=7 FASTLOOP -v BFI_INT -k poclbm

Also with regards to webserver, is it the ip address of the bitcoind server? Meaning if its 192.168.1.8 its just 192.168.1.8/8883 when entering into the web browser? Also After executing the multiminer does it show a cmd window ? Cuz when i did run it closes immediately.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on May 01, 2011, 10:24:29 AM
Try this:

Server
Code:
start /DD:\multiminer-1.4 multiminer.exe --admin-user=btc --admin-pass=asdqwe --web-port=80 -b 30 --url=http://btc:asdqwe@localhost:8332/

Client
Code:
start /DZ:\Dropbox\BTC\phoenix phoenix.exe -u mmp://btc:asdqwe@192.168.1.8?name=5850 -k poclbm DEVICE=0 VECTORS AGGRESSION=7 FASTLOOP BFI_INT

And yes, the webserver in that case would be http://192.168.1.8/ and it would serve up your D:\multiminer-1.4\www\index.html file... If you want it to display a status page, you might have to ask someone to put together an index.rpy to show status. The one jedi95 and I made is pretty disorganized and we'd rather not put it out in the open, but if you ask around I'm sure you'll be able to find someone happy to build one for you.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on May 01, 2011, 11:20:54 AM
Traceback (most recent call last):
  File "multiminer.py", line 114, in <module>
  File "multiminer.py", line 109, in main
  File "ClusterServer.pyc", line 102, in start
  File "WebServer.pyc", line 39, in start
  File "twisted\internet\posixbase.pyc", line 419, in listenTCP
  File "twisted\internet\tcp.pyc", line 857, in startListening
twisted.internet.error.CannotListenError: Couldn't listen on any:80: [Errno 1004
8] Only one usage of each socket address (protocol/network address/port) is norm
ally permitted.

Hi this is what I got from the error message after editting the script to the one you mentioned


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on May 01, 2011, 11:32:24 AM
Oh solved it...I think the teamviewer is using port 80. Btw thanks for your help. Is mmp more efficient compared to the usual rpc?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 01, 2011, 11:37:23 AM
Oh solved it...I think the teamviewer is using port 80. Btw thanks for your help. Is mmp more efficient compared to the usual rpc?

It is, see this from the original Multiminer thread:

Quote
It's also considerably more efficient than JSON-RPC: Requesting more work from the server requires 6 bytes from the client and 170 from the server. (Compare this with 47/605 for JSON-RPC... and that's not counting HTTP headers)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kindle on May 01, 2011, 11:43:50 AM



It's also considerably more efficient than JSON-RPC: Requesting more work from the server requires 6 bytes from the client and 170 from the server. (Compare this with 47/605 for JSON-RPC... and that's not counting HTTP headers)


Hi im curious as to how this is compared to pool mining. After using pool mining for awhile, I was thinking of using the same approach (smaller work difficulty to individual miners) for the local mining rigs set up. So far using bitcoind and mmp it seems like it is not the same compared to pool mining approach. As the more gpu is added to my local network, I guess running it like a mini pool would be more efficient compared to all connected using the normal method?

Btw running the multiminer, the cmd does not reflect anything after I keyed the command strings in. Is that normal ?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: anatolikostis on May 01, 2011, 06:05:26 PM
I don`t know about other phoenix versions but it seems that new gui miner has similar speed. ::)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: subotai on May 01, 2011, 07:28:27 PM
Some chance to see the version of the Cuda miner :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slush on May 02, 2011, 08:24:53 PM
jedu95, thanks for new very fast miner. I have one question - many users complaining about connection troubles while using more computers with my pool. Do you have any idea why it should not work? All other miners - poclbm, diablo, jgarzik etc does not have such problem. I don't have any limits on RPC connection, so I don't see the reason why it should not work... Thanks for your reply in advance.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 02, 2011, 10:57:01 PM
jedu95, thanks for new very fast miner. I have one question - many users complaining about connection troubles while using more computers with my pool. Do you have any idea why it should not work? All other miners - poclbm, diablo, jgarzik etc does not have such problem. I don't have any limits on RPC connection, so I don't see the reason why it should not work... Thanks for your reply in advance.

I looked into this but I can't see any reason that the miner would be unable to connect to some pools but work fine on others. I can't reproduce the problem either, so it's likely that the problem was system specific and not miner specific.

The problems I was having with slushes pool have gone away and it will now connect. I noticed this was happening with other miners as well so I don't think this was ever anything specific to Phoenix.

If anyone else is having this problem please post your system details and the command line you are using. Also please try with other miners too, since if other miners do it as well you probably have a system issue.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on May 02, 2011, 11:00:11 PM
If anyone else is having this problem please post your system details and the command line you are using. Also please try with other miners too, since if other miners do it as well you probably have a system issue.

did you try mining from two PCs, both using the same external IP? I think that's the condition which triggers the problem.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 02, 2011, 11:08:15 PM
If anyone else is having this problem please post your system details and the command line you are using. Also please try with other miners too, since if other miners do it as well you probably have a system issue.

did you try mining from two PCs, both using the same external IP? I think that's the condition which triggers the problem.

I tried 3 computes at once with a total of 9 instances of Phoenix. It worked as expected.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on May 02, 2011, 11:54:23 PM
I tried 3 computes at once with a total of 9 instances of Phoenix. It worked as expected.

I have debian squeeze, clean install. which package versions do you need?

python-pyopencl                                                          0.92-1
ati-opencl-runtime                                                       2.1
python-twisted                                                           10.1.0-3
python                                                                   2.6.6-3+squeeze2

kernel  2.6.32-5-686

anything else?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slush on May 02, 2011, 11:57:31 PM
I tried 3 computes at once with a total of 9 instances of Phoenix. It worked as expected.

I tried it on my two rigs and had this problem, too. It must be specific to the miner, because I used diablo and poclbm without any problem before.

Once I started at least one phoenix miner, other miners on second machine suddenly stopped working. More phoenix miners on the same machine works without problem. I tried to stop pool's firewall (where are some advanced anti-DoS techniques enabled), but no difference. Currently I have absolute no idea where the problem can be and problem indices sounds really weird. My two rigs aren't linked together in any way, they are even mining under separate pool accounts and I have no other limitations on the pool except the firewall. As this problem occured only with phoenix, there must be _something_ different than in other miners... Still no idea?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 03, 2011, 12:25:30 AM
I tried 3 computes at once with a total of 9 instances of Phoenix. It worked as expected.

I tried it on my two rigs and had this problem, too. It must be specific to the miner, because I used diablo and poclbm without any problem before.

Once I started at least one phoenix miner, other miners on second machine suddenly stopped working. More phoenix miners on the same machine works without problem. I tried to stop pool's firewall (where are some advanced anti-DoS techniques enabled), but no difference. Currently I have absolute no idea where the problem can be and problem indices sounds really weird. My two rigs aren't linked together in any way, they are even mining under separate pool accounts and I have no other limitations on the pool except the firewall. As this problem occured only with phoenix, there must be _something_ different than in other miners... Still no idea?

I will have CFSworks take a look at the RPC protocol implementation, since he was the one who worked on that part of Phoenix. I mostly understand how it works, but if I can't see this problem occur for myself I don't know where to start.

We might end up needing to give you a modified build that logs additional info when this happens if we can't find the problem.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slush on May 03, 2011, 12:28:07 AM
We might end up needing to give you a modified build that logs additional info when this happens if we can't find the problem.

Good idea, if you add hooks to correct places, I can collect some logs for further investigation...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tripper22 on May 03, 2011, 04:30:21 AM
I tried 3 computes at once with a total of 9 instances of Phoenix. It worked as expected.

I tried it on my two rigs and had this problem, too. It must be specific to the miner, because I used diablo and poclbm without any problem before.

Once I started at least one phoenix miner, other miners on second machine suddenly stopped working. More phoenix miners on the same machine works without problem. I tried to stop pool's firewall (where are some advanced anti-DoS techniques enabled), but no difference. Currently I have absolute no idea where the problem can be and problem indices sounds really weird. My two rigs aren't linked together in any way, they are even mining under separate pool accounts and I have no other limitations on the pool except the firewall. As this problem occured only with phoenix, there must be _something_ different than in other miners... Still no idea?

It's nice to be right. I had the same issue and I narrowed it down to the Phoenix miner. I told slush about this problem yesterday.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Adeq on May 03, 2011, 05:44:01 AM
How many M/s can be achieved on the Radeon HD5850?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BitLex on May 03, 2011, 05:58:33 AM
How many M/s can be achieved on the Radeon HD5850?

depends on gpuclock/bios and miner-settings,
~295Mhash/s @775MHz
~345Mhash/s @900MHz


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Adeq on May 03, 2011, 06:29:07 AM
Ok. Thanks for reply.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slush on May 03, 2011, 02:51:54 PM
It's nice to be right...

...and I promised that I'll test it soon :).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: sanchaz on May 03, 2011, 02:53:10 PM
How many M/s can be achieved on the Radeon HD5850?

depends on gpuclock/bios and miner-settings,
~295Mhash/s @775MHz
~345Mhash/s @900MHz

i get 270Mhash/s @ 725Mhz (stock clock, memory at 300 or 1000 doesnt really make a difference)

do u change the voltage to get 775 or 900?, or do i just need to put it at 775 or 900 (i doubt it will do 900 without voltage ajustment, but doesnt hurt to ask)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on May 03, 2011, 03:13:29 PM
I like to know what DEVICE each miner is running on. And in cssh I'm using very compact terminals, so they all fit on a screen, so I like more compact status line. Here's a diff for anyone interested:

Code:
Index: phoenix.py
===================================================================
--- phoenix.py  (revision 56)
+++ phoenix.py  (working copy)
@@ -110,6 +110,7 @@
                 exit()
             kernelModule = imp.load_module(module, file, filename, smt)
             self.kernel = kernelModule.MiningKernel(requester)
+           self.logger.DEVICE = self.kernel.DEVICE
         return self.kernel

     def makeQueue(self, requester):
@@ -122,4 +123,4 @@
     miner = Miner()
     miner.start(options)

-    reactor.run()
\ No newline at end of file
+    reactor.run()
Index: ConsoleLogger.py
===================================================================
--- ConsoleLogger.py    (revision 56)
+++ ConsoleLogger.py    (working copy)
@@ -56,6 +56,7 @@
         self.lineLength = 0
         self.connectionType = None
         self.idle = False
+       self.DEVICE = -1

     def reportRate(self, rate, update=True):
         """Used to tell the logger the current Khash/sec."""
@@ -115,9 +116,9 @@
             rate = self.rate if (not self.idle) else 0
             type = " [" + str(self.connectionType) + "]" if self.connectionType is not None else ''
             status = (
-                "[" + formatNumber(rate) + "hash/sec] "
-                "[" + str(self.accepted) + " Accepted] "
-                "[" + str(self.invalid) + " Rejected]" + type)
+                "[" + formatNumber(rate) + "Hs/s] "
+                "[" + str(self.accepted) + " Acc] "
+                "[" + str(self.invalid) + " Rej]" + type + " [D "+str(self.DEVICE)+"]")
             self.say(status)
             self.lastUpdate = time()

@@ -152,4 +153,4 @@
         self.say(message, True, hideTimestamp)
         if update:
             self.updateStatus(True)
-       
\ No newline at end of file


I am learning python, so I am sure that this can be written in a better way. I would like to learn in which way? Anyway, this diff will produce a status line like this:

Code:
[298.44 MHs/s] [15 Acc] [0 Rej] [RPC (+LP)] [D 3]

the last number is the device number.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on May 03, 2011, 04:40:56 PM
I think that I have found a bug in your miner.

If the solving nonce is ZERO it is silently ignored. But you already have a framework introduced specifically to avoid this problem!

This happens because you check if last item in self.output[self.OUTPUT_SIZE] is not zero:
Code:
       if self.output[self.OUTPUT_SIZE]:
                reactor.callFromThread(self.postprocess, self.output.copy(),
                data.nr)

and in openCL kernel you assign nonce to it:

Code:
#ifdef VECTORS
        if (H.x == 0)
        {
                output[OUTPUT_SIZE] = output[nonce.x & OUTPUT_MASK] = nonce.x;
        }
        else if (H.y == 0)
        {
                output[OUTPUT_SIZE] = output[nonce.y & OUTPUT_MASK] = nonce.y;
        }
#else
        if (H == 0)
        {
                output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;
        }
#endif

I think that following patch will fix the bug:

Code:
Index: kernels/poclbm/kernel.cl
===================================================================
--- kernels/poclbm/kernel.cl    (revision 56)
+++ kernels/poclbm/kernel.cl    (working copy)
@@ -296,16 +296,20 @@
 #ifdef VECTORS
        if (H.x == 0)
        {
-               output[OUTPUT_SIZE] = output[nonce.x & OUTPUT_MASK] = nonce.x;
+               output[OUTPUT_SIZE] = 1;
+               output[nonce.x & OUTPUT_MASK] = nonce.x;
        }
        else if (H.y == 0)
        {
-               output[OUTPUT_SIZE] = output[nonce.y & OUTPUT_MASK] = nonce.y;
+               output[OUTPUT_SIZE] = 1;
+               output[nonce.y & OUTPUT_MASK] = nonce.y;
        }
 #else
        if (H == 0)
        {
-               output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;
+               output[OUTPUT_SIZE] = 1;
+               output[nonce & OUTPUT_MASK] = nonce;
        }
 #endif
-}
\ No newline at end of file
+}
+

how do you think?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on May 03, 2011, 04:57:16 PM
Hmm.. ok, this patch will not solve the problem, because later in postprocess you are again checking against zero:

Code:
        for i in xrange(self.OUTPUT_SIZE):
            if output[i]:

but it's still possible to fix it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Hawkix on May 03, 2011, 04:59:57 PM
Is the hashrate of the Phoenix miner reported accurately?

I found out that using AGGRESSION=11 I can get up to 2x 400 MH/sec on 2x Radeon HD5870 at 965/300 clocks. The GPU usage is above 97% and the cards generate a lot of heat and the GUI is very irresponsible.

Surprisingly, using AGGRESSION=7 FASTLOOP I can get up to 2x430 MH/sec (!!!) while the GUI is slowed just a bit and the GPU usage is about 92% and the cards are a lot cooler. The power consumption lowers, too.

I mine using deepbit.net and its reported hashrate varies a lot, so I cannot count on it.

Does simply higher local reported hashrate mean *always* faster calculation and more per-day yield? Or is the hashrate reported in Phoenix also just approximate and may vary depending on various system settings (clocks, latency, etc.)?




Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tripper22 on May 03, 2011, 05:05:19 PM
It's nice to be right...

...and I promised that I'll test it soon :).

Yes you did. ;D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on May 03, 2011, 05:14:08 PM
Hmm.. ok, this patch will not solve the problem, because later in postprocess you are again checking against zero:

Code:
        for i in xrange(self.OUTPUT_SIZE):
            if output[i]:

but it's still possible to fix it.

OK, so how about this fix:

Code:
Index: kernels/poclbm/kernel.cl
===================================================================
--- kernels/poclbm/kernel.cl    (revision 56)
+++ kernels/poclbm/kernel.cl    (working copy)
@@ -296,16 +296,32 @@
 #ifdef VECTORS
        if (H.x == 0)
        {
-               output[OUTPUT_SIZE] = output[nonce.x & OUTPUT_MASK] = nonce.x;
+               if(nonce.x == 0) {
+                       output[OUTPUT_SIZE] = 2;
+               } else {
+                       output[OUTPUT_SIZE] = 1;
+                       output[nonce.x & OUTPUT_MASK] = nonce.x;
+               }
        }
-       else if (H.y == 0)
+       if (H.y == 0) // without "else" clause, because it can happen that both nonces are a solution
        {
-               output[OUTPUT_SIZE] = output[nonce.y & OUTPUT_MASK] = nonce.y;
+               if(nonce.y == 0) {
+                       output[OUTPUT_SIZE] = 2;
+               } else {
+                       output[OUTPUT_SIZE] = 1;
+                       output[nonce.y & OUTPUT_MASK] = nonce.y;
+               }
        }
 #else
        if (H == 0)
        {
-               output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;
+               if(nonce == 0) {
+                       output[OUTPUT_SIZE] = 2;
+               } else {
+                       output[OUTPUT_SIZE] = 1;
+                       output[nonce & OUTPUT_MASK] = nonce;
+               }
        }
 #endif
-}
\ No newline at end of file
+}
+
Index: kernels/poclbm/__init__.py
===================================================================
--- kernels/poclbm/__init__.py  (revision 56)
+++ kernels/poclbm/__init__.py  (working copy)
@@ -346,12 +346,21 @@
         # Iterate over only the first OUTPUT_SIZE items. Exclude the last item
         # which is a duplicate of the most recently-found nonce.
         for i in xrange(self.OUTPUT_SIZE):
            if output[i]:   
                 if not self.interface.foundNonce(nr, int(output[i])):
                     hash = self.interface.calculateHash(nr, int(output[i]))
                     if not hash.endswith('\x00\x00\x00\x00'):
                         self.interface.error('Unusual behavior from OpenCL. '
                             'Hardware problem?')
+        if(self.output[self.OUTPUT_SIZE] == 2):
+            self.interface.log("Nearly impossible happened! Found solving nonce which is ZERO !")
+            if not self.interface.foundNonce(nr, 0):
+                hash = self.interface.calculateHash(nr, 0)
+                if not hash.endswith('\x00\x00\x00\x00'):
+                    self.interface.error('Unusual behavior from OpenCL. '
+                        'Hardware problem?')
     
     def mineThread(self):
         for data in self.qr:
@@ -376,11 +385,14 @@
             # The OpenCL code will flag the last item in the output buffer when
             # it finds a valid nonce. If that's the case, send it to the main
             # thread for postprocessing and clean the buffer for the next pass.
-            if self.output[self.OUTPUT_SIZE]:
+            if(self.output[self.OUTPUT_SIZE] > 0):
                 reactor.callFromThread(self.postprocess, self.output.copy(),
                 data.nr)
             
                 self.output.fill(0)
                 cl.enqueue_write_buffer(
                     self.commandQueue, self.output_buf, self.output)



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Clavulanic on May 04, 2011, 04:40:47 AM
I just wanted clarification on running a dual GPU setup. From what I understand is you simply need to run a second instance of this problem contained in a separate folder AND you change device=0 to device=1.
Also, do you have to have the second one connected to a monitor or a dummy plug? Or can you someone do that in the code.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on May 04, 2011, 06:00:34 AM
I think that I have found a bug in your miner.

If the solving nonce is ZERO it is silently ignored. But you already have a framework introduced specifically to avoid this problem!

This happens because you check if last item in self.output[self.OUTPUT_SIZE] is not zero:

That particular caveat did bother me a little while I was writing the postprocess function...
I think the easiest fix might be to unconditionally check the 0-nonce in the CPU before doing any mining in the GPU...

I'm torn. On one hand I want to fix this... But on the other hand, since the possibility of a block both passing both the
H=0 requirement to get returned to the host and the nonce=0 requirement to get discarded by the caveat is highly improbable,
(1 in 2^64) it might be better to choose simplicity over correctness/completeness in this case.

I just wanted clarification on running a dual GPU setup. From what I understand is you simply need to run a second instance of this problem contained in a separate folder AND you change device=0 to device=1.
Also, do you have to have the second one connected to a monitor or a dummy plug? Or can you someone do that in the code.

You don't even need to put it in a separate folder. Just start start it twice: one instance with DEVICE=0 and the other with DEVICE=1.
You will probably need a dummy plug if you're on Windows. I don't know enough to say, though.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: casascius on May 04, 2011, 06:27:29 AM
I think that I have found a bug in your miner.

If the solving nonce is ZERO it is silently ignored. But you already have a framework introduced specifically to avoid this problem!

This happens because you check if last item in self.output[self.OUTPUT_SIZE] is not zero:

That particular caveat did bother me a little while I was writing the postprocess function...
I think the easiest fix might be to unconditionally check the 0-nonce in the CPU before doing any mining in the GPU...

I'm torn. On one hand I want to fix this... But on the other hand, since the possibility of a block both passing both the
H=0 requirement to get returned to the host and the nonce=0 requirement to get discarded by the caveat is highly improbable,
(1 in 2^64) it might be better to choose simplicity over correctness/completeness in this case.


Wouldn't it be best to just not worry?  That equates to a loss of 1/2^32 of hashing power, or a loss of 0.00000002%.  The CPU cycles expended in making sure that zero nonce was always covered would cause a greater net loss.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on May 04, 2011, 06:38:33 AM
Wouldn't it be best to just not worry?  That equates to a loss of 1/2^32 of hashing power, or a loss of 0.00000002%.  The CPU cycles expended in making sure that zero nonce was always covered would cause a greater net loss.

1/2^64, since the hash must first be low enough (1/2^32) for the GPU to try to send it back to the CPU before the nonce=0 caveat is even a factor.
It's a good exercise to identify and work out a solution to the problem, but in practice it's really not worthwhile to worry about. :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cosurgi on May 04, 2011, 05:22:42 PM
I'm torn. On one hand I want to fix this... But on the other hand, since the possibility of a block both passing both the
H=0 requirement to get returned to the host and the nonce=0 requirement to get discarded by the caveat is highly improbable,

Heh I know. But I'm perfectionist here, and modified OpenCL code has only 1/2^32 chance of actually being slower in execution, because it's all enclosed inside an "if" conditional. So it isn't making calculations any slower, actually.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nelisky on May 04, 2011, 05:42:04 PM
I'm torn. On one hand I want to fix this... But on the other hand, since the possibility of a block both passing both the
H=0 requirement to get returned to the host and the nonce=0 requirement to get discarded by the caveat is highly improbable,

Heh I know. But I'm perfectionist here, and modified OpenCL code has only 1/2^32 chance of actually being slower in execution, because it's all enclosed inside an "if" conditional. So it isn't making calculations any slower, actually.


Beware, though, that 'if' statements make paralel optimization harder and the opencl runtime may end up being a LOT slower with a simple conditional branch command that looks all innocent.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: UnluckyMiner on May 05, 2011, 04:55:18 AM
Has anyone seen this error:

Code:
$ ./phoenix.py -u http://bitcoin:password@localhost:8332/ -k poclbm DEVICE=0 VECTORS AGGRESSION=3
Traceback (most recent call last):
  File "./phoenix.py", line 123, in <module>
    miner.start(options)
  File "/phoenix-miner/trunk/Miner.py", line 76, in start
    self.kernel = self.options.makeKernel(KernelInterface(self))
  File "./phoenix.py", line 112, in makeKernel
    self.kernel = kernelModule.MiningKernel(requester)
  File "kernels/poclbm/__init__.py", line 125, in __init__
    platforms = cl.get_platforms()
pyopencl.LogicError: clGetPlatformIDs failed: platform not found khr

Professor Google doesn't seem to know anything about this issue, and I can't seem to figure out why it is happening. I have basically the same error when trying to run poclbm by itself.

Any help would be greatly appreciated!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: AltPluzF4 on May 05, 2011, 04:59:13 AM
Has anyone seen this error:

Code:
$ ./phoenix.py -u http://bitcoin:password@localhost:8332/ -k poclbm DEVICE=0 VECTORS AGGRESSION=3
Traceback (most recent call last):
  File "./phoenix.py", line 123, in <module>
    miner.start(options)
  File "/phoenix-miner/trunk/Miner.py", line 76, in start
    self.kernel = self.options.makeKernel(KernelInterface(self))
  File "./phoenix.py", line 112, in makeKernel
    self.kernel = kernelModule.MiningKernel(requester)
  File "kernels/poclbm/__init__.py", line 125, in __init__
    platforms = cl.get_platforms()
pyopencl.LogicError: clGetPlatformIDs failed: platform not found khr

Professor Google doesn't seem to know anything about this issue, and I can't seem to figure out why it is happening. I have basically the same error when trying to run poclbm by itself.

Any help would be greatly appreciated!

What video card are you using? I personally get a similar error when I use the VECTORS argument with my GTX260


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: UnluckyMiner on May 05, 2011, 05:00:47 AM
Quote
What video card are you using? I personally get a similar error when I use the VECTORS argument with my GTX260

AMD/ATI 6990


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on May 05, 2011, 07:24:31 AM
Quote
What video card are you using? I personally get a similar error when I use the VECTORS argument with my GTX260

AMD/ATI 6990

The AMD/ATI SDK is not installed properly. Did you do all the steps in this document (http://developer.amd.com/gpu/amdappsdk/assets/ATI_Stream_SDK_Installation_Notes.pdf) (look under section 2.2)?
If so, take a second look at the ICD registration step, since that's necessary for any OpenCL anything to work on your system.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: rarefied on May 05, 2011, 02:57:25 PM
I am also running into the RPC lockout problem.  My setup is two HD6990s on two machines behind NAT with a single public IP.  I'm able to start two copies of phoenix on one machine, but then no other machine behind my NAT can contact mining.bitcoin.cz either for RPC or just to browse the web site.  At first I thought it was the large number of TCP connections created as I had 70 or so connections from the one machine on which phoenix was running.  However using DiabloMiner I'm able to launch an instance on each machine and the number of active connections jumps up to 130 or so.  I'm running the following on Ubuntu 11.04:

  • Python 2.7.1
  • pyopencl 2011.1beta3
  • boost 1.42
  • twisted 10.2

Thanks for the great miner.  It increases performance on my 6990s from about 530 Mhash/sec to 670 Mhash/sec using the BFI_INT instruction!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slush on May 05, 2011, 03:25:36 PM
I found that phoenix isn't using keep alive, but for every RPC call it open separate connection. I'm pretty sure that's the reason for troubles connecting to my pool; I introduced pretty strict rules after last DoS attacks, but using keep-alive in miners, people should not hit those limits at all (at least not with few rigs from one IP).

As this issue affect my pool, I offer 15 BTC to anybody who pull keep-alive patch for phoenix (in fact it should be relatively simple as phoenix is coded clearly).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Dayofswords on May 05, 2011, 10:52:34 PM
As this issue affect my pool, I offer 15 BTC to anybody who pull keep-alive patch for phoenix (in fact it should be relatively simple as phoenix is coded clearly).

If only I knew remotely how, after a few months, I've earn 1/3 of that at your pool.(I found one block through, too bad i was in a pool for it, i could have had 50!)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 05, 2011, 11:39:45 PM
I found that phoenix isn't using keep alive, but for every RPC call it open separate connection. I'm pretty sure that's the reason for troubles connecting to my pool; I introduced pretty strict rules after last DoS attacks, but using keep-alive in miners, people should not hit those limits at all (at least not with few rigs from one IP).

As this issue affect my pool, I offer 15 BTC to anybody who pull keep-alive patch for phoenix (in fact it should be relatively simple as phoenix is coded clearly).

Thanks for getting to the bottom of this issue. Now that we know what's wrong we can fix it.

The only complication is that the Twisted library we use for the RPC protocol implementation doesn't support keep-alive. This makes it a bit more complex to fix, but we should have it done shortly. Our plan is to use a more up-to-date part of the Twisted library that supports keep-alive.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Herodes on May 06, 2011, 01:38:11 AM

Dual 5970 rig. Win 7 64 bit. SDK 2.4
Miner Phoenix 1.3


Every time I reboot the pc, my worker scripts run, they look like

cd c:\bitcoin\phoenix
phoenix -u http://user@domain.com_1:pass@poolsite.com:8332 -k poclbm DEVICE=n -v VECTORS BFI_INT AGRESSION=11

Of course one device for each bat file (0 through 3).

One of the cards have a troubled GPU. No matter which slot I use in the machine, it never runs for long. It runs for a very short while, then it freeze.

Sample message at a freeze:
Code:
325.80 Mhash/sec [2 Accepted] [0 Rejected] [RPC (+LP)]. Then GPU activity drops to zero.


http://imageshack.us/photo/my-images/859/gpuactivity.png/

Any ideas?



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 06, 2011, 01:45:33 AM
I have a question, i trying to run Phoenix under WinPE 3.0, but i cant run any python app... it just gives a "Cant start application, the parallel config is incorrent, etc"

I also tried installing Python itselft in WinPE, and it does install OK, but is the same error trying to launch the python.exe. ANy ideas???


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JesusTheCaffeine on May 06, 2011, 02:09:39 AM
I'm pulling in 365 Mh/s on my 6970 clocked at 950/1375.

Debian linux
SDK 2.4
Command: python phoenix.py -u http://DERP@mining.bitcoin.cz:8332 -k poclbm BFI_INT AGGRESSION=11 DEVICE=0


When I pass vectors it slows down to 330mh/s  ???



I get the same results in Windows 7, any other 6970/6950 users getting any higher?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on May 06, 2011, 02:28:54 AM
Any ideas?

All I can say is that you should try SDK versions older than 2.4, or use a different driver version.
The error looks like OpenCL is quitting mid-work. The fact that it's happening on only one GPU makes me suspect hardware trouble. :(

I have a question, i trying to run Phoenix under WinPE 3.0, but i cant run any python app... it just gives a "Cant start application, the parallel config is incorrent, etc"

I also tried installing Python itselft in WinPE, and it does install OK, but is the same error trying to launch the python.exe. ANy ideas???

That error message is pretty confusing, but some Google searching around says that you should try installing this (http://www.microsoft.com/downloads/en/details.aspx?familyid=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en) in your PE.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Herodes on May 06, 2011, 02:43:08 AM
Any ideas?

All I can say is that you should try SDK versions older than 2.4, or use a different driver version.
The error looks like OpenCL is quitting mid-work. The fact that it's happening on only one GPU makes me suspect hardware trouble. :(

Thanks for your answer. I've tried to run the card with the troubling GPU alone in the rig, then both the main and slave gpu of that card just runs very happily, but once both cards (5970) are in the machine, this problem occurs again. The problem occur no matter which PCI-slot a specific card is connected to.

When you learn this, would you still suspect that the hw is faulty? Is there a program that I can use to test this? Btw Both GPU-Z and GPuCaps hangs when I try starting them.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 06, 2011, 04:14:30 AM
That error message is pretty confusing, but some Google searching around says that you should try installing this (http://www.microsoft.com/downloads/en/details.aspx?familyid=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en) in your PE.

yup, its the "The application has failed to start because its side-by-side configuration is incorrect.", the problem is, VC2008 redistributable cant be installed on WinPE :S Maybe placing the .dlls on the same directory as phoenix?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: zoro on May 06, 2011, 04:52:32 AM
I'm pulling in 365 Mh/s on my 6970 clocked at 950/1375.

Debian linux
SDK 2.4
Command: python phoenix.py -u http://DERP@mining.bitcoin.cz:8332 -k poclbm BFI_INT AGGRESSION=11 DEVICE=0


When I pass vectors it slows down to 330mh/s  ???



I get the same results in Windows 7, any other 6970/6950 users getting any higher?

400Μh/s
-k poclbm DEVICE=0 VECTORS AGGRESSION=12 WORKSIZE=128 BFI_INT
win7 x86  catalyst 11.3
930/350


a question about solo mining:
if a miner says:
warning: work queue empty, miner is idle
should i restart the miner?
the hashes are running though :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JesusTheCaffeine on May 06, 2011, 06:51:40 AM
I'm pulling in 365 Mh/s on my 6970 clocked at 950/1375.

Debian linux
SDK 2.4
Command: python phoenix.py -u http://DERP@mining.bitcoin.cz:8332 -k poclbm BFI_INT AGGRESSION=11 DEVICE=0


When I pass vectors it slows down to 330mh/s  ???



I get the same results in Windows 7, any other 6970/6950 users getting any higher?

400Μh/s
-k poclbm DEVICE=0 VECTORS AGGRESSION=12 WORKSIZE=128 BFI_INT
win7 x86  catalyst 11.3
930/350

Bah, any sdk except 2.4 just doesn't want to work with me in debian.

I have to live with 365 :/


a question about solo mining:
if a miner says:
warning: work queue empty, miner is idle
should i restart the miner?
the hashes are running though :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on May 06, 2011, 11:36:06 AM
Dual 5970 rig. Win 7 64 bit. SDK 2.4
Miner Phoenix 1.3

Every time I reboot the pc, my worker scripts run, they look like

cd c:\bitcoin\phoenix
phoenix -u http://user@domain.com_1:pass@poolsite.com:8332 -k poclbm DEVICE=n -v VECTORS BFI_INT AGRESSION=11

Of course one device for each bat file (0 through 3).
One of the cards have a troubled GPU. No matter which slot I use in the machine, it never runs for long. It runs for a very short while, then it freeze.
Sample message at a freeze:
Code:
325.80 Mhash/sec [2 Accepted] [0 Rejected] [RPC (+LP)]. Then GPU activity drops to zero.

http://imageshack.us/photo/my-images/859/gpuactivity.png/
Any ideas?

You didn't mentioned at what clock speeds you running.

You said win 7 64, sdk 2.4. have you installed all the things useless to mining coming with the driver?
11.4?

It has been told many times, by many members that it is best to go for less than 11, thats 10.10 or 10.XX with ati stream sdk 2.1 for HD 5000 series cards.
& APP 2.3 or greater for HD 6000 series with 11.XX drivers, coz HD 6000 series don't support ati stream 2.2 or less.

If over clocked beyond limit with out looking out temp, also has the possibility that one gpu in that card blown out.
Better run only one card & see which card's gpu giving problem. Isolation of problem is first step in trouble shooting.
You can see that by device 0 & 1, after finding the gpu, mark the card, then uninstall all the AMD drivers &
then run latest version of "driver sweeper" from www.phyxion.net & analyse & clean AMD-Display drivers.
Then install 10.xx & 2.1 & check again to confirm THE gpu is blown or not.
If it runs with out problem, then u r lucky.
Always try to run fan at 100% speed, if u can able to with stand sound.
Coz, cost of fan is very less than the cost of gpu's.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JesusTheCaffeine on May 06, 2011, 12:41:18 PM
Is it ok to have a few rejected shares, like 2000 accepted and 50 rejected?



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: elrock on May 06, 2011, 03:32:44 PM
Just FYI, I get a "wrong username/password" error message when I try to connect to deepbit.net.  My username (email address) has a period in it and that's probably the source of the problem.  I tried escaping the period to no avail.

I'm able to mine at slush's pool with no problems.  I suppose I will have to register with a different email address at deepbit.net if I want to join that pool.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on May 06, 2011, 03:54:52 PM
Is it ok to have a few rejected shares, like 2000 accepted and 50 rejected?

Yes. Its really good. For the 2050 shares u sent, 2000 accepted & 50 rejected (stale)
Its quite low actually.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on May 06, 2011, 03:59:53 PM
Just FYI, I get a "wrong username/password" error message when I try to connect to deepbit.net.  My username (email address) has a period in it and that's probably the source of the problem.  I tried escaping the period to no avail.

I'm able to mine at slush's pool with no problems.  I suppose I will have to register with a different email address at deepbit.net if I want to join that pool.

You can use same email address to register in any number of pools.
First you login to deepbit.net with username & password.
Make sure, the worker username & password are correct, that is it is same as in miner.
If not change the worker name & password to reflect the worker name & password in deepbit.net.
You can create new worker & use that.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Herodes on May 06, 2011, 04:34:26 PM
...

Thanks for you answer, I have moved it to

http://bitcointalk.org/index.php?topic=7389.0


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: elrock on May 06, 2011, 04:54:25 PM
Just FYI, I get a "wrong username/password" error message when I try to connect to deepbit.net.  My username (email address) has a period in it and that's probably the source of the problem.  I tried escaping the period to no avail.

I'm able to mine at slush's pool with no problems.  I suppose I will have to register with a different email address at deepbit.net if I want to join that pool.

You can use same email address to register in any number of pools.
First you login to deepbit.net with username & password.
Make sure, the worker username & password are correct, that is it is same as in miner.
If not change the worker name & password to reflect the worker name & password in deepbit.net.
You can create new worker & use that.

Oops, I was using a period instead of "_"  before the worker ID number.  :-[ 

Fixed and now running well.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JesusTheCaffeine on May 06, 2011, 09:04:35 PM
Is it ok to have a few rejected shares, like 2000 accepted and 50 rejected?

Yes. Its really good. For the 2050 shares u sent, 2000 accepted & 50 rejected (stale)
Its quite low actually.
Coolio, I didn't really think it was my OC because I WC and the max temp of the GPU is never past 50C.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: E on May 07, 2011, 04:40:18 AM
I'm not sure if this info is on this thread already, but for you ubuntu users out there, if you're getting

Code:
  File "/home/ethan/src/bitcoin/phoenix-miner/trunk/minerutil/RPCProtocol.py", line 24, in <module>                                                               
    from twisted.web2.client import http                                         
ImportError: No module named web2.client

from phoenix.py, you'll need:

Code:
e@u:~/src/bitcoin/phoenix-miner/trunk$ sudo aptitude install python-twisted-web2

-E
(1Jmn97kfJ6DBBCuft6Z1oW8e2Lwgheyr6s)

Features


Download

Latest version: 1.4
Windows binaries (http://svn3.xp-dev.com/svn/phoenix-miner/files/phoenix-1.4.zip)
Source code/Linux release (http://svn3.xp-dev.com/svn/phoenix-miner/files/phoenix-1.4.tar.bz2) (requires Python, Twisted, and PyOpenCL)

SVN:
http://svn3.xp-dev.com/svn/phoenix-miner/


Donations

129ZQG33GmqYRVSCw2hw7zmDUCvvMsuGbC

Multiminer thread (http://bitcointalk.org/index.php?topic=5210.0)
MMP protocol specifications (https://github.com/CFSworks/multiminer/raw/master/doc/mmp.pdf)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: teknohog on May 07, 2011, 05:16:47 PM
I'm not sure if this info is on this thread already, but for you ubuntu users out there, if you're getting

Code:
  File "/home/ethan/src/bitcoin/phoenix-miner/trunk/minerutil/RPCProtocol.py", line 24, in <module>                                                               
    from twisted.web2.client import http                                         
ImportError: No module named web2.client

from phoenix.py, you'll need:

Code:
e@u:~/src/bitcoin/phoenix-miner/trunk$ sudo aptitude install python-twisted-web2

Gentoo users may notice that twisted-web2 is not in Portage. You can find it in the sage-on-gentoo overlay.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 07, 2011, 05:26:48 PM
it its posible to compile the phoenix miner for windows in some way that doest requiere VB2008/2005 libs? i heart it its posible using a static link.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on May 07, 2011, 10:54:50 PM
I just moved over to Phoenix after finding too many share count misses with another miner.  So far, this is fantastic!  Hash rates are comparable.  Great work and thank you.  Donation sent.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: AltPluzF4 on May 08, 2011, 12:42:04 AM
Slightly confused here... Running a GTX260 (216 core) at about ~50Mhash/s on Windows 7 Professional 64bit.
If I close the console window, then relaunch the miner, my hash rate maxes around ~25Mhash/s (halves)

To fix this, I have to reboot (or, because I'm impatient, disable then re-enable the videocard via device manager.) I'm then back to full hash rate.
However, if I simply break execution of the program (via Ctrl+C), it seems to terminate properly and when relaunching I remain at the full hash rate.

Clearly, the simple answer is to always just terminate it via Ctrl+C... but I'm curious if anyone knows 'why' it seems to crash the video drivers by just closing the console window?

Thanks for any input :-/


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on May 08, 2011, 01:49:01 AM
Slightly confused here... Running a GTX260 (216 core) at about ~50Mhash/s on Windows 7 Professional 64bit.
If I close the console window, then relaunch the miner, my hash rate maxes around ~25Mhash/s (halves)

To fix this, I have to reboot (or, because I'm impatient, disable then re-enable the videocard via device manager.) I'm then back to full hash rate.
However, if I simply break execution of the program (via Ctrl+C), it seems to terminate properly and when relaunching I remain at the full hash rate.

Clearly, the simple answer is to always just terminate it via Ctrl+C... but I'm curious if anyone knows 'why' it seems to crash the video drivers by just closing the console window?

Thanks for any input :-/

For one you are not using a high end NVidia card, but more importantly, you are not using an ATI/AMD card.  For better or worse, the OpenCL used on Radeon cards (as opposed to CUDA on NVidia cards) is better suited to this type of calculation.  Essentially it amounts to it taking a few more instructions to do the same work on an NVidia card.  Personally, I prefer NVidia cards for gaming, but such is life when mining for bitcoins.

Make sure you are launching Phoenix as Administrator or you only get partial GPU access.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: AltPluzF4 on May 08, 2011, 01:56:46 AM
For one you are not using a high end NVidia card, but more importantly, you are not using an ATI/AMD card.  For better or worse, the OpenCL used on Radeon cards (as opposed to CUDA on NVidia cards) is better suited to this type of calculation.  Essentially it amounts to it taking a few more instructions to do the same work on an NVidia card.  Personally, I prefer NVidia cards for gaming, but such is life when mining for bitcoins.

Make sure you are launching Phoenix as Administrator or you only get partial GPU access.

Thanks for the input, but this is irrelevant to my question. I know I'm not using a great mining card, but this is what I have, and it's better than nothing.

My question was to the concern of closing the console window via WM_CLOSE causes the video driver to basically cut performance in half, and requires a restart of the driver.
While simply terminating via Ctrl+C closes out cleanly. I'm a C++ dev, and not familiar with python, so I'm not sure if this is just an issue with the windows compiled binary, or if the cleanup code is missing something.

Either way, it's not an important issue (since I have the work-around method), but I do like to know 'why' stuff happens, not just that it does :-/

Thanks for your time.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bill86 on May 08, 2011, 10:27:08 AM
Hello!
Is there a way to access a pool with phoenix.py through a local proxy client or a proxy?

Situation:
I am under Linux and I have access to a small proxy pool which is accessed through a local client listening on a port on my localhost.
When I test it with:
 export http_proxy="127.0.0.1:<PORT>" wget http://<some_address>/<some_content>
the proxy client shows traffic and all is fine.

But when I try
 export http_proxy="127.0.0.1:<PORT>" ./phoenix.py <URL_AND_OPTIONS>
then there is no traffic on the proxy client so I guess it is a direct connect to the server. :(

Is there a solution?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on May 08, 2011, 10:58:52 AM
Hello!
Is there a way to access a pool with phoenix.py through a local proxy client or a proxy?

Situation:
I am under Linux and I have access to a small proxy pool which is accessed through a local client listening on a port on my localhost.
When I test it with:
 export http_proxy="127.0.0.1:<PORT>" wget http://<some_address>/<some_content>
the proxy client shows traffic and all is fine.

But when I try
 export http_proxy="127.0.0.1:<PORT>" ./phoenix.py <URL_AND_OPTIONS>
then there is no traffic on the proxy client so I guess it is a direct connect to the server. :(

Is there a solution?


Are you using the trunk version? The code in the trunk right now doesn't support http_proxy. 1.4 does (and 1.45 will) use
Twisted for the HTTP requests, which presumably supports http_proxy.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bill86 on May 08, 2011, 11:16:38 AM
[...]

Are you using the trunk version? The code in the trunk right now doesn't support http_proxy. 1.4 does (and 1.45 will) use
Twisted for the HTTP requests, which presumably supports http_proxy.
No I'm using version 1.4 .
Hmm how did you configure this?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 08, 2011, 08:33:31 PM
one question, there is some way to "export" the hash rate to a .txt file?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 09, 2011, 12:47:32 PM
Version 1.45 has been released.

Changes:
1. FASTLOOP modified to use dynamic number of internal loops (should be faster, and now works at any aggression without causing stale shares)
2. RPC now uses keep-alive (should resolve issues with Slush's pool)


FASTLOOP is now recommended at any AGGRESSION level for non-dedicated miners (any card outputting to a monitor that is used and not just a dummy plug)

Using it with dedicated miners at high AGGRESSION still won't improve performance, but it no longer causes stale shares. If for some reason you have a dedicated miner at low aggression then FASTLOOP should improve hashrate.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: molecular on May 09, 2011, 01:21:47 PM
Donations

129ZQG33GmqYRVSCw2hw7zmDUCvvMsuGbC
http://blockexplorer.com/q/getreceivedbyaddress/129ZQG33GmqYRVSCw2hw7zmDUCvvMsuGbC says: 65.88207230

Not bad. Sent some more as thanks for BFI_INT.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on May 09, 2011, 08:17:13 PM
I think there is something wrong with 1.45. I get a "work is idle" error with slush's pool. Once this error comes up (I think it's happening at random or after a certain period of time) it won't resume hashing. With guiminer I have no problems.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SleepMachine on May 09, 2011, 08:37:03 PM
Works perfectly with bitcoinpool now. With 1.40 i got 8-10% rejects. Not a single reject so far. This just got awesomer. I guess the keep-alives really did the trick. Thanks alot.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nster on May 09, 2011, 09:13:26 PM
is there any possible downside to using fastloop with, say, aggression 12?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 09, 2011, 09:46:16 PM
is there any possible downside to using fastloop with, say, aggression 12?

Well, the number of internal loop iterations is recalculated several times a second, which will always just be 1 at AGGRESSION=12. It won't decrease your hashrate but it will use extra CPU cycles. It's probably better to disable it since there will be 0 hashrate gain.

Also:
FASTLOOP is now on by default so you will need to specify FASTLOOP=false to disable it. The options are fairly flexible so false/FALSE/f/n/no are all accepted values for disabling it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slush on May 09, 2011, 11:15:09 PM
jedi95, I tested new version and works perfecly on my pool. Thanks a lot, 15 BTC on the way!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: DareC on May 10, 2011, 12:29:49 AM
Would it be possible to show on the bottom line which OpenCL device is being used?  I've got a 6990, which has 2 GPUs on one card. I run two instances of phoenix via batch file and can't tell them apart.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 10, 2011, 12:59:28 AM
I think there is something wrong with 1.45. I get a "work is idle" error with slush's pool. Once this error comes up (I think it's happening at random or after a certain period of time) it won't resume hashing. With guiminer I have no problems.

That message works differently in Phoenix compared to other miners. With poclbm that message is displayed on the last line in the console window replacing the status bar. Phoenix just displays this as a normal log entry and sets the hashrate in the display to 0. Are you getting constant 0 hashrate when this happens or only the message in the log?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BOARBEAR on May 10, 2011, 01:00:23 AM
I think there is something wrong with 1.45. I get a "work is idle" error with slush's pool. Once this error comes up (I think it's happening at random or after a certain period of time) it won't resume hashing. With guiminer I have no problems.
same problem


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slush on May 10, 2011, 01:16:00 AM
I think there is something wrong with 1.45. I get a "work is idle" error with slush's pool. Once this error comes up (I think it's happening at random or after a certain period of time) it won't resume hashing. With guiminer I have no problems.
same problem

I can confirm, it start to idle after some time (but previously reported connection troubles are solved with this release).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 10, 2011, 01:42:32 AM
I think there is something wrong with 1.45. I get a "work is idle" error with slush's pool. Once this error comes up (I think it's happening at random or after a certain period of time) it won't resume hashing. With guiminer I have no problems.
same problem

I can confirm, it start to idle after some time (but previously reported connection troubles are solved with this release).

I'm looking into this now.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: thesebastian on May 10, 2011, 02:08:22 AM
ETA for CUDA? :D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: gleamingthecube on May 10, 2011, 03:40:40 AM
I am having idle problem with 1.45 as well. I am running a GTX 460 with -k poclbm vectors FASTLOOP AGGRESSION=4


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitjet on May 10, 2011, 03:55:56 AM
So I am still using 1.3 on one of my machines since Its complicated to access the desktop right now. Am I missing out on anything (aside from the fastloop fix) on the newer versions?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on May 10, 2011, 04:19:32 AM
So I am still using 1.3 on one of my machines since Its complicated to access the desktop right now. Am I missing out on anything (aside from the fastloop fix) on the newer versions?

It's probably best to avoid 1.45 until they fix the idling issue.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on May 10, 2011, 06:25:35 AM
version 1.45
2200+ accepted, 0 Rejected.
-k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=10


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 10, 2011, 07:47:11 AM
We have isolated the cause of the idle problem and corrected it. If nothing goes wrong in testing this will be released as 1.46 shortly.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on May 10, 2011, 07:53:50 AM
jedi95, I tested new version and works perfecly on my pool. Thanks a lot, 15 BTC on the way!

FYI, I'm going to reuse those 15 BTC in a new bounty to help close this bug (http://twistedmatrix.com/trac/ticket/3420) and bring true persistent connections to Twisted's HTTP client.

Whoever helps the Twisted team to get that bug closed will get 15 BTC from me. :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slush on May 10, 2011, 08:02:57 AM
FYI, I'm going to reuse those 15 BTC in a new bounty to help close this bug (http://twistedmatrix.com/trac/ticket/3420) and bring true persistent connections to Twisted's HTTP client.

Whoever helps the Twisted team to get that bug closed will get 15 BTC from me. :)

:) You should open separate thread in marketplace or technical discussion - 15 BTC is going to be serious wealth ;) and I'm sure there are some skilled programmers interested in getting their first bitcoins for some fun with Twisted...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dbitcoin on May 10, 2011, 08:15:03 AM
CFSworks, how about add this:

http://bitcointalk.org/index.php?topic=1976.msg114013#msg114013



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 10, 2011, 09:10:04 AM
1.46 has been released which fixes the idle problem.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CFSworks on May 10, 2011, 09:24:59 AM
CFSworks, how about add this:

http://bitcointalk.org/index.php?topic=1976.msg114013#msg114013

As it is, any failed RPC operation will put Phoenix into "retry connection" mode, where it retries at 15 second intervals.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CryptikEnigma on May 10, 2011, 10:40:33 AM
I just downloaded this. When I open the application the cmd window just opens for a split second then closes. What did I do wrong?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Hawkix on May 10, 2011, 10:51:47 AM
As I asked before .. how does Phoenix calculate local hashrate?

I observed that at aggression 7 I can get 430MH/sec, while at aggression 10 I can get only 405, but at this lower local hashrate I am able to finish succesfully more work shares than at aggression 7 (tested for half a day, card compared to card, etc.).

So, better aggression yields in hotter GPU and better yield, while the local hashrate is actually reported lower.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 10, 2011, 11:11:24 AM
As I asked before .. how does Phoenix calculate local hashrate?

I observed that at aggression 7 I can get 430MH/sec, while at aggression 10 I can get only 405, but at this lower local hashrate I am able to finish succesfully more work shares than at aggression 7 (tested for half a day, card compared to card, etc.).

So, better aggression yields in hotter GPU and better yield, while the local hashrate is actually reported lower.


The displayed hashrate is the average over several kernel executions. (configure with -a, default is 10) Each sample in the average is calculated using: (nonces per execution/time taken)

Higher AGGRESSION increases both the number of nonces per execution and the time taken.

I have tried AGGRESSION values up to 14 and the displayed hashrate continues to increase with each step.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Nicksasa on May 10, 2011, 11:18:36 AM
As I asked before .. how does Phoenix calculate local hashrate?

I observed that at aggression 7 I can get 430MH/sec, while at aggression 10 I can get only 405, but at this lower local hashrate I am able to finish succesfully more work shares than at aggression 7 (tested for half a day, card compared to card, etc.).

So, better aggression yields in hotter GPU and better yield, while the local hashrate is actually reported lower.


The displayed hashrate is the average over several kernel executions. (configure with -a, default is 10) Each sample in the average is calculated using: (nonces per execution/time taken)

Higher AGGRESSION increases both the number of nonces per execution and the time taken.

I have tried AGGRESSION values up to 14 and the displayed hashrate continues to increase with each step.
At 909Mhz It shows me 351Mhash/s, when i bump it to 910Mhz i get 362Mhash/s. But then at 911Mhz I get 351Mhash/s again. Using agression 12, fastloop=false and worksize=128 on my unlocked 6950.
Seems somewhat a bug in the miner.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Internet151 on May 10, 2011, 12:56:44 PM
I'd be nice if the first post of this thread was updated with patch notes instead of having to dig for them.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bobR on May 10, 2011, 01:06:59 PM
1.46 has been released which fixes the idle problem.

ok where do you get it ??


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Nicksasa on May 10, 2011, 01:08:10 PM
1.46 has been released which fixes the idle problem.

ok where do you get it ??
Are you serious ?  ::) First post ...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: limpbrains on May 10, 2011, 02:45:01 PM
I was trying to build phoenix from sources under windows, but I can't make pyopencl works.
What version are you using in your setup for windows ?
Where can I find compiled one ? Which will work with python2.7

Thanks.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Tyran on May 10, 2011, 02:58:04 PM
I was trying to build phoenix from sources under windows, but I can't make pyopencl works.
What version are you using in your setup for windows ?
Where can I find compiled one ? Which will work with python2.7

Thanks.
I couldn't get pyopencl to work from source either.
Try the binary package found here, it's what I ended up using: http://www.lfd.uci.edu/~gohlke/pythonlibs/


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: limpbrains on May 10, 2011, 03:10:41 PM
I was trying to build phoenix from sources under windows, but I can't make pyopencl works.
What version are you using in your setup for windows ?
Where can I find compiled one ? Which will work with python2.7

Thanks.
I couldn't get pyopencl to work from source either.
Try the binary package found here, it's what I ended up using: http://www.lfd.uci.edu/~gohlke/pythonlibs/

I've tried this package. But it doesn't work for me with last Python 2.7. When I'm trying to import pyopencl it fails with dll error.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bobR on May 10, 2011, 03:44:29 PM
1.46 has been released which fixes the idle problem.

ok where do you get it ??
Are you serious ?  ::) First post ...

are you serious.. seemed clear enough... were are the downloads for 1.46
Is it so hard to post the url when announcing an updated version ?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Nythain on May 10, 2011, 04:25:43 PM
They're on the first post of this thread? at least, thats where I found them. That's the way proper forum software development usually works. Update software, edit main post to reflect changes.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bobR on May 10, 2011, 04:32:33 PM
They're on the first post of this thread? at least, thats where I found them. That's the way proper forum software development usually works. Update software, edit main post to reflect changes.

ok I guess thats easier than posting a url link with hundreds of post
Guess I should have know that the first post was edited... really
I'm not a mind reader


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Nythain on May 10, 2011, 04:36:39 PM
ok I guess thats easier than posting a url link with hundreds of post
That's usually why it's done that way. Some development threads can get to be hundreds of pages long or more. Sorry for sounding snarky. Mornings, no one loves em. Also, I tend to forget that not everyone spends large amounts of time on various internet forums.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bobR on May 10, 2011, 07:50:34 PM
Either ther is a problem with phoenix 1.46 or bitcoinpool
I get no rejects but the pool consistently is showing less accepted shares than phonix
WTF


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: zoro on May 10, 2011, 08:45:58 PM
exactly the same with deepbit.
although i see 0 rejected in all workers, some workers have 5% stales!
others have 0%
very strange!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JesusTheCaffeine on May 10, 2011, 10:01:54 PM
As I asked before .. how does Phoenix calculate local hashrate?

I observed that at aggression 7 I can get 430MH/sec, while at aggression 10 I can get only 405, but at this lower local hashrate I am able to finish succesfully more work shares than at aggression 7 (tested for half a day, card compared to card, etc.).

So, better aggression yields in hotter GPU and better yield, while the local hashrate is actually reported lower.


The displayed hashrate is the average over several kernel executions. (configure with -a, default is 10) Each sample in the average is calculated using: (nonces per execution/time taken)

Higher AGGRESSION increases both the number of nonces per execution and the time taken.

I have tried AGGRESSION values up to 14 and the displayed hashrate continues to increase with each step.
At 909Mhz It shows me 351Mhash/s, when i bump it to 910Mhz i get 362Mhash/s. But then at 911Mhz I get 351Mhash/s again. Using agression 12, fastloop=false and worksize=128 on my unlocked 6950.
Seems somewhat a bug in the miner.



DUDUDUDUDUDUDUDUDE, If you go to AMD CCC and make powertune +20 you can get MUCH MORE HASH, due to the card not downclocking when it gets over 200w.

ALSO: you must OC with CCC


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Nicksasa on May 10, 2011, 10:17:14 PM
As I asked before .. how does Phoenix calculate local hashrate?

I observed that at aggression 7 I can get 430MH/sec, while at aggression 10 I can get only 405, but at this lower local hashrate I am able to finish succesfully more work shares than at aggression 7 (tested for half a day, card compared to card, etc.).

So, better aggression yields in hotter GPU and better yield, while the local hashrate is actually reported lower.


The displayed hashrate is the average over several kernel executions. (configure with -a, default is 10) Each sample in the average is calculated using: (nonces per execution/time taken)

Higher AGGRESSION increases both the number of nonces per execution and the time taken.

I have tried AGGRESSION values up to 14 and the displayed hashrate continues to increase with each step.
At 909Mhz It shows me 351Mhash/s, when i bump it to 910Mhz i get 362Mhash/s. But then at 911Mhz I get 351Mhash/s again. Using agression 12, fastloop=false and worksize=128 on my unlocked 6950.
Seems somewhat a bug in the miner.



DUDUDUDUDUDUDUDUDE, If you go to AMD CCC and make powertune +20 you can get MUCH MORE HASH, due to the card not downclocking when it gets over 200w.

ALSO: you must OC with CCC
First of all, you don't have to OC with CCC. I'm using afterburner and that's what i have always used. Powertune is already set to +20%.
It's not downclocking, heaven benchmark shows me increased fps at 950 then at 910.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SleepMachine on May 10, 2011, 10:25:45 PM
exactly the same with deepbit.
although i see 0 rejected in all workers, some workers have 5% stales!
others have 0%
very strange!

I can confirm this behaviour with Bitcoinpool. Phoenix miner is reporting more accepted shares than the site is.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bolapara on May 10, 2011, 10:59:16 PM
same here in 1.45.  it reports 0% stales but deepbit reports much more.

also, the % stales I had before (~.27%) is now way up to .31% so it is definitely worse...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: F.A. Hayek on May 10, 2011, 11:51:14 PM
Can someone post instructions from a barebox to making this work ?

I'm having trouble getting it to run. I have bitcoind running as a daemon and that's about it.



 File "./phoenix.py", line 123, in <module>
    miner.start(options)
  File "/home/fahayek/Downloads/phoenix-1.46/Miner.py", line 74, in start
    self.kernel = self.options.makeKernel(KernelInterface(self))
  File "./phoenix.py", line 111, in makeKernel
    kernelModule = imp.load_module(module, file, filename, smt)
  File "kernels/poclbm/__init__.py", line 22, in <module>
    import pyopencl as cl
  File "/usr/lib/pymodules/python2.7/pyopencl/__init__.py", line 3, in <module>
    import pyopencl._cl as _cl
ImportError: libOpenCL.so.1: cannot open shared object file: No such file or directory



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: AltPluzF4 on May 11, 2011, 01:10:01 AM
Small request... but could you please add a display for an "efficiency" ratio/percentage? It's easy to just glance at accepted/rejected, but I'd like to see a comparison of "get works" vs accepted.
Currently I have to manually count how many times the log prints that it received new work, then compare that to the accepts and rejects (rejects have been very rare as of the new version.)

Also, probably a dumb question, but when I load the miner, I get a double request... is this something that can be addressed, or is it a server-side issue?

Example:
Code:
[10/05/2011 20:57:51] Phoenix 1.46 starting...
[10/05/2011 20:57:51] Connected to server
[10/05/2011 20:57:51] Server gave new work; passing to WorkQueue
[10/05/2011 20:57:51] New block (WorkQueue)
[10/05/2011 20:57:51] Server gave new work; passing to WorkQueue
I always get new work after a new block, but there's always a 'new' block after I start the app.

Also... could there be a way to dump a temp file on close, so if you're just restarting, it can resume the work unit it had previously instead of requesting a new one? Most likely I'd expect it would be timestamped, and ignored if older than a few seconds. One such instance where this is useful is when you release a new version and I want to close out, extract the new files, then relaunch it.

If I was on a linux box, I'd just manually edit the source and merge with your svn changes, but since I'm on windows I am relying on your binary. I'll probably end up just learning the basics of python and compiling this myself, but for now I'm just being lazy and hoping you'd be kind enough to consider these modifications. Especially since it may benefit people other than myself.

Thanks for your time, sorry if I'm incoherent, drowsy from allergy meds about to pass out :-|


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: drgr33n on May 11, 2011, 03:33:56 AM
Can someone post instructions from a barebox to making this work ?

I'm having trouble getting it to run. I have bitcoind running as a daemon and that's about it.



 File "./phoenix.py", line 123, in <module>
    miner.start(options)
  File "/home/fahayek/Downloads/phoenix-1.46/Miner.py", line 74, in start
    self.kernel = self.options.makeKernel(KernelInterface(self))
  File "./phoenix.py", line 111, in makeKernel
    kernelModule = imp.load_module(module, file, filename, smt)
  File "kernels/poclbm/__init__.py", line 22, in <module>
    import pyopencl as cl
  File "/usr/lib/pymodules/python2.7/pyopencl/__init__.py", line 3, in <module>
    import pyopencl._cl as _cl
ImportError: libOpenCL.so.1: cannot open shared object file: No such file or directory



Check out linuxcoin :D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: zoro on May 11, 2011, 04:28:48 AM
exactly the same with deepbit.
although i see 0 rejected in all workers, some workers have 5% stales!
others have 0%
very strange!
latest news: i see an increase to average speed in last 5 minutes and at the end of the round, meaning i get more in each round!
thus i think 1.46 is better even with more stalled shares (or deepbit stalled reports are wrong!), i am not sure about pps though :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Nicksasa on May 11, 2011, 09:39:18 AM
This is not only with phoenix but also with poclbm but why does -v on 69XX cards reduce the mhash/s ? As i see it speeds it up on the 5XXX cards.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kalifg on May 11, 2011, 03:28:42 PM
Trying to get it to run on Mac OS X. It worked once with DEVICE=0 VECTORS AGGRESSION=7 but after stopping it to try other parameters it stopped working with the error "[25/04/2011 15:59:52] FATAL kernel error: Failed to compile OpenCL kernel!". Looking in the generated crash log there's this:


Code:
Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000101fc3000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib                   0x00007fff87fa7506 strtol_l + 75
1   ...pple.ATIRadeonX2000GLDriver      0x000000011502632f glrCompDeleteProgram + 4895
2   ...pple.ATIRadeonX2000GLDriver      0x0000000115026535 glrCompDeleteProgram + 5413
...

I have the same problem.  Deleting the phoenix directory and untarring a fresh copy of the code allows me to run it again.  I found that removing the file kernels/poclbm/34084881c46d0a0ca533f7a327086560.elf allowed me to run it again.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: manifold on May 11, 2011, 07:00:03 PM
Hi, I get the same error as F.A. Hayek .

Code:
Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
    miner.start(options)
  File "/home/myusername/Programme/phoenix/Miner.py", line 74, in start
    self.kernel = self.options.makeKernel(KernelInterface(self))
  File "phoenix.py", line 111, in makeKernel
    kernelModule = imp.load_module(module, file, filename, smt)
  File "kernels/poclbm/__init__.py", line 22, in <module>
    import pyopencl as cl
  File "/usr/lib/pymodules/python2.7/pyopencl/__init__.py", line 3, in <module>
    import pyopencl._cl as _cl
ImportError: libOpenCL.so.1: cannot open shared object file: No such file or directory

I installed already the python-PyOpenCL package.

Or do I have to download some files from here:
https://github.com/m0mchil/poclbm
and copy them into the kernel folder?


I got the ATI 5770 in Ubuntu with the fglrx Package from the restricted driver manager.


What can I do?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: niooron on May 11, 2011, 07:48:11 PM
I don't know if this was already found, but I just opened 2 instances of phoenix at agression=3 and I am getting the same mhash/s than agression=8 or 9 on a single instance, only without any desktop lag.

Can someone else try?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: manifold on May 11, 2011, 08:44:04 PM
Hi, I get the same error as F.A. Hayek .

Code:
Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
    miner.start(options)
  File "/home/myusername/Programme/phoenix/Miner.py", line 74, in start
    self.kernel = self.options.makeKernel(KernelInterface(self))
  File "phoenix.py", line 111, in makeKernel
    kernelModule = imp.load_module(module, file, filename, smt)
  File "kernels/poclbm/__init__.py", line 22, in <module>
    import pyopencl as cl
  File "/usr/lib/pymodules/python2.7/pyopencl/__init__.py", line 3, in <module>
    import pyopencl._cl as _cl
ImportError: libOpenCL.so.1: cannot open shared object file: No such file or directory

I installed already the python-PyOpenCL package.

Or do I have to download some files from here:
https://github.com/m0mchil/poclbm
and copy them into the kernel folder?


I got the ATI 5770 in Ubuntu with the fglrx Package from the restricted driver manager.


What can I do?

Ok Now It works! I had to download the sdk and follow the instructions... now iot works... 100 MHash/s


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jkminkov on May 11, 2011, 09:14:10 PM
I have two cards 6950 and 5780 on one rig, and when I try to stop(ctrl+c) one miner, system hangs win7 x64, if I'm lucky I can stop both miners and then start them again


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 11, 2011, 10:18:53 PM
I have no idea why reloading the cached kernel fails on OSX. I don't have any way to test this because I don't have a mac. (and never will)

As a workaround you can replace __init__.py in the kernels\poclbm folder with this version:
Download (http://svn3.xp-dev.com/svn/phoenix-miner/branches/OSX/kernels/poclbm/__init__.py)


This modification simply skips caching the kernel, which means it's compiled every time you start Phoenix.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shackleford on May 12, 2011, 04:07:17 AM
I have two cards 6950 and 5780 on one rig, and when I try to stop(ctrl+c) one miner, system hangs win7 x64, if I'm lucky I can stop both miners and then start them again

I just came here to post the same thing, glad I am not alone.

Windows on an otherwise stable machine will lock up when hitting the X on the DOS box with like a 60% chance and Cntrl C has like a 40% chance of lock up. (my guesstimate)

Two miners both 5870's on Windows 7 64b
Catalyst  11.4 (then 11.5) and 2.4 OCL  with and without the additional phatk kernel

(great miner btw)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BOARBEAR on May 12, 2011, 04:13:23 AM
I have two cards 6950 and 5780 on one rig, and when I try to stop(ctrl+c) one miner, system hangs win7 x64, if I'm lucky I can stop both miners and then start them again

I just came here to post the same thing, glad I am not alone.

Windows on an otherwise stable machine will lock up when hitting the X on the DOS box with like a 60% chance and Cntrl C has like a 40% chance of lock up. (my guesstimate)

Two miners both 5870's on Windows 7 64b
Catalyst  11.4 (then 11.5) and 2.4 OCL  with and without the additional phatk kernel

(great miner btw)

I have this problem too


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: manifold on May 12, 2011, 11:17:21 AM
1.46 has been released which fixes the idle problem.

Code:
Warning: work queue empty, miner is idle
I still get the error with the current trunk Revision 82.


The error is really bad...



I use the command:
python phoenix.py  -u http://user:pass@mining.bitcoin.cz:8332 -k poclbm DEVICE=0 VECTORS BFI_INT* FASTLOOP=false AGGRESSION=9
with a ATI 5770


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tiberiandusk on May 12, 2011, 12:15:38 PM
I'm getting the same error. On deepbit with the same settings I don't have this problem. Could it be related to the speed of the actual server not being able to keep up?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 12, 2011, 01:57:37 PM
jedi, one question the phoenix miners gives a error about it cant find kernel on winpe.

It needs some global variable or something?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Clavulanic on May 12, 2011, 05:35:04 PM
I upgraded to phoenix 1.46 last night and used the phatk kernal that jedi made.

I check back in the morning and both of my clients have 0 rejected shares!

I used to get 1.5-2% rejected shares before hand. I was also on aggression 7 and fastloop, while I am now on aggression 13 and fastloop false. Is this accurate or is it a bug of some sort? I don't think slush's pool displays rejected shares so I can't tell through that.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: varepsilon on May 12, 2011, 07:10:02 PM
exactly the same with deepbit.
although i see 0 rejected in all workers, some workers have 5% stales!
others have 0%
very strange!

I have the same problem with deepbit. Consider switching back to poclbm


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bobR on May 12, 2011, 07:35:51 PM
exactly the same with deepbit.
although i see 0 rejected in all workers, some workers have 5% stales!
others have 0%
very strange!

I have the same problem with deepbit. Consider switching back to poclbm

Phoenix seems to not be reporting stales as rejects


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 13, 2011, 03:48:35 AM
Version 1.47 has been released.

This version fixes rejected shares being counted as accepted.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: ataranlen on May 13, 2011, 03:54:21 AM
Version 1.47 has been released.

This version fixes rejected shares being counted as accepted.

Awesome! Now I can finally see my true share:rejected ratio on my miners!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JorgePasada on May 13, 2011, 08:00:11 AM
Any guides on how to set this up?

https://www.bitcoin.org/smf/index.php?topic=3359.msg108953#msg108953

I used the above one with no luck, but I'm kind of a noob so I 'm not sure if I'm even doing anything right.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SleepMachine on May 13, 2011, 10:35:54 AM
Version 1.47 has been released.

This version fixes rejected shares being counted as accepted.

Awesome! Now I can finally see my true share:rejected ratio on my miners!

Very nice


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nster on May 13, 2011, 04:36:22 PM
could you perhaps upgrade phatk as well for us sdk 2.4 users?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 13, 2011, 06:58:04 PM
could you perhaps upgrade phatk as well for us sdk 2.4 users?

Already done, this is also posted in the phatk thread:
Download (http://svn3.xp-dev.com/svn/phoenix-miner/files/kernels/phatk.zip)

Also, Phoenix has backwards compatibility for kernels. (meaning newer versions will work fine with kernels designed for older versions, but not necessarily the reverse.)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jkminkov on May 13, 2011, 07:27:00 PM
I have two cards 6950 and 5780 on one rig, and when I try to stop(ctrl+c) one miner, system hangs win7 x64, if I'm lucky I can stop both miners and then start them again

I just came here to post the same thing, glad I am not alone.

Windows on an otherwise stable machine will lock up when hitting the X on the DOS box with like a 60% chance and Cntrl C has like a 40% chance of lock up. (my guesstimate)

Two miners both 5870's on Windows 7 64b
Catalyst  11.4 (then 11.5) and 2.4 OCL  with and without the additional phatk kernel

(great miner btw)

I have this problem too

I found a dumb solution ;D - I caused RPC error and waited till 0 hash/s by disconnecting my RAS dial-up connetion, you can use disable LAN card or unplug RJ-45

too bad that it is unusable when using remote control software :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nster on May 14, 2011, 12:15:38 AM
could you perhaps upgrade phatk as well for us sdk 2.4 users?

Already done, this is also posted in the phatk thread:
Download (http://svn3.xp-dev.com/svn/phoenix-miner/files/kernels/phatk.zip)

Also, Phoenix has backwards compatibility for kernels. (meaning newer versions will work fine with kernels designed for older versions, but not necessarily the reverse.)

thanks, in the future, it be great if you continue... perhaps even include it in your original post


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JorgePasada on May 14, 2011, 01:53:18 AM
I'm in the process of reading through this whole thread,

But can anyone point me to a guide to help set this up?

List of things I need? What version of the ATI SDK I should be using? Etc.

If I can just get a list of ALL of the individual packages I need to install to get this to work, I can probably get it going.

I'll update this post as I learn more.

I'm running a 5970 and 2x 5850's right now.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: mewantsbitcoins on May 14, 2011, 01:55:49 AM
I'm in the process of reading through this whole thread,

But can anyone point me to a guide to help set this up?

List of things I need? What version of the ATI SDK I should be using? Etc.

If I can just get a list of ALL of the individual packages I need to install to get this to work, I can probably get it going.

I'll update this post as I learn more.

I'm running a 5970 and 2x 5850's right now.

Remove all the previous drivers.
Download ATI catalyst suite from http://support.amd.com/us/gpudownload/Pages/index.aspx for your operating system
Then download phoenix miner https://www.bitcoin.org/smf/index.php?topic=6458.0
and you should be all set to go. If you want to overclock/underclock your card, download MSI afterburner http://event.msi.com/vga/afterburner/download.htm

To start mining in phoenix directory type:

Code:
phoenix -u http://worker_name:password@pool_address:8332 -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=7

for deepbit it would look something like this:

Code:
phoenix -u http://evil_motherfucker@hell.com:mysupersecretpassword@deepbit.net:8332 -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=7

Donations welcome   ;)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nster on May 14, 2011, 04:37:04 AM
I'm in the process of reading through this whole thread,

But can anyone point me to a guide to help set this up?

List of things I need? What version of the ATI SDK I should be using? Etc.

If I can just get a list of ALL of the individual packages I need to install to get this to work, I can probably get it going.

I'll update this post as I learn more.

I'm running a 5970 and 2x 5850's right now.

Remove all the previous drivers.
Download ATI catalyst suite from http://support.amd.com/us/gpudownload/Pages/index.aspx for your operating system
Then download phoenix miner https://www.bitcoin.org/smf/index.php?topic=6458.0
and you should be all set to go. If you want to overclock/underclock your card, download MSI afterburner http://event.msi.com/vga/afterburner/download.htm

To start mining in phoenix directory type:

Code:
phoenix -u http://worker_name:password@pool_address:8332 -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=7

for deepbit it would look something like this:

Code:
phoenix -u http://evil_motherfucker@hell.com:mysupersecretpassword@deepbit.net:8332 -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=7

Donations welcome   ;)

SDK 2.2 should be better for him


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Azelphur on May 14, 2011, 09:20:15 PM
Hi, I've been trying to use phoenix with my new AMD 6990. When I start the miner, I seem to get relatively low speeds for this card, around 100-200. The wiki says I should get more like 400. After a couple of minutes the miner starts to spam

Kernel error: Unusual behaviour from OpenCL. Hardware problem?

I've tried SDK 2.4 and 2.2, and I've tried 64/32bit Ubuntu, all have the same problem. Does this mean my card is physically broken? :(


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: sethsethseth on May 14, 2011, 10:01:52 PM
I'm running a couple crossfired 5970's like this: -u http://address:x@pool.bitcoin.dashjr.org:8337 -k poclbm BFI_INT VECTORS AGGRESSION=7 WORKSIZE=64 DEVICE=3 -q 2
One of the cards is overclocked and one is not (due to heat issues).  The miner runs at 360mhash/s on both the overclocked cores, but when I add in the stock card cores, it drops the hash rate on the overclocked cores down to the same as the stock core hash around 300mhash.  The rejected shares go way up on all cores when they are all running together.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 14, 2011, 11:11:05 PM
jedi, on what phoenix relies to find its kernel??? atill getting "cant find kernel" on WinPe


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: WhatIf on May 15, 2011, 07:34:16 AM
Good grief man, this is some seriously fragmented code!  It's a frustrating maze of functions one must navigate through to understand what exactly is going on everywhere...  And what makes it even worse is the number of files the functions are spread over.

That being said, this is some nice work - good job!  You clearly know your stuff.  It sure would be nice if things were consolidated into fewer functions and files though.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 15, 2011, 07:50:25 AM
jedi, on what phoenix relies to find its kernel??? atill getting "cant find kernel" on WinPe

This I don't know exactly. The OS level dependencies are within Python itself.

This is the code to import kernels:

Code:
   import imp
    ...
    ...
    ...
    def makeKernel(self, requester):
        if not self.kernel:
            module = self.parsedSettings.kernel
            try:
                file, filename, smt = imp.find_module(module, ['kernels'])
            except ImportError:
                print("Could not locate the specified kernel!")
                exit()
            kernelModule = imp.load_module(module, file, filename, smt)
            self.kernel = kernelModule.MiningKernel(requester)
        return self.kernel


Good grief man, this is some seriously fragmented code!  It's a frustrating maze of functions one must navigate through to understand what exactly is going on everywhere...  And what makes it even worse is the number of files the functions are spread over.

That being said, this is some nice work - good job!  You clearly know your stuff.  It sure would be nice if things were consolidated into fewer functions and files though.

This is one of the results of the modular design. I can see how it would be confusing for some users, but the advantage is you can write a new kernel without necessarily knowing the rest of the code. It's also much easier to re-use the same code in other programs. For example, CFSworks' MultiMiner uses the exact same protocol implementation as Phoenix. (mineruitl)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tiberiandusk on May 15, 2011, 08:44:21 AM
The last few days I have been getting a lot of Miner Queue is Empty errors. I've tried adjusting the askrate and turning the aggression down but neither seems to help. It is causing me to get a lot of rejected shares which is really annoying. Anyone have any tips on how to fix this? It does it with poclbm and phatk.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 15, 2011, 09:00:20 AM
The last few days I have been getting a lot of Miner Queue is Empty errors. I've tried adjusting the askrate and turning the aggression down but neither seems to help. It is causing me to get a lot of rejected shares which is really annoying. Anyone have any tips on how to fix this? It does it with poclbm and phatk.

What pool/server are you connecting to?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Bitcoineruk on May 15, 2011, 09:59:52 AM
Setup guide for 6990 cards!! Windows 7 x64

Ok guys, just spent a little time trying to find the best values for my 6990 - I have had many differing hash rates dependant on settins, ad on this card it can go from 290mh/s to what im at now 400mh/s

To start with i downloaded the newest Phoenix miner: http://bitcointalk.org/index.php?topic=6458.0 (http://bitcointalk.org/index.php?topic=6458.0)

I then extracted straight to my c:\ drive with folder phoenix : c:\phoenix

Once the files are extracted i got to work with the settings, firing straight up i got a lowly 300mh/s but trawled through this thread, made various changes and got myself up!

I decided to create a .bat file so i could run it from the desktop - starting both cores of the 6990 at the same time.

How to Create a .bat file

Right click on your desktop and create a new txt document - i.e notepad

Call it whatever you want, you need to now (if you already dont have the setting enabled) make sure the file type is displayed for the document so you can modify it.

If you need to enable that simply go to folder options and untick "hide known filetypes"

rename the ".txt" document to ".bat"

Right click the now .bat file and select edit, it will look just like a notepad file, now you can start typing.

Here is what mine looks like - you can copy and paste this into it, but remeber to put your settings in :)

start /DC:\phoenix phoenix.exe -u http://yourwalletaddress:x@pool.bitcoin.dashjr.org:8337 -k poclbm DEVICE=0 VECTORS BFI_INT FASTLOOP AGGRESSION=11 WORKSIZE=128
start /DC:\phoenix phoenix.exe -u http://yourwalletaddress:x@pool.bitcoin.dashjr.org:8337 -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP AGGRESSION=11 WORKSIZE=128


The above settings will get you mining on lukejrs pool Eligius @ around 400mh/s with 925 core on the graphics card.

Save the .bat file and run it from the desktop :)

Just thought it might help some newbie miners (like me) without taking up loads of time.

Final Thoughts

My main gains came from going from BFI_INT* to just BFI_INT without the "*" and setting my worksize to 128 - the aggression always helps too

Donations welcome if this helped even just a little.

15sE1b7Y6rLMBwwyBLGwSBTQzvB8csUfrX


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tiberiandusk on May 15, 2011, 10:21:05 AM
The last few days I have been getting a lot of Miner Queue is Empty errors. I've tried adjusting the askrate and turning the aggression down but neither seems to help. It is causing me to get a lot of rejected shares which is really annoying. Anyone have any tips on how to fix this? It does it with poclbm and phatk.

What pool/server are you connecting to?

Eligius


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 15, 2011, 11:25:58 AM

My main gains came from going from BFI_INT* to just BFI_INT without the "*" and setting my worksize to 128 - the aggression always helps too


The * was to indicate that trying to use BFI_INT on ATI 4xxx series cards wouldn't work. I'm also curious why you were following the "Midrange and older ATI cards (48xx, 57xx, ect)" recommendation instead of the "High-end ATI cards (58xx, 5970, 68xx, 69xx)" one.

In any case, nice guide. I edited the first post a bit so that hopefully nobody else tries using BFI_INT* instead of BFI_INT.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JorgePasada on May 15, 2011, 10:31:58 PM
Edited Out, Posted my most recent error in the next post.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JorgePasada on May 15, 2011, 11:12:19 PM
I'm in the process of reading through this whole thread,

But can anyone point me to a guide to help set this up?

List of things I need? What version of the ATI SDK I should be using? Etc.

If I can just get a list of ALL of the individual packages I need to install to get this to work, I can probably get it going.

I'll update this post as I learn more.

I'm running a 5970 and 2x 5850's right now.

Remove all the previous drivers.
Download ATI catalyst suite from http://support.amd.com/us/gpudownload/Pages/index.aspx for your operating system
Then download phoenix miner https://www.bitcoin.org/smf/index.php?topic=6458.0
and you should be all set to go. If you want to overclock/underclock your card, download MSI afterburner http://event.msi.com/vga/afterburner/download.htm

To start mining in phoenix directory type:

Code:
phoenix -u http://worker_name:password@pool_address:8332 -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=7

for deepbit it would look something like this:

Code:
phoenix -u http://evil_motherfucker@hell.com:mysupersecretpassword@deepbit.net:8332 -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=7

Donations welcome   ;)

SDK 2.2 should be better for him

Thanks for the heads up, I'm using linux and right now I'm getting an error about . . . pyopencl apparently (it's in the reply just above this)

Also I've been reading and I've heard that SDK 2.4 _might_ be better, any thoughts on that?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 16, 2011, 12:33:30 AM
This I don't know exactly. The OS level dependencies are within Python itself.

This is the code to import kernels:

Code:
   import imp
    ...
    ...
    ...
    def makeKernel(self, requester):
        if not self.kernel:
            module = self.parsedSettings.kernel
            try:
                file, filename, smt = imp.find_module(module, ['kernels'])
            except ImportError:
                print("Could not locate the specified kernel!")
                exit()
            kernelModule = imp.load_module(module, file, filename, smt)
            self.kernel = kernelModule.MiningKernel(requester)
        return self.kernel

Thanks, i cheked it out and installing python 3.2 intro winpe fixed the problem, funny thing, i dont need python to be installed intro a normal windows.

BTW, there is a mode to only show up the hash rate, acepted and rejected in the cmd window? im using the "1>something.txt 2>&1" to redirect the output to a text file, for remote monitoring, and i get a lot of unknown characters in the txt file, parsing it is a nightmare, but thats not the problem, the txt file gets to over 1gb in size after 24 hours!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Internet151 on May 16, 2011, 03:52:35 AM
I'm still having occasional issues even with the latest version of phoenix not automatically reconnecting to bitcoinpool.com when it goes down for brief periods of time. Either the mining window stops doing anything or it says work queue is empty and long poll messages every ~10 minutes endlessly.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JorgePasada on May 16, 2011, 08:26:18 PM
Just got the following error . . .
Code:
bitcoin@bitcoin:~/poclbm$ ./poclbm.py
Traceback (most recent call last):
  File "./poclbm.py", line 27, in <module>
    platforms = cl.get_platforms()
pyopencl.LogicError: clGetPlatformIDs failed: invalid/unknown error code

Any Help?

Just followed the 11.04 thread guide http://bitcointalk.org/index.php?topic=7514.0 (http://bitcointalk.org/index.php?topic=7514.0) at that link.

Got the error above. I went with SDK 2.4

Should I be using 2.4 or 2.1? I'm mainly running on 5xxx series hardware.

Thanks to everyone who's contributing to this thread, sorry for the chatter, trying to learn is slow and painful . . .


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: evilpumpkin on May 17, 2011, 08:39:22 PM
Hi,

I get "Warning: work queue empty, miner is idle" both on mining.bitcoin.cz (RPC) and bitcoinpool.com (RPC+LP) with different queue sizes.
The following just occured with queue size 5:


[17/05/2011 22:17:05] Currently on block: 124681
[17/05/2011 22:17:05] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:05] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:05] New block (WorkQueue)
[17/05/2011 22:17:05] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:05] New block (WorkQueue)
[17/05/2011 22:17:06] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:06] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:06] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:06] New block (WorkQueue)
[17/05/2011 22:17:06] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:06] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:06] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:06] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:06] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:16] Server gave new work; passing to WorkQueue
[17/05/2011 22:17:16] New block (WorkQueue)
[17/05/2011 22:17:32] Result ...0000000019288c5d accepted
[17/05/2011 22:17:53] Result ...0000000045b2e911 accepted
[17/05/2011 22:18:17] Warning: work queue empty, miner is idle
[0 Khash/sec] [15 Accepted] [0 Rejected] [RPC]


It seems that the miner neglected to get new jobs, the last time work on a new block started.

Can anyone tell me where this problem might come from or maybe even how to fix it?


Thanks in advance


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: benjamindees on May 18, 2011, 02:46:09 AM
Just to post my experience, I have switched from poclbm-mod to phoenix (poclbm), and my reported hashrate is 10% higher with the GPU running 5 degrees C cooler.  I'll have to see whether that translates into a higher payout or not.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Shiver on May 18, 2011, 04:40:53 AM
I have the same experience, but I have to use the mod version of poclbm because otherwise I get the "miner is idle" reports every several hours.  I was about to install the Phoenix app as an alternative until I read this thread and seeing that it has the same issue.  Perhaps I'll have to get a wrapper application that will baby sit the miner and restart it when necessary.


Just to post my experience, I have switched from poclbm-mod to phoenix (poclbm), and my reported hashrate is 10% higher with the GPU running 5 degrees C cooler.  I'll have to see whether that translates into a higher payout or not.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 18, 2011, 06:03:16 AM
Jedi95 there something can be done about this?
http://i.imgur.com/Qvbxm.png

Coding my C program to parse it and get the mhash/s is easy, (last line, seach for [ ), but the file size increase in about 1KB per second!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: yrral on May 18, 2011, 07:09:25 AM
Jedi95 there something can be done about this?
http://i.imgur.com/Qvbxm.png

Coding my C program to parse it and get the mhash/s is easy, (last line, seach for [ ), but the file size increase in about 1KB per second!
I think the problem is that your language interprets the \b control character as some character. Change your system locale or just pipe the output through sed.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 18, 2011, 07:50:29 AM
Jedi95 there something can be done about this?
http://i.imgur.com/Qvbxm.png

Coding my C program to parse it and get the mhash/s is easy, (last line, seach for [ ), but the file size increase in about 1KB per second!

Your best option would be to modify ConsoleLogger to log only the information you want. The hashrate/accepted/rejected are reported separately from log messages so it should be easy to make it output exactly what you want and nothing else.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3athrow on May 18, 2011, 08:33:31 AM
I love this miner, this + the phatk kernel i get 10 - 25mh/s more with my 5830 than i do with poclbm or diablominer


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 18, 2011, 08:56:05 AM
Version 1.48 has been released.

Changes:
1. Fixed RPC connection lost callback failing. This *SHOULD* fix the remaining issues with the miner idling.
2. Added phatk kernel to release packages. The included version has the same FASTLOOP changes as the poclbm kernel.
3. Added a warning if WORKSIZE is set incorrectly and the default is used instead.
4. Adds https:// support for connecting to SSL enabled bitcoin clients.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jondecker76 on May 18, 2011, 09:33:55 AM
Going to try 1.48 right now,  the idling problem has been absolutely killing me, having to restart things 10+ times per day!  
I did an svn update yesterday and it still went idle on me over the night again (it was r86)... Just did an SVN update again just now, but it only pulled in one change file (RPCProtocol.py).  Now at r94, will report back if the ugly idle problem reappears again!



EDIT:
WOW!  Worse than ever!  Goes idle on all 3 cards within a couple of minutes..  Tried several times, going to reboot and try again :(

EDIT 2:
Still nothing good,  All 3 sessions go idle quite often, but sometimes within a minute or so it will start hashing again, but eventually it ends up just sitting there idle


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 18, 2011, 10:11:06 AM
My problem is that I have been unable to reproduce any sort of idle problems with 1.46 and later.

Right now the only thing I can do is look at the code and try to figure out WTF is going on. What pool are you connecting to? I can't fix it unless I can see it fail for myself or someone posts enough details for me to figure out what exactly is going wrong.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: benjamindees on May 18, 2011, 10:37:55 AM
try bitcoinpool.com


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jondecker76 on May 18, 2011, 10:55:30 AM
connecting to deepbit with all my idle problems


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 18, 2011, 11:01:07 AM
Thanks, I'll run 1 5870 on each pool overnight with lots of extra debug messages enabled and see what happens. Hopefully I will find at least one of them idling so I can get to the bottom of this.

Interestingly I have tested with both those pools before. I blocked packets to the IPs to simulate the server being down/unresponsive and in each case the miner recovered once I unblocked the IP again.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jondecker76 on May 18, 2011, 11:03:23 AM
let me try one more thing....  I've switched in the last week to a wireless connection (usb wifi adapter)  and the connection seems super slow (so slow that I have problems even sshing into the box) and it just occurred to me that there might be a link there..  Just went back to wired and restarted the miner, I'll report back if that solves my problems so you don't go wasting your time


thanks


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 18, 2011, 11:06:47 AM
let me try one more thing....  I've switched in the last week to a wireless connection (usb wifi adapter)  and the connection seems super slow (so slow that I have problems even sshing into the box) and it just occurred to me that there might be a link there..  Just went back to wired and restarted the miner, I'll report back if that solves my problems so you don't go wasting your time


thanks

That could be it, since if you can barely SSH into the box it's possible that it's not able to get work fast enough to keep the GPU fed with work. Even so, I already setup the miners for testing so might as well let them run.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jondecker76 on May 18, 2011, 12:02:41 PM
I switched back to wired and everything has been doing great so far - so it looks like it was definitely related to a flaky wireless adapter!  Good news for both of us :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kwukduck on May 18, 2011, 01:26:14 PM
I'm just a big noob here, running ubuntu natty but can't seem to install pyopencl

whenever i try to install package python-pyopencl it starts bitching about the package nvidia-current, which is unable to install, without this package installed it can't configure pyopencl somehow...

This is what installer returns if it tries to install nvidia-current

Code:
kwukduck@home2:~$ sudo apt-get install python-pyopencl
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  nvidia-current
Suggested packages:
  python-imaging-tk
Recommended packages:
  nvidia-opencl-icd
The following NEW packages will be installed:
  nvidia-current python-pyopencl
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/50.3 MB of archives.
After this operation, 154 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
(Reading database ... 143428 files and directories currently installed.)
Unpacking nvidia-current (from .../nvidia-current_270.41.06-0ubuntu1_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/nvidia-current_270.41.06-0ubuntu1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/libOpenCL.so', which is also in package amd-app 2.4
Selecting previously deselected package python-pyopencl.
Unpacking python-pyopencl (from .../python-pyopencl_0.92-1ubuntu1_amd64.deb) ...
Processing triggers for man-db ...
Errors were encountered while processing:
 /var/cache/apt/archives/nvidia-current_270.41.06-0ubuntu1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 18, 2011, 08:21:09 PM
Test results are in:

No idle miners, but I did find a completely unrelated bug in long polling. If the server sends a message over long polling, then long polling will stop working until you either restart the miner or the connection to the server is lost/regained. This has been fixed in SVN already, and it will be included in the next release.


I'm just a big noob here, running ubuntu natty but can't seem to install pyopencl

whenever i try to install package python-pyopencl it starts bitching about the package nvidia-current, which is unable to install, without this package installed it can't configure pyopencl somehow...

This is what installer returns if it tries to install nvidia-current


You have to recompile pyopencl without the nvidia-current dependency.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitclown on May 18, 2011, 11:07:30 PM
No idle miners, but I did find a completely unrelated bug in long polling. If the server sends a message over long polling, then long polling will stop working until you either restart the miner or the connection to the server is lost/regained. This has been fixed in SVN already, and it will be included in the next release.

I've been running SVN rev 97 for a couple of hours now with BitcoinPool, and the idling issue still persists. At most I waited 10 minutes before restarting Phoenix, it then connected and fetched new work immediately.

Python 2.6.6
Twisted 11.0.0


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 18, 2011, 11:30:28 PM
Your best option would be to modify ConsoleLogger to log only the information you want. The hashrate/accepted/rejected are reported separately from log messages so it should be easy to make it output exactly what you want and nothing else.

im not a python programer, but i think it can be made by adding:
Quote
   def updateStatus(self, force=False):
        #only update if last update was more than a second ago
        dt = time() - self.lastUpdate
        if force or dt > self.UPDATE_TIME:
            rate = self.rate if (not self.miner.idle) else 0
            type = " [" + str(self.connectionType) + "]" if self.connectionType is not None else ''
            status = (
                "[" + formatNumber(rate) + "hash/sec] "
                "[" + str(self.accepted) + " Accepted] "
                "[" + str(self.invalid) + " Rejected]" + type)
            self.say(status)
            fileHandle = open ( 'status.txt', 'w' )
            fileHandle.write(status)
            fileHandle.close()
            self.lastUpdate = time()
? i think i need to check how to add a new command line argument to use it for the file name..... mmm google here i go!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 18, 2011, 11:35:44 PM
No idle miners, but I did find a completely unrelated bug in long polling. If the server sends a message over long polling, then long polling will stop working until you either restart the miner or the connection to the server is lost/regained. This has been fixed in SVN already, and it will be included in the next release.

I've been running SVN rev 97 for a couple of hours now with BitcoinPool, and the idling issue still persists. At most I waited 10 minutes before restarting Phoenix, it then connected and fetched new work immediately.

Python 2.6.6
Twisted 11.0.0

Hmm, well I still can't fix it if I don't know what's wrong. This means I have to see it for myself or someone has to post highly detailed information. (run with -v to add verbose output, then post the log messages.)

EDIT:
Mostly what I need to know is if you have a "Disconnected from server" and then "Failed to connect, retrying...." after it goes idle. If my understanding of the issue is correct there is a problem with the disconnect being reported and thus it never tries to reconnect and just sits there. If you don't get these messages then I have the right idea. Otherwise I have been looking in the wrong place.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitclown on May 19, 2011, 12:21:24 AM
Mostly what I need to know is if you have a "Disconnected from server" and then "Failed to connect, retrying...." after it goes idle. If my understanding of the issue is correct there is a problem with the disconnect being reported and thus it never tries to reconnect and just sits there. If you don't get these messages then I have the right idea. Otherwise I have been looking in the wrong place.
I don't get any error or diagnostics messages besides "Warning: work queue empty, miner is idle", even after sending SIGINT. Here's the full log:
Code:
$ svn up
At revision 97.
$ ./phoenix.py -u http://PonyBaloney:***@bitcoinpool.com:8334/ -v -k poclbm DEVICE=1 VECTORS BFI_INT AGGRESSION=12
[19/05/2011 02:05:04] Phoenix r86 starting...
[19/05/2011 02:05:05] Connected to server
[19/05/2011 02:05:05] Server gave new work; passing to WorkQueue
[19/05/2011 02:05:05] New block (WorkQueue) 
[19/05/2011 02:05:05] Server gave new work; passing to WorkQueue
[19/05/2011 02:05:16] Server gave new work; passing to WorkQueue
[19/05/2011 02:05:16] Result 000000002dd85b62... accepted
[19/05/2011 02:05:16] Result 00000000eafda01c... accepted
[19/05/2011 02:05:27] Server gave new work; passing to WorkQueue
[19/05/2011 02:05:27] Result 00000000d1f4cb13... accepted
[19/05/2011 02:05:28] Result 000000000d44f7cb... accepted
[19/05/2011 02:05:29] Result 0000000037d080df... accepted
[19/05/2011 02:05:33] Result 000000001ea49bfd... accepted
[19/05/2011 02:05:36] Server gave new work; passing to WorkQueue
[19/05/2011 02:05:39] Result 000000002d3fc4f9... accepted
[19/05/2011 02:05:47] Server gave new work; passing to WorkQueue
[19/05/2011 02:05:53] Result 000000008e7ae512... accepted
[19/05/2011 02:05:56] Server gave new work; passing to WorkQueue
[19/05/2011 02:05:59] Result 000000004da386a2... accepted
[19/05/2011 02:06:01] Result 00000000dfa6d714... accepted
[19/05/2011 02:06:09] Result 00000000583c8de4... accepted
[19/05/2011 02:06:16] Warning: work queue empty, miner is idle
[19/05/2011 02:06:19] Server gave new work; passing to WorkQueue
[19/05/2011 02:06:20] Server gave new work; passing to WorkQueue
[19/05/2011 02:06:21] Result 0000000090497502... accepted
[19/05/2011 02:06:29] Server gave new work; passing to WorkQueue
[19/05/2011 02:06:40] Server gave new work; passing to WorkQueue
[19/05/2011 02:06:50] Server gave new work; passing to WorkQueue
[19/05/2011 02:07:01] Server gave new work; passing to WorkQueue
[19/05/2011 02:07:09] Result 000000005a08c825... accepted
[19/05/2011 02:07:17] Server gave new work; passing to WorkQueue
[19/05/2011 02:07:17] New block (WorkQueue)             
[19/05/2011 02:07:18] LP: New work pushed               
[19/05/2011 02:07:18] Server gave new work; passing to WorkQueue
[19/05/2011 02:07:19] Server gave new work; passing to WorkQueue
[19/05/2011 02:07:27] Server gave new work; passing to WorkQueue
[19/05/2011 02:07:29] Result 00000000b913c353... accepted
[19/05/2011 02:07:38] Server gave new work; passing to WorkQueue
[19/05/2011 02:07:49] Server gave new work; passing to WorkQueue
[19/05/2011 02:07:52] Result 0000000095161e35... accepted
[19/05/2011 02:07:55] Result 000000007ad2d6b7... accepted
[19/05/2011 02:07:58] Server gave new work; passing to WorkQueue
[19/05/2011 02:08:05] Result 0000000035d60b6f... accepted
[19/05/2011 02:08:08] Server gave new work; passing to WorkQueue
[19/05/2011 02:08:17] Result 00000000fa673e1c... accepted
[19/05/2011 02:08:19] Result 000000004a857f84... accepted
[19/05/2011 02:08:19] Server gave new work; passing to WorkQueue
[19/05/2011 02:08:29] Server gave new work; passing to WorkQueue
[19/05/2011 02:08:49] Warning: work queue empty, miner is idle
[0 Khash/sec] [19 Accepted] [0 Rejected] [RPC (+LP)]^C          <- Waited 5 minutes before interrupting.
$

Even if this turns out to be a pool failure, shouldn't there be some timeouts for retries?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 19, 2011, 12:34:32 AM
BTW, increasing queue size cant help those ppl having "miner is idle"? i think it worth a try.


I think this should do the hash/s log(export) thing.

phoenix.py
Quote
   def _parse(self):
        parser = OptionParser(usage="%prog -u URL [-k kernel] [kernel params]")
        parser.add_option("-v", "--verbose", action="store_true",
            dest="verbose", default=False, help="show debug messages")
        parser.add_option("-k", "--kernel", dest="kernel", default="poclbm",
            help="the name of the kernel to use")
        parser.add_option("-u", "--url", dest="url", default=None,
            help="the URL of the mining server to work for [REQUIRED]")
        parser.add_option("-q", "--queuesize", dest="queuesize", type="int",
            default=1, help="how many work units to keep queued at all times")
        parser.add_option("-a", "--avgsamples", dest="avgsamples", type="int",
            default=10,
            help="how many samples to use for hashrate average")
        parser.add_option("-lt", "--logtotext", dest="logtotext", default="none",
        
        self.parsedSettings, args = parser.parse_args()

Quote
   def makeLogger(self, requester, miner):
        if not self.logger:
            self.logger = ConsoleLogger(miner, self.parsedSettings.verbose, self.parsedSettings.logtotext)
        return self.logger

ConsoleLogger.py
Quote
   def __init__(self, miner, verbose=False, logtotext):
        self.verbose = verbose
        self.miner = miner
        self.logtotext = logtotext
        self.lastUpdate = time() - 1
        self.rate = 0
        self.accepted = 0
        self.invalid = 0
        self.lineLength = 0
        self.connectionType = None

Quote
       
    def updateStatus(self, force=False):
        #only update if last update was more than a second ago
        dt = time() - self.lastUpdate
        if force or dt > self.UPDATE_TIME:
            rate = self.rate if (not self.miner.idle) else 0
            type = " [" + str(self.connectionType) + "]" if self.connectionType is not None else ''
            status = (
                "[" + formatNumber(rate) + "hash/sec] "
                "[" + str(self.accepted) + " Accepted] "
                "[" + str(self.invalid) + " Rejected]" + type)
            self.say(status)
            if(self.logtotext != "none")
                fileHandle = open ( logtotext, 'w' )
                fileHandle.write(status)
                fileHandle.close()
            self.lastUpdate = time()
        

I gona try it once i figured out how to compile something in Python hahaha.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: benjamindees on May 19, 2011, 01:16:31 AM
Python is an interpreted language.  There's no need to compile anything.  You can use py2exe to create an executable but it's just a wrapper.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JorgePasada on May 19, 2011, 01:47:36 AM
I just got this up and running on my rig.

1x 5970 and 2x 5850's /w another 5850 on the way.

Using SDK v 2.4, pain in the a$$ to find a couple errors caused by that. I'm pulling average numbers currently, lots of variance 900mhash to 1.2ghash depending on the time.

Can anyone recommend any settings I can tweak to decrease the level of variance for each GPU?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 19, 2011, 03:06:33 AM
Mostly what I need to know is if you have a "Disconnected from server" and then "Failed to connect, retrying...." after it goes idle. If my understanding of the issue is correct there is a problem with the disconnect being reported and thus it never tries to reconnect and just sits there. If you don't get these messages then I have the right idea. Otherwise I have been looking in the wrong place.
I don't get any error or diagnostics messages besides "Warning: work queue empty, miner is idle", even after sending SIGINT. Here's the full log:

Even if this turns out to be a pool failure, shouldn't there be some timeouts for retries?

This confirms that the cause is disconnects/timeouts not being detected. I think I know what I need to change, but it's somewhat harder for me at the moment because CFSworks wrote the entire RPC implementation and he hasn't been around for more than a week.


I just got this up and running on my rig.

1x 5970 and 2x 5850's /w another 5850 on the way.

Using SDK v 2.4, pain in the a$$ to find a couple errors caused by that. I'm pulling average numbers currently, lots of variance 900mhash to 1.2ghash depending on the time.

Can anyone recommend any settings I can tweak to decrease the level of variance for each GPU?

Use the phatk kernel, AGGRESSION between 7 and 12, VECTORS and BFI_INT. You might also see an increase with WORKSIZE=128, but the default of 256 is working optimally for me on 5870s.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Internet151 on May 19, 2011, 01:16:47 PM
I can also confirm even with -v enabled phoenix 1.48 will sometimes not reconnect/keep going after a work queue is empty miner is idle message and no further info.

Sometimes this will cause all 9 of my GPU's in my 3 pc's to stop, and sometimes a few of them will pick back up.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Eikill on May 19, 2011, 02:04:42 PM
I need some help. I have a Sapphire 5770 card with no overclock running on SDK version 2.1 and driver version 10.11 (Because I've heard they are best for 5xxx cards, is this true?) and when I run the  miner I get this error,

Code:
C:\pminer>phoenix -u http://@deepbit.net:8332/
 -k poclbm DEVICE=1 VECTORS BFI_INT FASTLOOP=false AGGRESSION=11
Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
  File "Miner.pyc", line 75, in start
  File "phoenix.py", line 111, in makeKernel
  File "kernels\poclbm\__init__.py", line 22, in <module>
    import pyopencl as cl
  File "zipextimporter.pyc", line 82, in load_module
  File "pyopencl\__init__.pyc", line 3, in <module>
  File "zipextimporter.pyc", line 98, in load_module
ImportError: MemoryLoadLibrary failed loading pyopencl\_cl.pyd

I think there is something wrong with OpenCL or something, but I've tried to reinstall both SDK and drivers with no success.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 19, 2011, 02:08:39 PM
use 11.4/11.5 and sdk 2.1, anything lower than 11.3 does not work for mining for me, the GPU device cant be seen by miners, be phoenix or guiminer.

Funny thing is that openCL acually works on gpu using older drivers (directcompute benchmark incluides a opencl benchmark), so i have no idea of what is going on.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JayC on May 19, 2011, 10:17:33 PM
Anybody else having problems connecting to the SVN?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 19, 2011, 10:42:24 PM
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)

Download 1.48 debug build

Windows binaries (http://svn3.xp-dev.com/svn/phoenix-miner/files/phoenix-1.48-debug.zip)
Source code/Linux release (http://svn3.xp-dev.com/svn/phoenix-miner/files/phoenix-1.48.tar-debug.bz2) (requires Python, Twisted, and PyOpenCL)

SVN:
http://svn3.xp-dev.com/svn/phoenix-miner/


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitclown on May 19, 2011, 10:50:37 PM
Nice work! Testing r99 now. Will let you know how it turns out.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Inaba on May 19, 2011, 11:25:36 PM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 19, 2011, 11:37:27 PM
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)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jondecker76 on May 20, 2011, 12:43:27 AM
I ran revision 97 for about 24 hours on a wired connection and finally one of my 3 instances went idle...  Just updated to revision 99, will see how it does!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: marcus_of_augustus on May 20, 2011, 01:11:58 AM

Anybody using the "phatk" kernel on HD 5970 ??

Did a quick test on one of my cores and didn't see any noticeable difference over pocblm (less if anything..... SDK 2.1, fglrx 11.2, clocks  800/300)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 20, 2011, 01:35:18 AM

Anybody using the "phatk" kernel on HD 5970 ??

Did a quick test on one of my cores and didn't see any noticeable difference over pocblm (less if anything..... SDK 2.1, fglrx 11.2, clocks  800/300)

It's only beneficial on SDK 2.4. For 2.1 use poclbm.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: charbo on May 20, 2011, 02:06:59 AM
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


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Inaba on May 20, 2011, 06:27:20 AM
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 :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 20, 2011, 07:47:38 AM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitclown on May 20, 2011, 08:17:10 AM
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)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dadittox on May 20, 2011, 08:58:21 AM
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


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 20, 2011, 09:29:39 AM
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.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dadittox on May 20, 2011, 10:04:25 AM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: marcus_of_augustus on May 20, 2011, 10:12:41 AM

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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 20, 2011, 10:35:40 AM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jkminkov on May 20, 2011, 01:45:15 PM
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


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on May 20, 2011, 05:27:54 PM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: error on May 20, 2011, 05:31:13 PM
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  


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: check on May 20, 2011, 05:38:34 PM
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!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: allinvain on May 20, 2011, 06:01:45 PM
1.48 is out..try that...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BOARBEAR on May 20, 2011, 09:47:16 PM
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


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nster on May 20, 2011, 10:33:35 PM
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


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 21, 2011, 12:41:54 AM
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/


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: OVerLoRDI on May 21, 2011, 06:12:25 AM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Bitcoineruk on May 21, 2011, 08:57:57 AM
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


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SoreGums on May 21, 2011, 10:33:44 AM
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 :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitclown on May 21, 2011, 01:49:11 PM
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!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: someee on May 21, 2011, 08:23:31 PM
whats new in 1.48 compared to 1.47?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: mewantsbitcoins on May 21, 2011, 08:27:08 PM
whats new in 1.48 compared to 1.47?

number 7 changed to number 8


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: charbo on May 21, 2011, 09:02:24 PM
whats new in 1.48 compared to 1.47?

number 7 changed to number 8

BIG OWNED


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on May 22, 2011, 07:31:30 AM
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.


no, it did not. two miners stopped this night. I was using -q 2. I am on 10.12/2.1 and will switch to 11.5/2.1 to see if it helps.

http://bitcoinx.com/miner_idle.png


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on May 22, 2011, 07:33:00 AM
is it possible to set the poclbm frames flag? -f 40 does not seem to work.

or is there some other way to set priority within a gpu?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jondecker76 on May 22, 2011, 08:19:04 AM
I have been running flawlessly for a few days now with no more idling problems, thank you!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: mosimo on May 22, 2011, 09:44:53 AM
The one problem that I have really is my computer will happily work for 2 days straight mining then the display drivers will crash. This causes phoenix to basically stall. It doesn't stop responding, it just stalls at it's current Hash/s and last sent hash. It doesn't get new work even when pushed. Is there anything you can do to restart it once a display driver crashes. I don't really want to lower the core clock or increase the mem clock as it's at a nice rate now and this only happens every so often.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SmokeTooMuch on May 22, 2011, 09:47:25 AM
is it possible to set the poclbm frames flag? -f 40 does not seem to work.

or is there some other way to set priority within a gpu?

I guess you have to use the AGGRESSION=X switch, where x is the level of aggression you want to have (default is 4, lower -> more resources for other programs, higher -> more resources for phoenix)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grndzero on May 22, 2011, 07:28:54 PM
I had to escape the ;askrate on linux or else OpenCL would say it couldn't find the device.
phoenix -u http://USERNAME.WORKERNAME:PASSWORD@mining.bitcoin.cz:8332/\;askrate=12 -k poclbm DEVICE=2 VECTORS AGGRESSION=12

Standard poclbm/poclbm-mod were giving me 317Mh/s.
Phoenix was giving me 310Mh/s.
That went up to 343.5Mh/s with BFI_INT!

If you're using askrate make sure to set it properly. Calculate (type into Google) 2^32 divided by your hashrate. So mine would be 2^32/343500000=12.5035438 (so 12)

Nice to see that BFI_INT is working for you!

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.

"The worker hash rates shown below are estimates based on share submissions in the last 15 minutes. These will rarely be the same as your miner's actual hash rate."

Wait a while and see if it improves. Right now my Total Worker Speed says it's 30 Mh/s slower than I know it is. I've seen it show 100 Mh/s higher at times also. It's going to fluctuate, it's really not anything to worry about.


Title: Close Window do same as Ctrl+C
Post by: SoreGums on May 22, 2011, 11:27:36 PM
Someone all ready brought it up earlier, however I have proper usecase for this now.

I'm using windows 7 and if i run the client and then use ctrl+c to close it, everything shuts down cleanly and life is good.
If I click the close window icon or kill the process it crashes the nvidia driver, the screen goes blank and windows says "graphics driver recovered ok"

Would it be possible to put the same code that makes stuff end nicely on ctrl+c in the same place as closing the window via the top right icon or killing the process.

the usecase is I'm using Task Scheduler to run the phoenix when the computer is idle, works great except for the task scheduler killing the process when the computer is not idle anymore as it crashes the nvidia driver and the screen goes blank for a second etc...

Thanks :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: FairUser on May 22, 2011, 11:33:57 PM
Hey Jedi95,

Would it be possible for you to have a config file which contains all the information that I would normally specify on the command line?  The reason I ask is because (in linux) when I run your miner, my login and password can be viewed by anyone else on the box who runs a "ps -a".  If there was a "-config <filename>" option, that would be great and would add a bit more security for those who share a box with someone else.

Thanks for being awesome.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: minerX on May 23, 2011, 08:23:05 AM
Hey Jedi95,

Would it be possible for you to have a config file which contains all the information that I would normally specify on the command line?  The reason I ask is because (in linux) when I run your miner, my login and password can be viewed by anyone else on the box who runs a "ps -a".  If there was a "-config <filename>" option, that would be great and would add a bit more security for those who share a box with someone else.

Thanks for being awesome.



Honestly I think this is an issue for the pools.  They shouldn't be using worker names that are connected to the main login.  For example deepbit uses emailname@gmail.com_0, _1, etc.  BTC Guild uses loginname_workerID.

But either, the most that can happen is they redirect your BTC transactions.  But both pools have security against this.  If you use an original password I think you will be OK. 


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jrmithdobbs on May 23, 2011, 02:20:46 PM
Can you add a --sane-output (or similar) option that doesn't rewrite the terminal?

For now I'm just using this (hacky) patch to make it stop doing so:

https://github.com/jrmithdobbs/phoenix-miner/commit/024a66dbced7be2306662f40b67f1675486738d4

Edit: It'd also be helpful if you'd point me in the direction of the code that is writing/patching the final binary so i can change it to use /tmp instead of the kernel directory. I hate windows-per-app-install-directory-isms on my unix machines and am trying to move kernel/ to /usr/share/phoenix-miner but don't want to give the user who runs this write access anywhere in /usr/share. ;)

Edit: nevermind I found it. Here's a patch that changes the expectation of kernels being in CWD to being in /usr/share/phoenix-miner/ and writes the binaries to TMPDIR (if set) or /tmp (if not). I'm sure this breaks on windows.

https://github.com/jrmithdobbs/phoenix-miner/commit/4bad15f3df349fe07c69a0b82ca205e9c58c23d9

Edit: Replaced code blocks with github links since I noticed the whitespace breakage in those patches.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Eikill on May 23, 2011, 03:09:21 PM
I've got a Sapphire 5770 with driver version 11.4 (because 10.11 did not work) and SDK 2.1, and I get this message when I start the miner:

Code:
FATAL kernel error: Failed to apply BFI_INT patch to kerne
l! Is BFI_INT supported on this hardware?

I thought BFI_INT was supported on all 5xxx and up cards?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: foggyb on May 23, 2011, 03:21:35 PM
What is the format for command line mining (solo) while connected to LAN bitcoin server?

I am using win7 on both PC's. Local PC is mining as RPC client, but i can't get phoenix to work at all. GUminer is not able to connect from 2nd PC.

Help!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SoreGums on May 23, 2011, 04:12:22 PM
Local PC is mining as RPC client, but i can't get phoenix to work at all. GUminer is not able to connect from 2nd PC.

https://en.bitcoin.it/wiki/Running_Bitcoin

you probably need to add "rpcallowip" into config file...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: foggyb on May 23, 2011, 05:03:07 PM
Local PC is mining as RPC client, but i can't get phoenix to work at all. GUminer is not able to connect from 2nd PC.

https://en.bitcoin.it/wiki/Running_Bitcoin

you probably need to add "rpcallowip" into config file...

When I add that command to command line or conf file, this happens:

http://dl.dropbox.com/u/5765587/error1.png



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tumaru on May 24, 2011, 12:04:51 AM
I am running a nvidia G102m, core 2 duo running windows 7 64 bit. With this and every time I try to run it this error comes up and if I run it with these particular settings my graphics card driver will crash with this error message. I am running the current graphics driver 270.61. If I use VECTORS BFI_INT then my driver doesn't crash but the same error message comes up.

C:\Program Files (x86)\Bitcoin\phoenix-1.48>phoenix -u http://username:password@bitcoinpool.com:8334/ -k poclbm

FASTLOOP=false AGGRESSION=9
[23/05/2011 16:39:49] Phoenix 1.48 starting...
[23/05/2011 16:39:50] Connected to server
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]Unhandled Error
Traceback (most recent call last):
  File "threading.pyc", line 504, in __bootstrap

  File "threading.pyc", line 532, in __bootstrap_inner

  File "threading.pyc", line 484, in run

--- <exception caught here> ---
  File "twisted\python\threadpool.pyc", line 207, in _worker

  File "twisted\python\context.pyc", line 118, in callWithContext

  File "twisted\python\context.pyc", line 81, in callWithContext

  File "kernels\poclbm\__init__.py", line 392, in mineThread

pyopencl.LogicError: clEnqueueReadBuffer failed: invalid command queue




If I use these settings then this error message comes up and it just keeps on saying failed to connect.

C:\Program Files (x86)\Bitcoin\phoenix-1.48>phoenix -u http://username:password@bit
coinpool.com:8334/-k poclbm -v VECTORS BFI_INT AGGRESSION=7
[23/05/2011 16:59:23] Phoenix 1.48 starting...
[23/05/2011 16:59:23] Failed to connect, retrying...
[23/05/2011 16:59:42] Failed to connect, retrying...
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 24, 2011, 03:56:13 AM
I am running a nvidia G102m, core 2 duo running windows 7 64 bit. With this and every time I try to run it this error comes up and if I run it with these particular settings my graphics card driver will crash with this error message. I am running the current graphics driver 270.61. If I use VECTORS BFI_INT then my driver doesn't crash but the same error message comes up.

C:\Program Files (x86)\Bitcoin\phoenix-1.48>phoenix -u http://username:password@bitcoinpool.com:8334/ -k poclbm

FASTLOOP=false AGGRESSION=9
[23/05/2011 16:39:49] Phoenix 1.48 starting...
[23/05/2011 16:39:50] Connected to server
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]Unhandled Error
Traceback (most recent call last):
  File "threading.pyc", line 504, in __bootstrap

  File "threading.pyc", line 532, in __bootstrap_inner

  File "threading.pyc", line 484, in run

--- <exception caught here> ---
  File "twisted\python\threadpool.pyc", line 207, in _worker

  File "twisted\python\context.pyc", line 118, in callWithContext

  File "twisted\python\context.pyc", line 81, in callWithContext

  File "kernels\poclbm\__init__.py", line 392, in mineThread

pyopencl.LogicError: clEnqueueReadBuffer failed: invalid command queue




If I use these settings then this error message comes up and it just keeps on saying failed to connect.

C:\Program Files (x86)\Bitcoin\phoenix-1.48>phoenix -u http://username:password@bit
coinpool.com:8334/-k poclbm -v VECTORS BFI_INT AGGRESSION=7
[23/05/2011 16:59:23] Phoenix 1.48 starting...
[23/05/2011 16:59:23] Failed to connect, retrying...
[23/05/2011 16:59:42] Failed to connect, retrying...
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

First of all Nvidia GPUs don't support BFI_INT so adding that flag won't work. Secondly lowend Nvidia cards are very slow miners, which at the current difficulty are pointless to run.

I'm not sure how you are getting "clEnqueueReadBuffer failed: invalid command queue" though.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nelisky on May 24, 2011, 04:24:29 PM
I'm on ubuntu and have been mining with phoenix/poclbm happily, no locks, against a local bitcoind instance. Today I decided to give a pool a go, and for 2 times in 5 hours I got the "Warning: work queue empty, miner is idle" that would just stay there until I Ctrl+C and restart that miner.

The obvious difference? Long polling. I've commented out the long poll thread start() so I can make sure that is the issue, but what I really feel is missing is an option to disable it. I don't have a patch (just a #) but can cook one if that feels important to anyone else.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: check on May 24, 2011, 06:13:52 PM
Just to follow up, "1.48 debug" seemed to improve things at first for a 6950 under Win7, but I'm still not having much luck with it.  It doesn't seem to actually get stuck, but it spends most of its time idling.  It seems to eventually recover, but then it will idle again after a few minutes.

phoenix-1.48-debug>phoenix -u http://user:pass@bitcoinpool.com:8334/ -v -q 2 -k poclbm DEVICE=0 AGGRESSION=10 BFI_INT PLATFORM=1 WORKSIZE=128
...
[24/05/2011 10:42:46] Warning: work queue empty, miner is idle
[24/05/2011 11:00:13] LP: New work pushed
[24/05/2011 11:00:13] Server gave new work; passing to WorkQueue
[24/05/2011 11:00:13] New block (WorkQueue)
[24/05/2011 11:00:16] Result 00000000f651082d... accepted
[24/05/2011 11:00:18] Result 000000002db4051c... accepted
[24/05/2011 11:00:25] Warning: work queue empty, miner is idle
[24/05/2011 11:03:00] LP: New work pushed
[24/05/2011 11:03:00] Server gave new work; passing to WorkQueue
[24/05/2011 11:03:00] New block (WorkQueue)
[24/05/2011 11:03:12] Warning: work queue empty, miner is idle
[0 Khash/sec] [360 Accepted] [6 Rejected] [RPC (+LP)]

Killing it and starting fresh always seems to do well for a while, which makes me think it's not solely a pool problem.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on May 24, 2011, 07:10:11 PM
I'm working on an extensive debug build that will dump out a highly detailed logfile every time the miner goes idle. Hopefully this will enable me to find the cause of this bug.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitcoinington on May 25, 2011, 04:23:15 AM
Hoping someone can help me here because i'm seeing some strange behavior in phoenix miner

when i'm mining on a pool i get a good hash rate and my accepted/rejected ratio is around 2000/40.

however, when i'm mining solo (using bitcoind as server and http://user:pass@localhost:8332 as the server) it shows that it is connected to the server and the hash rate is 430mh/s but it consistently stays at 0 Accepted and 0 Rejected.

anyone have an idea of what's going on? here's the commandline i'm using

-u http://user:pass@localhost:8332 -k poclbm device=0 vectors bfi_int aggression=7

any help would be greatly appreciated!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: error on May 25, 2011, 04:26:55 AM
Hoping someone can help me here because i'm seeing some strange behavior in phoenix miner

when i'm mining on a pool i get a good hash rate and my accepted/rejected ratio is around 2000/40.

however, when i'm mining solo (using bitcoind as server and http://user:pass@localhost:8332 as the server) it shows that it is connected to the server and the hash rate is 430mh/s but it consistently stays at 0 Accepted and 0 Rejected.

anyone have an idea of what's going on? here's the commandline i'm using

-u http://user:pass@localhost:8332 -k poclbm device=0 vectors bfi_int aggression=7

any help would be greatly appreciated!

If you mine solo, you won't see anything accepted until you find a full 50BTC block.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: twmz on May 25, 2011, 04:29:07 AM
however, when i'm mining solo (using bitcoind as server and http://user:pass@localhost:8332 as the server) it shows that it is connected to the server and the hash rate is 430mh/s but it consistently stays at 0 Accepted and 0 Rejected.

That's normal.  When you are in a pool, the pool "lies" to your mining client and tells it to calculate work at an artificially low difficulty.  As a result, you find what you think are valid blocks pretty frequently.  Pools call these shares.  The pool does this so that it can more effectively tell that you are doing real work on a regular basis.  Every once in a while these one of these shares will end up being a valid block for the "real" difficultly and that is when the pool ends up finding a block.

When you mine solo, you are now mining with the "real" difficulty directly.  You'll only get an "accepted" message when you find a real block (and earn 50 BTC).  This will be much much less often than you are used to as compared to finding accepted shares on a pool (days or weeks between blocks depending on your hash rate).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on May 25, 2011, 04:37:00 AM
however, when i'm mining solo (using bitcoind as server and http://user:pass@localhost:8332 as the server) it shows that it is connected to the server and the hash rate is 430mh/s but it consistently stays at 0 Accepted and 0 Rejected.

That's normal.  When you are in a pool, the pool "lies" to your mining client and tells it to calculate work at an artificially low difficulty.  As a result, you find what you think are valid blocks pretty frequently.  Pools call these shares.  The pool does this so that it can more effectively tell that you are doing real work on a regular basis.  Every once in a while these one of these shares will end up being a valid block for the "real" difficultly and that is when the pool ends up finding a block.

When you mine solo, you are now mining with the "real" difficulty directly.  You'll only get an "accepted" message when you find a real block (and earn 50 BTC).  This will be much much less often than you are used to as compared to finding accepted shares on a pool (days or weeks between blocks depending on your hash rate).

Thanks, this solved my doubt, why i got zero only even though my gpu usage is 100%.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: trebo on May 25, 2011, 06:30:46 AM
I'm working on an extensive debug build that will dump out a highly detailed logfile every time the miner goes idle. Hopefully this will enable me to find the cause of this bug.

jedi95, I have a patch that logs to syslog on linux machines, can I send you the patches?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: gentakin on May 25, 2011, 09:40:09 AM
Thanks for this miner, it works pretty good for me with phatk (at least if I can trust the hash rate shown in the phoenix client)!

However, there is one problem (that I already posted in deepbits thread, knowing it's probably a phoenix problem):
Sometimes long polling stops working until I restart phoenix. Example:

Quote
[25/05/2011 10:49:38] Result: cea614c1 accepted           
[25/05/2011 10:49:42] Result: cc38d5ab accepted           
[25/05/2011 10:49:55] Result: 26e10d54 accepted           
[25/05/2011 10:50:08] Result: 5dd94d57 rejected           
[25/05/2011 10:50:18] Result: 3a240e80 rejected           
[25/05/2011 10:51:05] Result: 029664f3 accepted           
[25/05/2011 10:51:31] Result: 58578139 accepted           
[25/05/2011 10:51:58] Result: f7aa2b93 accepted           
[25/05/2011 10:52:12] Result: 8cffaddf accepted           
[25/05/2011 10:52:37] Result: 1f244382 accepted           
[25/05/2011 10:53:13] Result: d8f362a7 accepted           
[25/05/2011 10:53:22] Result: 9ea37ad4 rejected           
[25/05/2011 10:53:29] Result: af350f97 rejected           
[25/05/2011 10:53:44] Result: 3ebf2662 accepted           
[25/05/2011 10:54:13] Result: 2ef96a00 accepted           
[25/05/2011 10:54:14] Result: e40a052a accepted           
[25/05/2011 10:54:14] Result: 4c64a417 accepted           
[25/05/2011 10:54:15] Result: 6af612e9 accepted

And so on: No LP messages for a (very) long time, instead lots of (compared to usual amounts) rejected shares.

Restarting phoenix will fix it:
Quote
[25/05/2011 11:23:05] Phoenix r86 starting...
[25/05/2011 11:23:05] Connected to server
[25/05/2011 11:23:22] Result: da42db08 accepted         
[25/05/2011 11:23:43] LP: New work pushed               
[25/05/2011 11:23:53] Result: 08a0d468 accepted         
[25/05/2011 11:24:00] Result: ceca5dec accepted         
[25/05/2011 11:24:07] Result: b7c71390 accepted         
[25/05/2011 11:24:22] Result: 8c7814d1 accepted         
[25/05/2011 11:24:28] Result: 160c836f accepted         
[25/05/2011 11:24:54] Result: 39784e84 accepted         
[25/05/2011 11:25:18] Result: d4b22132 accepted         
[25/05/2011 11:25:24] Result: adf76db7 accepted         
[25/05/2011 11:25:30] Result: 4df9dc3c accepted         
[25/05/2011 11:25:43] Result: 00d196f2 accepted         
[25/05/2011 11:25:49] Result: 0aa99500 accepted         
[25/05/2011 11:26:06] Result: 29d79d72 accepted         
[25/05/2011 11:26:41] Result: 3a370dc4 accepted         
[25/05/2011 11:26:45] Result: 90e4bceb accepted         
[25/05/2011 11:27:14] Result: 9aa7a90a accepted         
[25/05/2011 11:27:17] Result: 15d32279 accepted         
[25/05/2011 11:27:20] LP: New work pushed               
[25/05/2011 11:27:52] Result: 140f2597 accepted         
[25/05/2011 11:27:55] Result: 1736843d accepted         
[25/05/2011 11:28:22] LP: New work pushed


It might be related to my rather unstable network connection (wireless lan) which might cause the LP connection to get lost without phoenix re-connecting when my network is back up again.
I'm using the latest revision from SVN (r99 if I remember correctly, although phoenix says it's r86 when starting..)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: error on May 25, 2011, 09:47:26 AM
That seems to be it. If the network connection is interrupted, phoenix doesn't seem to reestablish the long polling connection. That would explain everything (except for it stopping completely, which is still an outstanding issue).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nelisky on May 25, 2011, 10:30:51 AM
That seems to be it. If the network connection is interrupted, phoenix doesn't seem to reestablish the long polling connection. That would explain everything (except for it stopping completely, which is still an outstanding issue).

Unlike what I mentioned previously, even without LP the hang still happens. Looking a bit closer at the code it seems to me that the getWork request that WorkQueue performs when the miner is found to be idle fails silently and is not retried, so phoenix sits waiting for something to happen but with no action deferred.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: drgr33n on May 25, 2011, 11:02:13 AM
I don't seem to have a problem ?

LinuxCoin 0.2a
AMD-SDK 2.4
fglrx 11.4

1 x 5870 @ 998/300
1 x 5830 @ 998/300

Phoenix has been ticking along for days now. I do get the odd queue is idle but its due to my sketchy mobile broadband. With the phatk kernel I'm getting around 425MHs on my 5870 and 300MHs from my 5830.

Great work !!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: commlinx on May 25, 2011, 11:36:20 AM
That seems to be it. If the network connection is interrupted, phoenix doesn't seem to reestablish the long polling connection. That would explain everything (except for it stopping completely, which is still an outstanding issue).

Unlike what I mentioned previously, even without LP the hang still happens. Looking a bit closer at the code it seems to me that the getWork request that WorkQueue performs when the miner is found to be idle fails silently and is not retried, so phoenix sits waiting for something to happen but with no action deferred.
I've only had it happen once, but wanted to +1 that because it happened to me on slush's pool that doesn't support LP a few days ago when he had some problems. One instance was going fine, but other was idle. I run under Win7 64-bit with SDK 2.4. My Internet is normally pretty reliable which might explain why I only had a problem after the pool being down a while.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: perryh on May 25, 2011, 11:52:42 AM
I got phoenix to work for a short while, but now it no longer shows my video card in the device list.

aticonfig and flgrxinfo both display my card

dsasda@dsay-home:~/phoenix/phoenix-1.48$ ./phoenix.py -u http://dsadssad:blah@btcguild.com:8332/ DEVICE=1 BFI_INT VECTORS AGGRESSION=12 -k phatk WORKSIZE=12
No device specified or device not found, use DEVICE=ID to specify one of the following

    
  • Intel(R) Core(TM)2 Extreme CPU Q6800  @ 2.93GHz
[0 Khash/sec] [0 Accepted] [0 Rejected]perryh@perry-home:~/phoenix/phoenix-1.48$

any ideas?

thanks

edit: fixed. just defined $DEVICE


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: disq on May 26, 2011, 05:32:10 PM
BTW, increasing queue size cant help those ppl having "miner is idle"? i think it worth a try.

I think this should do the hash/s log(export) thing.

I gona try it once i figured out how to compile something in Python hahaha.

Here is shivansps's logtotext modification, working diff (against phoenix 1.47, should not change anything with .48 tho)

Edit: If running on a flash drive, you should use /tmp for destination. Like so: "./phoenix.py PARAMS -t /tmp/my-awesome-ati-9990.txt"

Code:
diff -ur phoenix-1.47/ConsoleLogger.py phoenix-1.47-modified/ConsoleLogger.py
--- phoenix-1.47/ConsoleLogger.py 2011-05-13 06:43:53.000000000 +0300
+++ phoenix-1.47-modified/ConsoleLogger.py 2011-05-26 20:27:40.000000000 +0300
@@ -47,9 +47,10 @@
    
     UPDATE_TIME = 1.0
    
-    def __init__(self, verbose=False):
+    def __init__(self, verbose=False, logtotext=None):
         self.verbose = verbose
         self.lastUpdate = time() - 1
+        self.logtotext = logtotext
         self.rate = 0
         self.accepted = 0
         self.invalid = 0
@@ -119,6 +120,10 @@
                 "[" + str(self.accepted) + " Accepted] "
                 "[" + str(self.invalid) + " Rejected]" + type)
             self.say(status)
+            if(self.logtotext != None):
+                fileHandle = open (self.logtotext, 'w')
+                fileHandle.write(datetime.now().strftime(self.TIME_FORMAT) + ' ' + status)
+                fileHandle.close()
             self.lastUpdate = time()
        
     def say(self, message, newLine=False, hideTimestamp=False):
Binary files phoenix-1.47/ConsoleLogger.pyc and phoenix-1.47-modified/ConsoleLogger.pyc differ
Binary files phoenix-1.47/kernels/poclbm/167c418e01275326142dd6e832cab098.elf and phoenix-1.47-modified/kernels/poclbm/167c418e01275326142dd6e832cab098.elf differ
diff -ur phoenix-1.47/phoenix.py phoenix-1.47-modified/phoenix.py
--- phoenix-1.47/phoenix.py 2011-05-13 06:43:53.000000000 +0300
+++ phoenix-1.47-modified/phoenix.py 2011-05-26 20:26:39.000000000 +0300
@@ -44,6 +44,7 @@
         self.connection = None
         self.kernel = None
         self.queue = None
+        self.logtotext = None
        
         self.kernelOptions = {}
        
@@ -62,6 +63,7 @@
         parser.add_option("-a", "--avgsamples", dest="avgsamples", type="int",
             default=10,
             help="how many samples to use for hashrate average")
+        parser.add_option("-t", "--logtotext", dest="logtotext", default=None, help="Log to text")
        
         self.parsedSettings, args = parser.parse_args()
        
@@ -88,7 +90,7 @@
    
     def makeLogger(self, requester):
         if not self.logger:
-            self.logger = ConsoleLogger(self.parsedSettings.verbose)
+            self.logger = ConsoleLogger(self.parsedSettings.verbose, self.parsedSettings.logtotext)
         return self.logger
    
     def makeConnection(self, requester):


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jimraynor on May 26, 2011, 08:40:57 PM
whenever i try to run phoenix miner it just closes its self a split second after i run it, what am i doing wrong?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bobR on May 26, 2011, 08:43:35 PM
whenever i try to run phoenix miner it just closes its self a split second after i run it, what am i doing wrong?

With out some details I'd say mining


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jimraynor on May 26, 2011, 08:44:37 PM
definatly not mining


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bobR on May 26, 2011, 08:49:07 PM
definatly not mining

or learning ...
if you cant say exactly what you did that did not work
how can anyone help you

smart ass reply's  just make you look like an ass
and you just lost my help
have a good life


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jimraynor on May 26, 2011, 08:52:44 PM
i did not make a smart ass reply

i didnt exactly know what you ment but i thought you ment i might of been mining with other software so i said i definately wasnt

i just extracted the zip and ran phoenix.exe and a cmd window pops up then instantly closes


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: twmz on May 26, 2011, 09:00:06 PM
i just extracted the zip and ran phoenix.exe and a cmd window pops up then instantly closes

phoenix.exe can't be double clicked on.  It has required command line parameters.

Open a cmd window manually, change the the folder with phoenix.exe and run it from there with the required command line parameters.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bobR on May 26, 2011, 09:05:43 PM
i did not make a smart ass reply

i didnt exactly know what you ment but i thought you ment i might of been mining with other software so i said i definately wasnt

i just extracted the zip and ran phoenix.exe and a cmd window pops up then instantly closes

"C:\Program Files\Bitcoin\phoenix-1.48\phoenix.exe" -u http://Yourusername.worker:yourpassword@mining.bitcoin.cz:8332/;askrate=20 -v -q 1 -a 25 -k poclbm platform=0 DEVICE=0 AGGRESSION=7 FASTLOOP BFI_INT



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jimraynor on May 26, 2011, 09:15:59 PM
thanks, so do i need to put the phoenix files in C:\Program Files\Bitcoin\phoenix-1.48 for that to work?


EDIT: i just get "'C:Program' is not reconized as an internal or external command, operable program or batch file.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bobR on May 26, 2011, 09:22:07 PM
thanks, so do i need to put the phoenix files in C:\Program Files\Bitcoin\phoenix-1.48 for that to work?


or change where it actually is

Do you need computer lessons ?>?>?
HOW THINGS work


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jimraynor on May 26, 2011, 09:23:42 PM
i thought it might have to be in the bitcoin directory to work


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: catch on May 26, 2011, 11:00:50 PM
I just upgraded to a Sapphire Radeon 5830 a couple days ago and downloaded SDK 2.1 and the Catalyst driver package, I tried to run phoenix but the cmd window would blip and disappear. I was able to take a screenshot and I'm getting "ImportError: MemoryLoadLibrary failed failed loading pyopencl\_cl.pyd" I tried uninstalling and reinstalling the drivers, but it's still not working. Before, I was running a nividia GTS 250 with no problems.

This may be an easy fix, but I'm just feeling frustrated right now. I would appreciate any help!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Aqualung on May 27, 2011, 06:50:18 AM
i started to use Sapphire 5830 with phoenix 1.48 a week ago and have no problems
i've downloaded only Catalyst Software Suite   56.7 MB   11.5   5/9/2011 from http://www.amd.com/ru/Pages/AMDHomePage.aspx (http://www.amd.com/us/Pages/AMDHomePage.aspx) - works fine
ps... thanks to author for great miner! :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Kick on May 27, 2011, 07:07:37 AM
I just upgraded to a Sapphire Radeon 5830 a couple days ago and downloaded SDK 2.1 and the Catalyst driver package, I tried to run phoenix but the cmd window would blip and disappear. I was able to take a screenshot and I'm getting "ImportError: MemoryLoadLibrary failed failed loading pyopencl\_cl.pyd" I tried uninstalling and reinstalling the drivers, but it's still not working. Before, I was running a nividia GTS 250 with no problems.

This may be an easy fix, but I'm just feeling frustrated right now. I would appreciate any help!


look a few posts above you man.

http://forum.bitcoin.org/index.php?topic=6458.msg144610#msg144610


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: catch on May 27, 2011, 07:47:17 PM
i started to use Sapphire 5830 with phoenix 1.48 a week ago and have no problems
i've downloaded only Catalyst Software Suite   56.7 MB   11.5   5/9/2011 from http://www.amd.com/ru/Pages/AMDHomePage.aspx (http://www.amd.com/us/Pages/AMDHomePage.aspx) - works fine
ps... thanks to author for great miner! :)

Did you have to run anything after it installed? Are you using Windows 7 32 bit? I'm running 64 bit and the only other thing I can think of is just doing a fresh install of Windows 7.


Title: Phoenix on CPU
Post by: cande on May 28, 2011, 01:25:37 AM
Hey,

i'm trying to run Phoenix on my CPU, which gives me:
Code:
FATAL kernel error: Failed to load OpenCL kernel!

is there a reason to this? is it not designed to run on CPUs? poclbm runs without any hassle on the CPU


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BOARBEAR on May 28, 2011, 02:31:38 AM
Phoenix does not work with intel opencl platform, is there any plan to support it in the future?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: disq on May 28, 2011, 12:07:21 PM
Here is the logtotext patch for the 1.48: https://github.com/disq/bitcoin-rug-monitor/blob/master/logtotext-1.48.diff


Title: Re: Phoenix on CPU
Post by: m4rkiz on May 28, 2011, 11:04:56 PM
i'm trying to run Phoenix on my CPU, which gives me:
Code:
FATAL kernel error: Failed to load OpenCL kernel!
is there a reason to this? is it not designed to run on CPUs? poclbm runs without any hassle on the CPU

cpu days are over, today you can get ~4.5 BTC with 2200 MH/s (my last 24h on deepbit with 7 gpus)

Core i7 920 will give you no more than 0.045 per 24h (and there is 2-3kWh that you need to pay for, which means that you are loosing money)
with mainstream Pentium E5400 it is around 0.0045 per 24h... you would cover a week of calculation simply by going to faucet ;)



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: super6 on May 29, 2011, 05:24:00 AM
Is there a performance difference between phoenix for Linux and Win7? Is any distro better than another? I've got a 3x6990 system coming that I want to use as a dedicated miner so I want the most efficient setup possible. If there's no performance difference I'll probably go with Win7 because I'm more familiar with it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Firerouge on May 29, 2011, 10:24:16 AM
Love it so much.

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=128 AGGRESSION=12 on a single 5870 950/330 I get a nice 410 Mhas/sec.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: winnetou on May 29, 2011, 12:40:17 PM
i did not make a smart ass reply

i didnt exactly know what you ment but i thought you ment i might of been mining with other software so i said i definately wasnt

i just extracted the zip and ran phoenix.exe and a cmd window pops up then instantly closes

you have to run it from the command line / cmd.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tiberiandusk on May 29, 2011, 01:28:04 PM
i did not make a smart ass reply

i didnt exactly know what you ment but i thought you ment i might of been mining with other software so i said i definately wasnt

i just extracted the zip and ran phoenix.exe and a cmd window pops up then instantly closes

you have to run it from the command line / cmd.

Here is what I do:

Figure out what pool address and flags you want to use.

Make a txt file in the Phoenix folder with the exe and put your flags etc into it. Save and close the txt file.

Change the .txt extension to .bat and run the bat file.

Profit.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: icaci on May 29, 2011, 05:39:38 PM
Love it so much.

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=128 AGGRESSION=12 on a single 5870 950/330 I get a nice 410 Mhas/sec.
phatk works best with WORKSIZE=256. Getting 413 Mhash/s on both 5870 935/319 in a dual-card mining rig (w/o CrossFireX bridges).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Firerouge on May 29, 2011, 08:00:09 PM
Love it so much.

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=128 AGGRESSION=12 on a single 5870 950/330 I get a nice 410 Mhas/sec.
phatk works best with WORKSIZE=256. Getting 413 Mhash/s on both 5870 935/319 in a dual-card mining rig (w/o CrossFireX bridges).

Wow thank you. You pushed me up to a nice 417.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: keybaud on May 29, 2011, 08:29:43 PM
Love it so much.

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=128 AGGRESSION=12 on a single 5870 950/330 I get a nice 410 Mhas/sec.
phatk works best with WORKSIZE=256. Getting 413 Mhash/s on both 5870 935/319 in a dual-card mining rig (w/o CrossFireX bridges).

Isn't 256 the max for a 5870, so the default value Phoenix uses anyway?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: martok on May 29, 2011, 10:51:41 PM
Hello,
Is there any way to include special characters in the http username string. In poclbm --user "x;y" works but "http://x;y@hostname/" does not. I also tried "http://x%3by@hostname/" but no luck there either.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on May 29, 2011, 11:45:27 PM
whenever i try to run phoenix miner it just closes its self a split second after i run it, what am i doing wrong?

Open a command window and execute phoenix from a command line and you will see the error it is giving you.

Here is what I use for my workstation that must be responsive (remove FASTLOOP and boost aggression to 11 or 12 for a dedicated machine):

Quote
@ECHO OFF

SET DRIVE=D:
SET WORKINGDIR=D:\Bitcoin\phoenix
SET PHOENIX=phoenix.exe
SET USERNAME=xxxxxx
SET PASSWORD=xxxxxxx
SET SITE=btcmine.com
REM SET USERNAME=xxxxxx
REM SET PASSWORD=xxxxxx
REM SET SITE=pit.deepbit.net
SET PORT=8332
SET OPTIONS=-k poclbm DEVICE=0 VECTORS BFI_INT FASTLOOP WORKSIZE=128 AGGRESSION=9

%DRIVE%
CD %WORKINGDIR%
start %PHOENIX% -u http://%USERNAME%:%PASSWORD%@%SITE%:%PORT%/ %OPTIONS%

Note that I leave pools that I use commented out so that I can change from one to the other if I want too [for testing or because one is down, or whatever reason].  I should probably pass an argument to "start" so that the original command window doesn't popup, but it doesn't bother me enough to change it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: icaci on May 30, 2011, 05:43:15 AM
(remove FASTLOOP and boost aggression to 11 or 12 for a dedicated machine)
FASTLOOP is enabled by default in recent Phoenix versions and one must specify FASTLOOP=false in order to disable it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slowmining on May 30, 2011, 06:11:11 AM
[719 Accepted] [56 Rejected]

Is this normal?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: PoulGrym on May 30, 2011, 09:00:13 AM
Just tried to connect to deepbit.net and tada..

Code:
[30/05/2011 10:55:10] Connected to server
[348.31 Mhash/sec] [0 Accepted] [0 Rejected] [RPC (+LP)]Unhandled Error
Traceback (most recent call last):
  File "twisted\internet\tcp.pyc", line 529, in connectionLost

  File "minerutil\_newclient3420.pyc", line 826, in dispatcher

  File "minerutil\_newclient3420.pyc", line 1434, in _connectionLost_WAITING

  File "minerutil\_newclient3420.pyc", line 1363, in _disconnectParser

--- <exception caught here> ---
  File "minerutil\_newclient3420.pyc", line 494, in connectionLost

  File "twisted\web\http.pyc", line 1366, in noMoreData

  File "minerutil\_newclient3420.pyc", line 409, in _finished

  File "minerutil\_newclient3420.pyc", line 1337, in _finishResponse

exceptions.AttributeError: 'NoneType' object has no attribute 'connHeaders'

It got right back to track just a second after the error..


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: error on May 30, 2011, 09:24:09 AM
I just found a bug in the long polling code.

It seems that LP fails to work properly if the long polling URL uses a query string (e.g. http://localhost:8332/example?longpoll=example).

Here is the fix:

Code:
--- minerutil/RPCProtocol.py.orig       2011-05-18 04:48:47.000000000 -0400
+++ minerutil/RPCProtocol.py    2011-05-30 05:20:05.812351055 -0400
@@ -349,11 +349,12 @@
         if longpoll:
             lpParsed = urlparse.urlparse(longpoll[0])
             urlParsed = urlparse.urlparse(self.url)
-            lpURL = '%s://%s:%d%s' % (
+            lpURL = '%s://%s:%d%s%s' % (
                 lpParsed.scheme or urlParsed.scheme,
                 lpParsed.hostname or urlParsed.hostname,
                 (lpParsed.port if lpParsed.hostname else urlParsed.port) or 80,
-                lpParsed.path)
+                lpParsed.path,
+               '?' + lpParsed.query if lpParsed.query else '')
             if self.longPoller and self.longPoller.url != lpURL:
                 self.longPoller.stop()
                 self.longPoller = None


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: MiningBuddy on May 30, 2011, 10:00:35 AM
Is there any way to further enhance the reconnecting of phoenix to a pool?
I saw improvements in version 1.48, but if the pool is down for several minutes it seems to never reconnect.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: melco on May 30, 2011, 02:17:22 PM
Mine too. Never gets reconnected after pool network failures.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bitminer on May 30, 2011, 02:32:52 PM
After few hours of mining on deepbit I get usually the following error msg:

Code:
[308.36 Mhash/sec] [1857 Accepted] [29 Rejected] [RPC (+LP)]Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 519, in connectionLost
    protocol.connectionLost(reason)
  File "/phoenix/minerutil/_newclient3420.py", line 826, in dispatcher
    return func(*args, **kwargs)
  File "/phoenix/minerutil/_newclient3420.py", line 1434, in _connectionLost_WAITING
    self._disconnectParser(reason)
  File "/phoenix/minerutil/_newclient3420.py", line 1363, in _disconnectParser
    parser.connectionLost(reason)
--- <exception caught here> ---
  File "/phoenix/minerutil/_newclient3420.py", line 494, in connectionLost
    self.bodyDecoder.noMoreData()
  File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1388, in noMoreData
    finishCallback('')
  File "/phoenix/minerutil/_newclient3420.py", line 409, in _finished
    self.finisher(rest)
  File "/phoenix/minerutil/_newclient3420.py", line 1337, in _finishResponse
    connection = self._parser.connHeaders.getRawHeaders('Connection')
exceptions.AttributeError: 'NoneType' object has no attribute 'connHeaders'                                                                                                      [30/05/2011 15:30:54] Warning: work queue empty, miner is idle
[0 Khash/sec] [1857 Accepted] [29 Rejected] [RPC (+LP)]


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Azelphur on May 30, 2011, 03:37:51 PM
I get this one every now and again, usually at about 4am in the morning knowing my luck :D

Code:
  File "/opt/bitcoin/miners/phoenix-1.48/phoenix.py", line 125, in <module>
    reactor.run()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1158, in run
    self.mainLoop()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1167, in mainLoop
    self.runUntilCurrent()
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 789, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/nfsroot/opt/bitcoin/miners/phoenix-1.48/minerutil/RPCProtocol.py", line 127, in callback
    self.root.handleWork(result)
  File "/nfsroot/opt/bitcoin/miners/phoenix-1.48/minerutil/RPCProtocol.py", line 319, in handleWork
    if 'block' in work:
exceptions.TypeError: argument of type 'NoneType' is not iterable


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on May 30, 2011, 06:39:25 PM
I just saw the error for the first time this morning.  I am very hesitant to change miners since my dedicated machine is now very finely tuned and when I have tried to use GUI Miner I have managed to topple the machine.  I have seen the connection problem referred to above only once.  For me, Phoenix usually recovers even after 10 minutes or so [I had my router down for a bit the other night and all miners resumed when full Internet access was restored.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: martok on May 30, 2011, 09:51:56 PM
Hello,
Is there any way to include special characters in the http username string. In poclbm --user "x;y" works but "http://x;y@hostname/" does not. I also tried "http://x%3by@hostname/" but no luck there either.

Hi again,

After some stracing, I found the bug. It isn't with special chars but rather with long usernames in the URL. phoenix is base64 encoding using some encode function but that function is dropping a newline (\n) character into the base64 stream. That needs to come out else we are sending invalid HTTP headers.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: minerX on May 30, 2011, 11:59:52 PM
Just tried to connect to deepbit.net and tada..

Code:
[30/05/2011 10:55:10] Connected to server
[348.31 Mhash/sec] [0 Accepted] [0 Rejected] [RPC (+LP)]Unhandled Error
Traceback (most recent call last):
  File "twisted\internet\tcp.pyc", line 529, in connectionLost

  File "minerutil\_newclient3420.pyc", line 826, in dispatcher

  File "minerutil\_newclient3420.pyc", line 1434, in _connectionLost_WAITING

  File "minerutil\_newclient3420.pyc", line 1363, in _disconnectParser

--- <exception caught here> ---
  File "minerutil\_newclient3420.pyc", line 494, in connectionLost

  File "twisted\web\http.pyc", line 1366, in noMoreData

  File "minerutil\_newclient3420.pyc", line 409, in _finished

  File "minerutil\_newclient3420.pyc", line 1337, in _finishResponse

exceptions.AttributeError: 'NoneType' object has no attribute 'connHeaders'

It got right back to track just a second after the error..

I got that error too.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kynalvarus on May 31, 2011, 12:27:06 AM
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)

This would work great on Linux. I could even make most of it work on my Windows miner using Cygwin. However, I don't have an equivalent to aticonfig on Windows. Anyone know a good way of getting GPU load into Python (or any scripting language) on Windows/Cygwin?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: tehc0w on May 31, 2011, 03:12:30 AM
I'm mining with a GTS 250 and I get about 28-29m on poclbm but when I use phoenix, I can't get above 23m.  Has anyone else experienced this?  Is phoenix just less efficient with Nvidia cards?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on May 31, 2011, 11:45:02 AM
Just tried to connect to deepbit.net and tada..

Code:
[30/05/2011 10:55:10] Connected to server
[348.31 Mhash/sec] [0 Accepted] [0 Rejected] [RPC (+LP)]Unhandled Error
Traceback (most recent call last):
  File "twisted\internet\tcp.pyc", line 529, in connectionLost

  File "minerutil\_newclient3420.pyc", line 826, in dispatcher

  File "minerutil\_newclient3420.pyc", line 1434, in _connectionLost_WAITING

  File "minerutil\_newclient3420.pyc", line 1363, in _disconnectParser

--- <exception caught here> ---
  File "minerutil\_newclient3420.pyc", line 494, in connectionLost

  File "twisted\web\http.pyc", line 1366, in noMoreData

  File "minerutil\_newclient3420.pyc", line 409, in _finished

  File "minerutil\_newclient3420.pyc", line 1337, in _finishResponse

exceptions.AttributeError: 'NoneType' object has no attribute 'connHeaders'

It got right back to track just a second after the error..

I got that error too.

This is triggered by something that a few of the pools have done [at least deepbit and BTCMine].  I am sick of waking up to finding that hours have gone by with my miners down [and my GPU sitting at 40%].  I am hooked up to BTC Guild right now and maybe I will have more luck.  However, if this happens again, I am going to have to tweak my machines for pclbm and never look back [too much effort already tweaking machines to run optimally and stably].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: radracer on May 31, 2011, 01:02:13 PM
i am now getting these errors every time i try to run phoenix.  any idea what this means?

Code:
Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
  File "Miner.pyc", line 75, in start
  File "phoenix.py", line 111, in makeKernel
  File "kernels\poclbm\__init__.py", line 22, in <module>
    import pyopencl as cl
  File "zipextimporter.pyc", line 82, in load_module
  File "pyopencl\__init__.pyc", line 3, in <module>
  File "zipextimporter.pyc", line 98, in load_module
ImportError: MemoryLoadLibrary failed loading pyopencl\_cl.pyd


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on May 31, 2011, 07:48:28 PM
phoenix is not able to reconnect properly most of the time, right now im using my own programs to monitor it and restart it if the connection is down, and i even implemented a pool switch method too in case if the pool has been down for some time, the nly problem? i need to have thee stats on a plain text file, right now thats a nightmare, the file gets well over 3gb in size after just 24 hours, i need to try to do that phoenix mod ive attemped few days ago to export only stats to a .txt file again.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 01, 2011, 03:17:38 AM
I started using the latest command line version of poclbm on Windows 7 x64 and I am getting about the same performance, but it is known to reconnect more reliably [although when I used it with GUIMiner, it didn't always reconnect using the version from late March when I tested it and had the issue] and I am getting FAR fewer stale shares than with phoenix.  I have command scripts to allow me to switch miners and pools at will.  I was seeing 1.0 - 1.5% rejected shares with phoenix (more when there were pool problems) while I am seeing about 0.5% using poclbm with a relatively small share sample (about 1200 so far).  I am pretty sure it is the long polling code in phoenix that is causing the additional stale shares and it is certainly causing the recent crashes [why did that suddenly start in the last few days and not before ... I was using 1.48 since it was released but only saw the LP crash for the first time this morning on both machines at the same time (about 2:30AM CDT with deepbit.net).

I like the way phoenix is configured better and I like the command line output that shows the cumulative accepted/rejected counts better, so I really would prefer to use phoenix, but unfortunately, I cannot do so right now.  

Any word on when a new version is out that has been tested with multiple pools long polling?  I would love to test, but with only two machines [one GPU each], I can't afford to have a miner drop while I am away or sleeping [I work from home a lot, so I can test then easily enough ... I am not sure that up to a 16 hour run is sufficient though].

When phoenix comes around, I will be back with it :)  Just curious about any progress.  

Thank you.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: inlikeflynn on June 01, 2011, 04:56:55 AM
Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 ;D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: grm203 on June 01, 2011, 06:10:40 AM
I am getting 245 rejected shares with 4140 shares, from a HD5870 . I am wondering is it normal to have such high stale shares? EDIT: i am with btcmine pool


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: luffy on June 01, 2011, 06:31:01 AM
Veldy and all the other co-miners,
i agree that phoenix has this sirious connection problem now and then. and i want also to go to poclbm (just for now)
but my problem is how to get phatk kernel to work without phoenix?
phatk is faster than poclbm and not just by 1-2MH (for example from 300 goes to 310 with 5850 and from 360 goes to 380 with 5870)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 01, 2011, 12:58:39 PM
Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 ;D

I have always found phatk to be slower.  Why did you choose to use it?  Also, why WORKSIZE=256?  I have also found 128 to be faster on the 58xx and 69xx series.

I am using poclbm at the moment getting 0.2% stale rate [not using BTCMine at the moment though].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dikidera on June 01, 2011, 02:00:26 PM
Is this a bug i experienced?

When using these arguments

Quote
-k phatk DEVICE=0 VECTORS BFI_INT WORKSIZE=128 AGGRESSION=6 FASTLOOP=false
Specifically aggression 6 i see some weird hopping between 293.60 Mhash/s to 314 Mhash/s. When i put it back to aggression 9 it works ok at 290Mhash/s

Is this a bug?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 01, 2011, 04:01:45 PM
Veldy and all the other co-miners,
i agree that phoenix has this sirious connection problem now and then. and i want also to go to poclbm (just for now)
but my problem is how to get phatk kernel to work without phoenix?
phatk is faster than poclbm and not just by 1-2MH (for example from 300 goes to 310 with 5850 and from 360 goes to 380 with 5870)

I didn't get those results.  I see significantly slower results from phatk on my 6970 [I haven't tried on my 5850 ... but I am using poclbm to mine with now and not phoenix, so I won't be testing until an improved version of Phoenix is available].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: btcLeger on June 01, 2011, 05:33:04 PM
I am getting 245 rejected shares with 4140 shares, from a HD5870 . I am wondering is it normal to have such high stale shares? EDIT: i am with btcmine pool

I also had >7% stale shares today at btcmine. That was during the block with 2446260 round shares this morning. Usally I have < 3% at btcmine with my 0.5Ghash. Mostly btcmine works very well for me but I will try another pool for a couple of days I guess....


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: inlikeflynn on June 01, 2011, 06:13:03 PM
Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 ;D

I have always found phatk to be slower.  Why did you choose to use it?  Also, why WORKSIZE=256?  I have also found 128 to be faster on the 58xx and 69xx series.

I am using poclbm at the moment getting 0.2% stale rate [not using BTCMine at the moment though].

I chose to use phatk because I saw some other posts recomend using it on 5830/5850 cards and it is faster for me by 9-10MH/sec. WORKSIZE=256 with phatk also is faster for me (by another ~4MH/sec)

Here are some results from my testing:
297MH/sec = pocldm & WORKSIZE=128
304MH/sec = pocldm & WORKSIZE=256
308MH/sec = phatk & WORKSIZE=128
312MH/sec = phatk & WORKSIZE=256

I am getting quite a few rejected blocks though, so i'm not sure if that has anything to-do with the above settings or something else.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 01, 2011, 06:27:46 PM
I am getting 245 rejected shares with 4140 shares, from a HD5870 . I am wondering is it normal to have such high stale shares? EDIT: i am with btcmine pool

I also had >7% stale shares today at btcmine. That was during the block with 2446260 round shares this morning. Usally I have < 3% at btcmine with my 0.5Ghash. Mostly btcmine works very well for me but I will try another pool for a couple of days I guess....

I was seeing such high stale rates myself for awhile with them (although, for me anything greater than ~1% is exceedingly bad ... at one time, I never saw anything above 0.4% ... but that was back in late April or even early May), so I took a break until they moved BTCMine to a new server. Having said that, I have found that poclbm miner (not phoenix with the poclbm kernel) does a much better job with stale shares, so clearly it has better long polling code.  I was getting about 0.2% stale all evening last night until about midnight CDT, but by about 8AM CDT, it had risen to 0.9%. I am sure that phoenix will get it worked out before long, but frankly, it better be close to or better than poclbm at this point [I like phoenix better overall].  I have solid scripts for both that allow me to quickly switch miners and/or pools at a few moments notice.

In the mean time, I have found BTC Guild to be quite intriguing.  The guy who built it is very enthusiastic [not so different than Tycho when he started deepbit.net] and his pool has grown in a very short period of time to exceed hash rate of BTCMine.  BTC Guild is running ~500GH/s now (I contribute 0.71GH/s on average right now and hope to bring that up to 1.02GH/s by tonight or tomorrow night ... I didn't buy new mining hardware, just updated some existing hardware I had in storage, but found my board wasn't compatible with the CPU I have, so it should arrive today ... only a $50 investment ... could have made that in earnings while waiting if my CPU had been compatible).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 01, 2011, 06:41:40 PM
Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 ;D

I have always found phatk to be slower.  Why did you choose to use it?  Also, why WORKSIZE=256?  I have also found 128 to be faster on the 58xx and 69xx series.

I am using poclbm at the moment getting 0.2% stale rate [not using BTCMine at the moment though].

I chose to use phatk because I saw some other posts recomend using it on 5830/5850 cards and it is faster for me by 9-10MH/sec. WORKSIZE=256 with phatk also is faster for me (by another ~4MH/sec)

Here are some results from my testing:
297MH/sec = pocldm & WORKSIZE=128
304MH/sec = pocldm & WORKSIZE=256
308MH/sec = phatk & WORKSIZE=128
312MH/sec = phatk & WORKSIZE=256

I am getting quite a few rejected blocks though, so i'm not sure if that has anything to-do with the above settings or something else.

Rejects are higher now with the incredible pool hash rates.  The answer is probably a new protocol to replace RPC+LP, but your rejected shares could be from your card faulting on calculations and giving you invalid hash results as well. 

I will have to play with 256 worksize on my cards again.  I never tried anything but 128 on my 5850, but when I tried 256 on my 6970, I had a noticeable decline in hash rate reported by the miner.  I will try that again too :)

EDIT:  I just tested 256 worksize with my 6970 and rate dropped from 393MH/s to 323MH/s.  I find it hard to believe that the 5850 would be better suited to 256 than the 6970, but perhaps so.  I don't have time to test on my other box with the 5850 at the moment.   BTW ... I get 319MH/s with my 5850 now ... stock with using 128 (pushed core speed to 850MHz and reduced memory speed slightly to 900MHz).  Identical with both poclbm and phoenix [using poclbm kernel].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Obrzin on June 02, 2011, 03:27:00 AM
There seems to be a memory leak somewhere (maybe not technically a 'memory leak' since you are using Python but), phoenix uses several hundred megabytes of ram after several days of running.  My guess is a failure to prune some sort of list of completed shares / console output / something.  I would simply quit and restart, but I've run into the previously mentioned bug where my normally stable system would completely freeze upon exiting phoenix.  This one I can't seem to reliably reproduce, it happens sometimes upon exiting but most of the time it's fine.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jarekb on June 02, 2011, 02:09:17 PM
I've been having problems getting any gpu miner to work consistently with my 4870x2, so I'm cross posting my tech support post here since most of my tries have been with Phoenix.
http://forum.bitcoin.org/index.php?PHPSESSID=86cf6d7c91ca2a7bcd1c8b73edade733&topic=11312.0

Basically I get a lot of "Kernel error: Unusual behavior from OpenCL. Hardware problem?" errors along with a high rate of rejected shares. Catalyst A.I. is disabled and I've tried both poclbm and phatk kernels. Can anyone take a look at the above post to see if they can help me?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on June 02, 2011, 02:26:53 PM
idle bug

if it is not possible to restart phoenix by itself whenever the miner becomes idle maybe it is possible to simply have it exit whenever that state occurs. It should be easy to restart it from a batch file as soon as it exits...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mops on June 02, 2011, 03:40:40 PM
hello, i am new here.
i am having a wierd problem:
http://img585.imageshack.us/img585/6713/problemaphoenix.jpg (http://imageshack.us/photo/my-images/585/problemaphoenix.jpg/)
after a while my gpu will simply stop producing mhash. i have 2 computers, on one computer i got no problems ( 2*5850) , on the other one is the one taht i am having this issue i have a single 5850. it happens after 5-45 mins aprox.

oc does not seem to be the probleem
nor internet
nor the pool (have tried in btc/slush and it happens in both)
to momentarily fix it i have to close it and open up again, it will run fine till i get the same problem
i use the following bat: DEVICE=0 BFI_INT VECTORS askrate=12 FASTLOOP=false AGGRESSION=11 -k phatk


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shackleford on June 02, 2011, 07:43:56 PM
There seems to be a memory leak somewhere (maybe not technically a 'memory leak' since you are using Python but), phoenix uses several hundred megabytes of ram after several days of running.  My guess is a failure to prune some sort of list of completed shares / console output / something.  I would simply quit and restart, but I've run into the previously mentioned bug where my normally stable system would completely freeze upon exiting phoenix.  This one I can't seem to reliably reproduce, it happens sometimes upon exiting but most of the time it's fine.

I have had that lockup issue for a long time and I think I just found a way arround it. I am guessing your using Ati11.4/.5? If so try 11.3. Have two machines that were having this issue with 11.4 and it has cleared up with 11.3. That bug is realy bad on a non dedicated miner..(other stuff has gotten corrupt for me because of lockups from loosing the app close russian rullett)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nyargh on June 02, 2011, 07:58:03 PM
Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 ;D

What driver / os / sdk?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mops on June 02, 2011, 08:03:24 PM
Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 ;D

What driver / os / sdk?


w7 ultimate 64bits
catalyst 11.5
sdk 2.2

it used to work fie ( 3 days ). then i started having these problem, i have a pc next to me with same softs and bat and it works just fine

to momentarily fix it i have to close it and open up again, it will run fine till i get the same problem (5-45mins)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 02, 2011, 09:02:31 PM
Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 ;D

What driver / os / sdk?


w7 ultimate 64bits
catalyst 11.5
sdk 2.2

it used to work fie ( 3 days ). then i started having these problem, i have a pc next to me with same softs and bat and it works just fine

to momentarily fix it i have to close it and open up again, it will run fine till i get the same problem (5-45mins)

Catalyst 11.5 comes with stream, so do not install it separately.  Uninstall both.  Reboot.  Clean out ATI/AMD directories as applicable and then install the 11.5 drivers only.

I assume that your card is not over heating, the system and card is getting enough power [good PSU with enough steady power] and that you aren't overclocking it [or underclocking it ... like the memory clock] and you haven't touched any voltages?  You have been watching the temperature?  Proper ventilation in your case (you have good air flow).  If you can't answer these questions ... install MSI Afterburner for some help :)



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mops on June 03, 2011, 01:37:52 AM
Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 ;D

What driver / os / sdk?


w7 ultimate 64bits
catalyst 11.5
sdk 2.2

it used to work fie ( 3 days ). then i started having these problem, i have a pc next to me with same softs and bat and it works just fine

to momentarily fix it i have to close it and open up again, it will run fine till i get the same problem (5-45mins)

Catalyst 11.5 comes with stream, so do not install it separately.  Uninstall both.  Reboot.  Clean out ATI/AMD directories as applicable and then install the 11.5 drivers only.

I assume that your card is not over heating, the system and card is getting enough power [good PSU with enough steady power] and that you aren't overclocking it [or underclocking it ... like the memory clock] and you haven't touched any voltages?  You have been watching the temperature?  Proper ventilation in your case (you have good air flow).  If you can't answer these questions ... install MSI Afterburner for some help :)


first of all thxs for a proper answer
second:

good temps dont go above 70º with oc. with or without oc i got this problem.
600w psu, satellite, its argentinian , dont think you klnow it but its good enough to have 2*5850.
i will un install and reboot and see what happens :D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 03, 2011, 01:53:00 AM
My personal opinion is that 600W PSU, even a good one, is not good enough for a machine with two 5850s in it.  The motherboard, CPU, fans and probably one hard drive will be running that PSU near max.  I would expect the thing to fail over time.  Also, a PSU does fluctuate with it's ability to deliver power, and you can usually see stamped on the side of a decent PSU what that minumum 100% is [for 600W PSU, perhaps 568W or something like that].  Your 5850 probably burns ~200W each, CPU, ~100W depending on the CPU (could be a low power 65W or 110W i3,i5,i7 or more).  Case fans and hard drives ... not sure precisely, but I would guess on an average PC, probably 50W or so.  Your PSU may not be delivering optimum power at all times anymore since you have been taxing it so hard.  Personally, I would put a 750W in there ... or more if you think you will upgrade the cards at some point to a real energy hog :).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mops on June 03, 2011, 01:59:33 AM
My personal opinion is that 600W PSU, even a good one, is not good enough for a machine with two 5850s in it.  The motherboard, CPU, fans and probably one hard drive will be running that PSU near max.  I would expect the thing to fail over time.  Also, a PSU does fluctuate with it's ability to deliver power, and you can usually see stamped on the side of a decent PSU what that minumum 100% is [for 600W PSU, perhaps 568W or something like that].  Your 5850 probably burns ~200W each, CPU, ~100W depending on the CPU (could be a low power 65W or 110W i3,i5,i7 or more).  Case fans and hard drives ... not sure precisely, but I would guess on an average PC, probably 50W or so.  Your PSU may not be delivering optimum power at all times anymore since you have been taxing it so hard.  Personally, I would put a 750W in there ... or more if you think you will upgrade the cards at some point to a real energy hog :).
i am only using one 5850 with the 600w psu, sorry for not being clear, have not speaked english in a while XD
ty for the advice though

for the rig that has 2*5850 i am using lianli 850w, (with this rig i am having no trouble at all )


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jarekb on June 03, 2011, 02:02:45 AM
I got my issues with the 4870x2 resolved by updating to catalyst 11.5, but now my cores aren't processing as fast. One is in the mid 80's other is in the mid 50's. Any idea why the cores are running at different rates?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mops on June 03, 2011, 04:48:01 AM
i think i will have to format c:/

i am not being able to solve de problem, tries reinstalind, using sdk 2.4, 2.2, and not using any. now i get this screen:

http://img705.imageshack.us/img705/2861/errorpp.jpg (http://imageshack.us/photo/my-images/705/errorpp.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: luffy on June 03, 2011, 04:55:01 AM
5850 will not exceed 150W with a mild oc (not above 800MHz). i had 2x5850 with a 500W PSU for a while, ofcourse my rig is a dedicated one with a single core Sempron, 1GB ram , one 2.5" disk, etc
before any format make sure you have uninstalled all the ATI drivers and sdk and install only the full catalyst 11.3 or 11.5 with _ocl.
nothing more, i think you will be ok ;)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mops on June 03, 2011, 12:33:47 PM
5850 will not exceed 150W with a mild oc (not above 800MHz). i had 2x5850 with a 500W PSU for a while, ofcourse my rig is a dedicated one with a single core Sempron, 1GB ram , one 2.5" disk, etc
before any format make sure you have uninstalled all the ATI drivers and sdk and install only the full catalyst 11.3 or 11.5 with _ocl.
nothing more, i think you will be ok ;)
reinstalled, in several ways
using the sdk from catalyst
using 2.2
using 2.4
using kernel 1.6
kernel1.8.

it seems i will have to format :S


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: klayus on June 03, 2011, 01:47:14 PM
i found that using phatk gives me 25MH/s more on a 5870 and 4 more on a 4850 than using poclbm. also using bigger worksize helps with mh/s - with poclbm mh/s 's dont change with worksize change but on phatk i can use 256 for a 10 percent increase. same with 4850.

hopes this helps

donate if you feel like it :)
1KRfmENZaRbS27ViorpNbaKZoyNiKtGrWh


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on June 03, 2011, 03:05:44 PM
5850 will not exceed 150W with a mild oc (not above 800MHz). i had 2x5850 with a 500W PSU for a while, ofcourse my rig is a dedicated one with a single core Sempron, 1GB ram , one 2.5" disk, etc
before any format make sure you have uninstalled all the ATI drivers and sdk and install only the full catalyst 11.3 or 11.5 with _ocl.
nothing more, i think you will be ok ;)
reinstalled, in several ways
using the sdk from catalyst
using 2.2
using 2.4
using kernel 1.6
kernel1.8.

it seems i will have to format :S

Use driver sweeper from http://phyxion.net/item/driver-sweeper.html & remove all the AMD drivers.
Also, after removing go to safe mode & run again. which will remove every instance of AMD driver.
Then install fresh one. Go for latest 11.5 & 2.4 & instead of express install, go for custom install & ONLY install these 3,
ATI display driver, ATI catalyst install manager, APP 2.4 & if needed vc++.
You will be able to mine with out formating.

Also, don't use askrate & worksize for now.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: krayzie32 on June 03, 2011, 05:18:57 PM
Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 ;D

I have always found phatk to be slower.  Why did you choose to use it?  Also, why WORKSIZE=256?  I have also found 128 to be faster on the 58xx and 69xx series.

I am using poclbm at the moment getting 0.2% stale rate [not using BTCMine at the moment though].

I have 7 different computers running 5830s and 256 gives about 5m more than 128.  I run mine at 975 clock, 300 memory and I get about 300MH/sec.

I love these 5830s only cost $100 but can push out 300MH/sec!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mops on June 04, 2011, 06:13:35 AM
5850 will not exceed 150W with a mild oc (not above 800MHz). i had 2x5850 with a 500W PSU for a while, ofcourse my rig is a dedicated one with a single core Sempron, 1GB ram , one 2.5" disk, etc
before any format make sure you have uninstalled all the ATI drivers and sdk and install only the full catalyst 11.3 or 11.5 with _ocl.
nothing more, i think you will be ok ;)
reinstalled, in several ways
using the sdk from catalyst
using 2.2
using 2.4
using kernel 1.6
kernel1.8.

it seems i will have to format :S

Use driver sweeper from http://phyxion.net/item/driver-sweeper.html & remove all the AMD drivers.
Also, after removing go to safe mode & run again. which will remove every instance of AMD driver.
Then install fresh one. Go for latest 11.5 & 2.4 & instead of express install, go for custom install & ONLY install these 3,
ATI display driver, ATI catalyst install manager, APP 2.4 & if needed vc++.
You will be able to mine with out formating.

Also, don't use askrate & worksize for now.


THANKS A LOT

had to uninstall using both the driver sweeper, and using the catalyst setup, then i installed 11.5 the way you said and now it seems to work :D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: 5tr1k3r on June 04, 2011, 01:29:32 PM
I'm sorry, which askrate is used by default? I have 5770 and would like to know if I should set it by myself.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: 5tr1k3r on June 04, 2011, 03:11:21 PM
Oh, actually, I found the answer on the second page.

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 use deepbit.net (RPC+LP), so it makes changing the askrate setting pointless, as I see.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on June 04, 2011, 05:26:22 PM
5850 will not exceed 150W with a mild oc (not above 800MHz). i had 2x5850 with a 500W PSU for a while, ofcourse my rig is a dedicated one with a single core Sempron, 1GB ram , one 2.5" disk, etc
before any format make sure you have uninstalled all the ATI drivers and sdk and install only the full catalyst 11.3 or 11.5 with _ocl.
nothing more, i think you will be ok ;)
reinstalled, in several ways
using the sdk from catalyst
using 2.2
using 2.4
using kernel 1.6
kernel1.8.

it seems i will have to format :S

Use driver sweeper from http://phyxion.net/item/driver-sweeper.html & remove all the AMD drivers.
Also, after removing go to safe mode & run again. which will remove every instance of AMD driver.
Then install fresh one. Go for latest 11.5 & 2.4 & instead of express install, go for custom install & ONLY install these 3,
ATI display driver, ATI catalyst install manager, APP 2.4 & if needed vc++.
You will be able to mine with out formating.

Also, don't use askrate & worksize for now.


THANKS A LOT

had to uninstall using both the driver sweeper, and using the catalyst setup, then i installed 11.5 the way you said and now it seems to work :D

Nice, after some time, send me some bitcoins.
Also for CPU usage try this.

http://forum.bitcoin.org/index.php?topic=6188.msg168009#msg168009


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dober64 on June 04, 2011, 09:14:32 PM
jedi95 Hello! Help me please! Why this error?

Traceback (most recent call last):
  File "phoenix.py", line 26, in <module>
  File "zipextimporter.pyc", line 82, in load_module
  File "twisted\internet\reactor.pyc", line 38, in <module>
  File "twisted\internet\selectreactor.pyc", line 200, in install
  File "twisted\internet\selectreactor.pyc", line 72, in __init__
  File "twisted\internet\base.pyc", line 489, in __init__
  File "twisted\internet\posixbase.pyc", line 266, in installWaker
  File "twisted\internet\posixbase.pyc", line 74, in __init__
  File "<string>", line 1, in connect
socket.error: [Errno 10061] ╧юфъы■ўхэшх эх єёЄрэютыхэю,


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: error on June 04, 2011, 09:54:41 PM
jedi95 Hello! Help me please! Why this error?

Traceback (most recent call last):
  File "phoenix.py", line 26, in <module>
  File "zipextimporter.pyc", line 82, in load_module
  File "twisted\internet\reactor.pyc", line 38, in <module>
  File "twisted\internet\selectreactor.pyc", line 200, in install
  File "twisted\internet\selectreactor.pyc", line 72, in __init__
  File "twisted\internet\base.pyc", line 489, in __init__
  File "twisted\internet\posixbase.pyc", line 266, in installWaker
  File "twisted\internet\posixbase.pyc", line 74, in __init__
  File "<string>", line 1, in connect
socket.error: [Errno 10061] ╧юфъы■ўхэшх эх єёЄрэютыхэю,


Your pool is down. Go seek help with the pool operator.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 04, 2011, 10:33:09 PM
jedi95 Hello! Help me please! Why this error?

Traceback (most recent call last):
  File "phoenix.py", line 26, in <module>
  File "zipextimporter.pyc", line 82, in load_module
  File "twisted\internet\reactor.pyc", line 38, in <module>
  File "twisted\internet\selectreactor.pyc", line 200, in install
  File "twisted\internet\selectreactor.pyc", line 72, in __init__
  File "twisted\internet\base.pyc", line 489, in __init__
  File "twisted\internet\posixbase.pyc", line 266, in installWaker
  File "twisted\internet\posixbase.pyc", line 74, in __init__
  File "<string>", line 1, in connect
socket.error: [Errno 10061] ╧юфъы■ўхэшх эх єёЄрэютыхэю,


Your pool is down. Go seek help with the pool operator.

And post a message to the author of Phoenix.  It shouldn't be faulting like that [it rarely continues after such a stack trace is dumped to the console and it, at least for me, has continued to consume ~50% of my GPU doing only God knows what], instead, it should be handling such scenarios gracefully [and perhaps shut itself down].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: frakt on June 05, 2011, 10:07:18 AM
My hashrate is waaaayy too low for my cards. I need some help getting them to work like they should!

Here's my hashrates
http://i.imgur.com/OSlvj.png

Here's my GPU Load
http://i.imgur.com/ZuJxJ.png

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?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: 5tr1k3r on June 05, 2011, 11:23:21 AM
Looks like nothing much to worry about, but maybe it can help you trace some bugs or something.
Pool is deepbit.net, -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false AGGRESSION=12
Card's 5770 950/309.

http://up.idiaths.ru/?id=eb9a9bf1e5c62d07


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: 5tr1k3r on June 05, 2011, 11:38:38 AM
...
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?

Have you tried phatk kernel (-k phatk)?
Also try to underclock memory. It will decrease overall temp giving you the possibility to increase your gpu clocks a little bit. And also it should enhance mhash/s performance.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shackleford on June 05, 2011, 03:36:21 PM
I have been using Phoenix solo for a few days now with a decent hasrate. I finaly got 1 accepted and I thought that would mean that I finaly solved a block. However nothing ever showed up in the bitcoin client and there is still zero in the rejected.

 Is there some other possibility I am missing?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: error on June 05, 2011, 08:04:11 PM
I have been using Phoenix solo for a few days now with a decent hasrate. I finaly got 1 accepted and I thought that would mean that I finaly solved a block. However nothing ever showed up in the bitcoin client and there is still zero in the rejected.

 Is there some other possibility I am missing?

The Bitcoin client doesn't show generated blocks at all until after 2 confirmations. I don't know why this is. You've probably already seen it appear by now.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: yamato57 on June 05, 2011, 08:31:38 PM
Hi im new to bit mining and i am running dual MSI 6990s and they run at 333.33 mhash/sec per GPU which gives me the total of 1332 MHASH/SEC. Is this normal?? I want to try an overclock it as well, can anyone give me tips on how to do that and what rate should i be going at per card or per GPU?? ???

oh btw im also running my SAPPHIRE 5770 1GB on another computer and it only gives me 125.66 mhash/sec. On the wiki it saids i should be going at 156.83 at core of 850. what am i doing wrong?

C:\Users\Username\Desktop\phoenix\phoenix.exe -u username:password@deepbit.net:8332/ -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=8 WORKSIZE=128


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kokojie on June 05, 2011, 09:25:13 PM
I find that even aggression 1 is driving temperature too high (80C) for my card (ATI 6770), how do I set the speed even lower? I currently get 130 Mhash/s but I'm ok with lower speed if I could get my GPU temperature down to 70 level.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: error on June 05, 2011, 09:30:01 PM
I find that even aggression 1 is driving temperature too high (80C) for my card (ATI 6770), how do I set the speed even lower? I currently get 130 Mhash/s but I'm ok with lower speed if I could get my GPU temperature down to 70 level.

Aggression 1 is as fast as possible; you need to raise the number to lower the GPU load.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: 5tr1k3r on June 05, 2011, 09:38:54 PM
Hi im new to bit mining and i am running dual MSI 6990s and they run at 333.33 mhash/sec per GPU which gives me the total of 1332 MHASH/SEC. Is this normal?? I want to try an overclock it as well, can anyone give me tips on how to do that and what rate should i be going at per card or per GPU?? ???

oh btw im also running my SAPPHIRE 5770 1GB on another computer and it only gives me 125.66 mhash/sec. On the wiki it saids i should be going at 156.83 at core of 850. what am i doing wrong?

C:\Users\Username\Desktop\phoenix\phoenix.exe -u username:password@deepbit.net:8332/ -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=8 WORKSIZE=128

666 Mhash/s is normal for 6990. You can see it in the "Mining hardware comparison" page of the wiki. About overclocking — I'm not sure you should try it if you ask such questions... 1.3 Ghash/s is a good speed afterall. But if you really want to overclock your cards, go ahead, download msi afterburner and give it a try (e.g. set 850 mhz for core)... And try to use the forum search next time.

About 5770:
— What SDK do you have? If it's 2.4, use -k phatk, not -k poclbm.
— Why didn't you stick to the recommended miner settings written in the first post? Remove "WORKSIZE=128".


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kokojie on June 05, 2011, 09:40:58 PM
I find that even aggression 1 is driving temperature too high (80C) for my card (ATI 6770), how do I set the speed even lower? I currently get 130 Mhash/s but I'm ok with lower speed if I could get my GPU temperature down to 70 level.

Aggression 1 is as fast as possible; you need to raise the number to lower the GPU load.

That's not true, 1 is slowest, 130 Mhash/s for my gpu, if I set to 5, I get 160 Mhash/s and temperate goes even higher


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: error on June 05, 2011, 09:43:32 PM
I find that even aggression 1 is driving temperature too high (80C) for my card (ATI 6770), how do I set the speed even lower? I currently get 130 Mhash/s but I'm ok with lower speed if I could get my GPU temperature down to 70 level.

Aggression 1 is as fast as possible; you need to raise the number to lower the GPU load.

That's not true, 1 is slowest, 130 Mhash/s for my gpu, if I set to 5, I get 160 Mhash/s and temperate goes even higher

Oops, yes you're right. I need more coffee.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: 5tr1k3r on June 05, 2011, 09:46:46 PM
I find that even aggression 1 is driving temperature too high (80C) for my card (ATI 6770), how do I set the speed even lower? I currently get 130 Mhash/s but I'm ok with lower speed if I could get my GPU temperature down to 70 level.

Try to lower the memory speed.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kokojie on June 05, 2011, 09:48:45 PM
I find that even aggression 1 is driving temperature too high (80C) for my card (ATI 6770), how do I set the speed even lower? I currently get 130 Mhash/s but I'm ok with lower speed if I could get my GPU temperature down to 70 level.

Try to lower the memory speed.

you mean get a gpu utility and manually down-clock the gpu?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jolijar on June 06, 2011, 12:45:37 AM
I am new to using phoenix and I get this error when I start the program.

http://img718.imageshack.us/img718/4995/error2uc.th.jpg (http://imageshack.us/photo/my-images/718/error2uc.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

I am using a AMD 64 x2 5000+ 2.6 Ghz
GeForce 9400 GT
and 3gb ram

Any ideas on how I can fix this?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shackleford on June 06, 2011, 02:55:34 AM
I have been using Phoenix solo for a few days now with a decent hasrate. I finaly got 1 accepted and I thought that would mean that I finaly solved a block. However nothing ever showed up in the bitcoin client and there is still zero in the rejected.

 Is there some other possibility I am missing?

The Bitcoin client doesn't show generated blocks at all until after 2 confirmations. I don't know why this is. You've probably already seen it appear by now.
Thanks for the suggestion but it is definitely not this.  I was hoping it was some kind of configuration I was missing but now it seems like I somehow had a block that got lost in the works with no information on what happened. If it were stale or invalid fine but it is just a mystery.. very discouraging for my first solo attempt.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: error on June 06, 2011, 03:03:42 AM
I have been using Phoenix solo for a few days now with a decent hasrate. I finaly got 1 accepted and I thought that would mean that I finaly solved a block. However nothing ever showed up in the bitcoin client and there is still zero in the rejected.

 Is there some other possibility I am missing?

The Bitcoin client doesn't show generated blocks at all until after 2 confirmations. I don't know why this is. You've probably already seen it appear by now.
Thanks for the suggestion but it is definitely not this.  I was hoping it was some kind of configuration I was missing but now it seems like I somehow had a block that got lost in the works with no information on what happened. If it were stale or invalid fine but it is just a mystery.. very discouraging for my first solo attempt.

Might have been an invalid block, then. (Which, now that I think of it, is probably why Bitcoin doesn't display these until 2 confirmations.)

If you're doing any serious solo mining, you should consider setting up a private pool.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shackleford on June 06, 2011, 03:36:37 AM
I have been using Phoenix solo for a few days now with a decent hasrate. I finaly got 1 accepted and I thought that would mean that I finaly solved a block. However nothing ever showed up in the bitcoin client and there is still zero in the rejected.

 Is there some other possibility I am missing?

The Bitcoin client doesn't show generated blocks at all until after 2 confirmations. I don't know why this is. You've probably already seen it appear by now.
Thanks for the suggestion but it is definitely not this.  I was hoping it was some kind of configuration I was missing but now it seems like I somehow had a block that got lost in the works with no information on what happened. If it were stale or invalid fine but it is just a mystery.. very discouraging for my first solo attempt.

Might have been an invalid block, then. (Which, now that I think of it, is probably why Bitcoin doesn't display these until 2 confirmations.)

If you're doing any serious solo mining, you should consider setting up a private pool.

Thanks much, I can live with that explanation. I am not doing any serious solo mining I just want to get a few blocks or even one while it is still possible and thought I would devote like a month to it but it has me concerned that it may not be working correctly and I possibly could be wasting a few weeks.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: 5tr1k3r on June 06, 2011, 03:39:58 AM
you mean get a gpu utility and manually down-clock the gpu?

I mean get a gpu utility (like msi afterburner), set unofficial overclocking on (search for "EnableUnofficialOverclocking") and manually clock the memory (not gpu) down to 300-320 :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Neutral[Point] on June 06, 2011, 12:05:48 PM
Right now I'm doing 360Mhash/s with 5850 (890/1290/default V) on settings from first post.
I'm gonna play with it a little more later. I'm thinking about rising voltage a little bit so I could try 950 on core.
Great tool indeed.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on June 07, 2011, 07:34:28 AM
another idle stop:
Quote
[07/06/2011 03:28:19] Server gave new work; passing to WorkQueue
[07/06/2011 03:28:28] Result 000000007f14d7ab... accepted
[07/06/2011 03:29:38] Server gave new work; passing to WorkQueue
[07/06/2011 03:30:58] Server gave new work; passing to WorkQueue
[07/06/2011 03:32:06] Result 000000000d6b2652... accepted
[07/06/2011 03:32:17] Server gave new work; passing to WorkQueue
[07/06/2011 03:33:15] Result 00000000da134dd0... accepted
[07/06/2011 03:33:18] Result 000000006f8cfd20... accepted
[07/06/2011 03:33:31] Result 00000000e5e44240... accepted
[07/06/2011 03:33:36] Server gave new work; passing to WorkQueue
[07/06/2011 03:34:56] Server gave new work; passing to WorkQueue
[07/06/2011 03:35:48] Result 00000000bad9dcb6... accepted
[07/06/2011 03:36:02] Server gave new work; passing to WorkQueue
[07/06/2011 03:37:20] Server gave new work; passing to WorkQueue
[07/06/2011 03:37:31] Result 00000000b8083712... accepted
[07/06/2011 03:38:25] Result 00000000fa7f0a12... accepted
[07/06/2011 03:38:32] Result 000000008fc523e9... accepted
[07/06/2011 03:38:39] Server gave new work; passing to WorkQueue
[07/06/2011 03:39:33] Result 00000000d3a5b849... accepted
[07/06/2011 03:39:58] Server gave new work; passing to WorkQueue
[07/06/2011 03:41:08] Server gave new work; passing to WorkQueue
[07/06/2011 03:41:08] New block (WorkQueue)
[07/06/2011 03:41:08] Currently on block: 129123
[07/06/2011 03:41:09] Server gave new work; passing to WorkQueue
[07/06/2011 03:42:07] Server gave new work; passing to WorkQueue
[07/06/2011 03:43:03] Result 00000000e2e41fd2... rejected
[07/06/2011 03:43:21] Server gave new work; passing to WorkQueue
[07/06/2011 03:43:22] New block (WorkQueue)
[07/06/2011 03:43:22] Currently on block: 129124
[07/06/2011 03:43:23] Server gave new work; passing to WorkQueue
[07/06/2011 03:44:20] Result 00000000047efef7... accepted
[07/06/2011 03:44:42] Server gave new work; passing to WorkQueue
[07/06/2011 03:44:49] Result 0000000077c476c0... accepted
[07/06/2011 03:46:02] Server gave new work; passing to WorkQueue
[07/06/2011 03:48:33] Warning: work queue empty, miner is idle
[0 Khash/sec] [246 Accepted] [20 Rejected] [RPC]
hmm


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bradstrom on June 08, 2011, 12:29:17 AM
I'm trying to run Phoenix on my 5830, and I'm getting an error. I received the same error when running a GTX 260. OS is Windows 7 x64.

Here's my command line input for the 5830:
Quote
phoenix.exe -u http://bradstrom:********@bitcoinpool.com:8332/ -k poclbm DEVICE=0

Here is the error:
Quote
FATAL kernel error: Failed to load OpenCL kernel!

I installed ATI drivers fresh today, and I am able to run poclbm on GUIMiner. Any suggestions?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: mattpker on June 08, 2011, 12:44:43 PM
Sounds like you are missing the poclbm kernel in the kernels directory located where your phoenix.exe file is.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Freakin on June 08, 2011, 09:41:31 PM
Is there any way to record a logfile at the same time it is displayed on screen?

I want to monitor my miners with nagios but be able to see my usual data on screen.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TurdHurdur on June 08, 2011, 09:42:46 PM
Is there any way to record a logfile at the same time it is displayed on screen?

I want to monitor my miners with nagios but be able to see my usual data on screen.
Use tee.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Freakin on June 08, 2011, 09:54:37 PM
Is there any way to record a logfile at the same time it is displayed on screen?

I want to monitor my miners with nagios but be able to see my usual data on screen.
Use tee.

awesome!  Thanks for the tip.  Never used tee before.

Found that a windows port was part of UnxUtils
http://sourceforge.net/projects/unxutils/files/

now i gotta remember how to add a service to nagios :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dingen on June 09, 2011, 12:12:13 AM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CubedRoot on June 09, 2011, 01:37:18 AM
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?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: super6 on June 09, 2011, 02:26:28 AM
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?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 09, 2011, 03:46:25 AM
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
http://i.imgur.com/OSlvj.png

Here's my GPU Load
http://i.imgur.com/ZuJxJ.png

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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 09, 2011, 03:57:57 AM
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?].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on June 09, 2011, 04:12:25 AM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: gigabytecoin on June 09, 2011, 04:33:26 AM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: gentakin on June 09, 2011, 01:25:46 PM
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. :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: keybaud on June 09, 2011, 04:31:11 PM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kcobra on June 09, 2011, 04:47:06 PM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 09, 2011, 04:57:58 PM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: keybaud on June 09, 2011, 09:13:39 PM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: kcobra on June 09, 2011, 09:25:11 PM
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.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 09, 2011, 09:35:14 PM
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? :)) 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].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: AngstHase on June 10, 2011, 12:53:30 AM
Have some problems with internet reconnects and phoenix too. Falling down to 0 Mh/s sucks for dedicated miner ;D


Title: Spurious rejections for slow Phoenix miners on Pushpool-based mining pools
Post by: MintCondition on June 10, 2011, 03:56:38 AM

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.



Title: wHY only one GPU work ?
Post by: derbe on June 10, 2011, 09:39:31 AM
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 :)  It is not my mother speech.


Title: Re: wHY only one GPU work ?
Post by: maxcorrads on June 10, 2011, 09:49:29 AM
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 :)  It is not my mother speech.

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


Title: Re: wHY only one GPU work ?
Post by: derbe on June 10, 2011, 09:56:42 AM
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 :)  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 :D :D :D
Ok i found some nice:
http://www.overclock.net/folding-home-guides-tutorials/384733-30-second-dummy-plug.html

THX for respone ;)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: mosie on June 10, 2011, 10:08:18 AM
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.


Title: Re: wHY only one GPU work ?
Post by: keybaud on June 10, 2011, 12:54:20 PM
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 :)  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 :D :D :D
Ok i found some nice:
http://www.overclock.net/folding-home-guides-tutorials/384733-30-second-dummy-plug.html

THX for respone ;)

Nothing to do with ATI or NVidia, it's a Windows limitation.


Title: Re: wHY only one GPU work ?
Post by: mosie on June 10, 2011, 01:05:08 PM
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 :)  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 :D :D :D
Ok i found some nice:
http://www.overclock.net/folding-home-guides-tutorials/384733-30-second-dummy-plug.html

THX for respone ;)

Nothing to do with ATI or NVidia, it's a Windows limitation.

Sure !


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mato Kira on June 10, 2011, 11:58:27 PM
I'm running a 9800M GTS, only getting about 14.8Mh/s with AGGRESSION=3 and WORKSIZE=64. Anyone have any suggestions for upping this?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: 5tr1k3r on June 11, 2011, 12:36:35 AM
I'm running a 9800M GTS, only getting about 14.8Mh/s with AGGRESSION=3 and WORKSIZE=64. Anyone have any suggestions for upping this?
Unfortunately, there is only one suggestion — buy a decent amd card, and preferably not a mobile one. https://en.bitcoin.it/wiki/Mining_hardware_comparison (https://en.bitcoin.it/wiki/Mining_hardware_comparison)


Title: Re: Spurious rejections for slow Phoenix miners on Pushpool-based mining pools
Post by: memvola on June 11, 2011, 12:43:50 AM
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 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.
Thanks for the hint. I've been getting a very high rejected rate (50%-75%) on slower miners using phoenix. Doesn't happen while using poclbm for instance...

Looks like lpaskrate was introduced in 1.48, but it didn't solve my problems. Options I use are roughly:

Code:
./phoenix.py AGGRESSION=9 WORKSIZE=256 -u http://1XXX0pps:x@continuumpool.com:8332/;lpaskrate=20 DEVICE=0

The same with swepool. I tried reducing askrate to 5 as well. Any ideas why this didn't work?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mato Kira on June 11, 2011, 01:33:59 AM
I'm running a 9800M GTS, only getting about 14.8Mh/s with AGGRESSION=3 and WORKSIZE=64. Anyone have any suggestions for upping this?
Unfortunately, there is only one suggestion — buy a decent amd card, and preferably not a mobile one. https://en.bitcoin.it/wiki/Mining_hardware_comparison (https://en.bitcoin.it/wiki/Mining_hardware_comparison)
Kinda locked into a solution with it being a laptop and all.. are there any effective ways to overclock?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: asdfg on June 11, 2011, 04:20:34 PM
Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
  File "Miner.pyc", line 75, in start
  File "phoenix.py", line 111, in makeKernel
  File "kernels\poclbm\__init__.py", line 22, in <module>
    import pyopencl as cl
  File "zipextimporter.pyc", line 82, in load_module
  File "pyopencl\__init__.pyc", line 3, in <module>
  File "zipextimporter.pyc", line 98, in load_module
ImportError: MemoryLoadLibrary failed loading pyopencl\_cl.pyd


 ???


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Etheric on June 11, 2011, 05:56:10 PM
Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
  File "Miner.pyc", line 75, in start
  File "phoenix.py", line 111, in makeKernel
  File "kernels\poclbm\__init__.py", line 22, in <module>
    import pyopencl as cl
  File "zipextimporter.pyc", line 82, in load_module
  File "pyopencl\__init__.pyc", line 3, in <module>
  File "zipextimporter.pyc", line 98, in load_module
ImportError: MemoryLoadLibrary failed loading pyopencl\_cl.pyd


 ???

I had this problem too initially. I think it is related to the SDK driver not being properly installed.

I fixed it by uninstalling my current drivers, booting into safe mode, and using Driver Sweeper to remove all traces of old drivers and then installing the full 11.5 Catalyst suite.

Hope that helps you too!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: asdfg on June 11, 2011, 06:43:51 PM
Traceback (most recent call last):
  File "phoenix.py", line 123, in <module>
  File "Miner.pyc", line 75, in start
  File "phoenix.py", line 111, in makeKernel
  File "kernels\poclbm\__init__.py", line 22, in <module>
    import pyopencl as cl
  File "zipextimporter.pyc", line 82, in load_module
  File "pyopencl\__init__.pyc", line 3, in <module>
  File "zipextimporter.pyc", line 98, in load_module
ImportError: MemoryLoadLibrary failed loading pyopencl\_cl.pyd


 ???

I had this problem too initially. I think it is related to the SDK driver not being properly installed.

I fixed it by uninstalling my current drivers, booting into safe mode, and using Driver Sweeper to remove all traces of old drivers and then installing the full 11.5 Catalyst suite.

Hope that helps you too!

Updated my drivers and it works, thank you.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CubedRoot on June 11, 2011, 07:05:08 PM
CAn someone tell my why a LP push like the ones below locks my GPU down, and forces me to restart?

I am using Ubuntu 64, newest phoenix and phatk kernel


Code:
[11/06/2011 14:42:10] Result: ac8fb0cd accepted
[11/06/2011 14:42:18] Result: a42fd6a2 accepted
[11/06/2011 14:42:35] Result: 652fb629 accepted
[11/06/2011 14:49:17] LP: New work pushed
[11/06/2011 14:52:32] LP: New work pushed
[11/06/2011 14:56:03] LP: New work pushed
[11/06/2011 14:57:19] LP: New work pushed
[309.70 Mhash/sec] [10 Accepted] [0 Rejected] [RPC (+LP)]




Title: Re: Spurious rejections for slow Phoenix miners on Pushpool-based mining pools
Post by: MintCondition on June 11, 2011, 07:33:57 PM

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.

An update on this bug: Upon further research into the Phoenix code it seems that specifying the lpaskrate argument does not actually solve anything, so please ignore the quoted solution. I originally assumed the queuesize was intended as both preferred and maximum size, so that the oldest work would be abandoned when overfilling the queue. Instead, current work will only be abandoned when a new block has been detected; any forced getwork responses will just be added to the workqueue, only making the problem worse.

A better avenue for improvement, although more involved, might be to add an expiration mechanism to the Phoenix code. Until then I'd recommend never mining at less than 36MH/s to avoid rejected shares caused by this bug.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jondecker76 on June 11, 2011, 09:34:07 PM
For a little bit while deepbit was down today, I decided to try solo mining...  DUring the short period that I tried it (About 10 minutes),  phoenix kept reporting "Result didn't meet full difficulty, not sending"

what does this mean?  I was showing a normal hash rate, and showing 0 accepter, 0 rejected.  I've never seen this before mining in any pool.

thanks!


Title: Re: Spurious rejections for slow Phoenix miners on Pushpool-based mining pools
Post by: jedi95 on June 12, 2011, 06:23:44 PM

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.

An update on this bug: Upon further research into the Phoenix code it seems that specifying the lpaskrate argument does not actually solve anything, so please ignore the quoted solution. I originally assumed the queuesize was intended as both preferred and maximum size, so that the oldest work would be abandoned when overfilling the queue. Instead, current work will only be abandoned when a new block has been detected; any forced getwork responses will just be added to the workqueue, only making the problem worse.

A better avenue for improvement, although more involved, might be to add an expiration mechanism to the Phoenix code. Until then I'd recommend never mining at less than 36MH/s to avoid rejected shares caused by this bug.

This is not accurate concerning the queue. The queue itself uses the deque class which has a maximum size set to the size the user specifies. Adding additional work to queue will automatically purge the oldest work if the queue is full. See the documentation for deque here:

Quote
If maxlen is not specified or is None, deques may grow to an arbitrary length. Otherwise, the deque is bounded to the specified maximum length. Once a bounded length deque is full, when new items are added, a corresponding number of items are discarded from the opposite end. Bounded length deques provide functionality similar to the tail filter in Unix. They are also useful for tracking transactions and other pools of data where only the most recent activity is of interest.

http://docs.python.org/library/collections.html#collections.deque



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: finnthecelt on June 12, 2011, 07:02:39 PM
I'm running a 9800M GTS, only getting about 14.8Mh/s with AGGRESSION=3 and WORKSIZE=64. Anyone have any suggestions for upping this?
Unfortunately, there is only one suggestion — buy a decent amd card, and preferably not a mobile one. https://en.bitcoin.it/wiki/Mining_hardware_comparison (https://en.bitcoin.it/wiki/Mining_hardware_comparison)
Kinda locked into a solution with it being a laptop and all.. are there any effective ways to overclock?

http://www.overclock.net/nvidia-drivers-overclocking-software/461651-9800m-gts-overclocking-possible.html (http://www.overclock.net/nvidia-drivers-overclocking-software/461651-9800m-gts-overclocking-possible.html)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mousepotato on June 12, 2011, 08:46:39 PM
I just downclocked my memory to 300MHz (down from 1200MHz) and I picked up a good 22-23Mh/s.  Sweet!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SchizophrenicX on June 13, 2011, 11:37:53 AM
Would you guys recommend LinuxCoin?

I have been trying to get my Ubuntu up but to no avail. LiveCD installs on 4 GB drives but I think a full install requires > 4.4 GB


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: AngstHase on June 13, 2011, 12:33:27 PM
any chance to get a phoenix update soon?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: supa on June 13, 2011, 03:07:35 PM

I tried to skim through the thread but I still have a couple of questions regarding the kernel AGGRESSION parameter and -a (average samples).

For starters...  In Windows, if I set my aggression higher than 15, it seems the whole thing explodes.  15 works OK with a laggy display (expected).

In Linux, I don't care about the display, so I put my aggression to 20.  Linux gets a higher hash rate.  I'm not sure anything over 15 actually does anything, but 20 seemed like a good number at the time....

What is this doing... ? :)

Is there a relation to this and the -f (frames) in poclbm?  A windows machine with poclbm -f 0 is still mostly usable.

Finally, according to this -
Quote
-a (average samples) - Sets the number of samples to use for hashrate averaging. Default is 10. You might want to lower this for longer kernel execution times. (high aggression)

I should make a lower -a for higher aggression.  I tried setting it to "-a 1" without much difference and even "-a 0".  What does this do?

Using phatk kernel if it matters.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on June 13, 2011, 08:25:01 PM
AGGRESSION is used to set the number of nonces to run per kernel execution. Values above 16 won't do anything because nonces to run = 2^(16 + AGGRESSION) Setting a higher value for AGGRESSION will simply round down to the highest valid value (16)

The -a parameter is used for the hashrate display. With higher aggression settings kernels can take several seconds to run, so this makes taking 16 samples rather pointless. The reason multiple samples are used is that otherwise the displayed hashrate would fluctuate greatly at low aggression.

The -f option in poclbm is somewhat similar to aggression because it also controls kernel execution sizes. The main difference is that aggression sets the number of nonces to run per execution while -f sets the target time for each execution. (-f adjusts the number of nonces constantly to maintain the target execution time)

As for updates to Phoenix, I think I have a solid workaround for the idle problem now. I still don't know the exact reason for it, but the workaround should be sufficient to recover automatically. I will release this is 1.50 shortly if I don't find any issues in testing. These changes are included in the latest SVN revision (r101) if anyone wants to try it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SchizophrenicX on June 14, 2011, 01:59:10 PM
constantly getting failed to connect: retrying message on Ubuntu 11.04. Followed the guide around here.
poclbm connects normally. so I'm guessing I'm missing something...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: finnthecelt on June 14, 2011, 05:35:20 PM
constantly getting failed to connect: retrying message on Ubuntu 11.04. Followed the guide around here.
poclbm connects normally. so I'm guessing I'm missing something...


Yeah, windows.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SchizophrenicX on June 14, 2011, 06:08:37 PM
yea. I'm having windows trouble right now and I have been trying to get my miners running on linux since it's free. I don't even have a working windows machine right now unfortunately... although at this moment it seems like one of my old XP machine is able to restore it's OS from a recovery partition.

Anyway... Here is what shows in terminal

Code:
me@ubuntu:~/poclbm$ ./poclbm.py
No device specified or device not found, use -d to specify one of the following

[0] AMD Phenom(tm) II X4 B55 Processor
[1] Cypress
[2] Cypress
[3] Cypress
[4] Cypress
[5] Cypress
me@ubuntu:~/poclbm$ cd ../phoenix
me@ubuntu:~/phoenix$ ./phoenix.py -u http://username.workername:workerpassword@api.bitcoin.cz -k phatk DEVICE=1 VECTORS BFI_INT WORKSIZE=256 AGGRESSION=7
[15/06/2011 01:47:29] Phoenix r101 starting...
[15/06/2011 01:47:30] Failed to connect, retrying...
[15/06/2011 01:47:45] Failed to connect, retrying...
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]^Cme@ubuntu:~/phoenix$ cd ../poclbm
wenbin@Binbuntu:~/poclbm$ ./poclbm.py -d1 -o api.bitcoin.cz -u username.workername --pass=workerpassword -v -w256 -f30
15/06/2011 01:48:39, 0b7c45c9, accepted                     
15/06/2011 01:48:44, f2c5f913, accepted                     
299841 khash/s


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on June 14, 2011, 10:10:50 PM
Version 1.50 has been released.

This should fix the miner getting stuck idle. I added a workaround for now since I am not 100% confident that I fixed the underlying problem.

Changes:
1. Fixed long poll crashing when the server disconnects the miner with a message
2. Fixed QueueReader error when stopping the kernel
3. Several RPC protocol changes to reduce occurrence of idle miner problem
4. When idle the miner will now request more work every 15 seconds (this should eliminate idling in cases where the connection isn't lost)
5. LP now works in cases where the URL uses a query string (thanks to error for the patch, see page 30 for details)


@SchizophrenicX

You need to add the port after the server:

http://username.workername:workerpassword@api.bitcoin.cz:8332


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BitMinerN8 on June 14, 2011, 11:03:18 PM
Version 1.50 has been released.


Thanks! I'll start updating the farm.  :P


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Nachtwind on June 15, 2011, 12:38:18 AM
I tried it...
Code:
2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:xxxx@btcguild.com:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on June 15, 2011, 02:00:39 AM
I tried it...
Code:
2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:xxxx@btcguild.com:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

That's odd, the BFI_INT patcher hasn't been changed since 1.0 so I don't see how updating could break it. Does it work if you don't use the BFI_INT flag?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BitMinerN8 on June 15, 2011, 02:08:16 AM
I tried it...
Code:
2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:xxxx@btcguild.com:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)

That's odd, the BFI_INT patcher hasn't been changed since 1.0 so I don't see how updating could break it. Does it work if you don't use the BFI_INT flag?

For testing I have put this on a number of rigs (4 of 12) in my farm and am not having any issues like you are describing. I am not using GUIMiner though, just running it through command prompt/script. All my mining rigs are extremely clean, just Win7 x64 w/SP1, the ATI Drivers with only the AMD APP/SDK selected, then I use ATI Tray Tools for the OC. Set to autologin and run the scripts. Options:
-k phatk PLATFORM=0 DEVICE=1 VECTORS BFI_INT FASTLOOP=false WORKSIZE=128 AGGRESSION=11



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Clipse on June 15, 2011, 02:17:24 AM
Heres a pickle, I seem to get 3mhash on the dot less on 4 rigs i just updated with 1.50 from 1.48 with same arguments used.

Retried with 1.48 and hashrate went up exactly 3mhash o_0

Is there a reason for the slight drop, or is 1.48 reporting wrong hashrate ?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: brunoshady on June 15, 2011, 02:26:24 AM
I tried it...
Code:
2011-06-15 02:29:22: Wird ausgeführt: E:\bitcoin\guiminer\guiminer\phoenix.exe -u http://xxxx:xxxx@btcguild.com:8332 PLATFORM=0 DEVICE=0 VECTORS  AGGRESSION=5 -v FASTLOOP=true  BFI_INT -k phatk
2011-06-15 02:29:22: Listener für "btc" gestartet
2011-06-15 02:29:26: Listener für "btc": [15/06/2011 02:29:26] Finding inner ELF...

From that moment onwards there was 5 minutes with nothing happening (yet still showing MHASH in the Gui(miner 06-09). ALso the MH was at about 180 compared to 200 with the 1.48 release...

System Specs:
Intel COre 2 Duo 2160
1x ATI 6850
4GB RAM
Windows 7 x64

Guess i will stick with the previous version and hope this might post was useful ,0)


try the command like this, yours is very confused...


phoenix -v -u http://xxxx:xxxx@btcguild.com:8332 -k phatk DEVICE=0 VECTORS BFI_INT AGGRESSION=5


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: innervisi0nn on June 15, 2011, 05:25:24 AM
[14/06/2011 22:23:17] Phoenix 1.50 starting...
[14/06/2011 22:23:17] Connected to server
MSG: upstream RPC error
[14/06/2011 22:23:40] Disconnected from server
[14/06/2011 22:23:54] Warning: work queue empty, miner is idle
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

getting that issue...only with 2 pools tho, any idea?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d.james on June 15, 2011, 05:26:35 AM
new version works flawlessly with the phoenix rising guiminer here


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Nachtwind on June 15, 2011, 06:41:51 AM
Ok, started without BFI_INT and with commands put together like suggested:
It seems to be doing "Something".
Code:
2011-06-15 08:36:09: Listener für "btc" gestartet
2011-06-15 08:36:10: Listener für "btc": [15/06/2011 08:36:10] Phoenix 1.50 starting...

Then nothing (no more console output) - but my shares on BTCGuild are increasing. Yet without BFI_INT i have a performance drop of roughly 20% to 25%

Now with BFI_INT and commands put together in the new order there is still no console output but it seems to work with about 5% less MH (compared to 1.48).



In case you dont see a reason for your software behaving that odd - i have a shitload of SDKs on this PC and there might be something interfering somewhere... wouldnt be the first software...



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: niooron on June 15, 2011, 03:56:55 PM
Sometimes I still get stale shares after a LP notification. Is the queue bug still unfixed?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on June 15, 2011, 04:43:28 PM
Sometimes I still get stale shares after a LP notification. Is the queue bug still unfixed?

This can happen if the share was already being sent when the LP request returned a new block. Shares are checked against the current block before being sent, but after that there are no further checks.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bongo on June 15, 2011, 08:03:43 PM
1.50 works well :) , stales have come down a bit  ;D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SchizophrenicX on June 15, 2011, 08:17:32 PM
Version 1.50 has been released.

This should fix the miner getting stuck idle. I added a workaround for now since I am not 100% confident that I fixed the underlying problem.

Changes:
1. Fixed long poll crashing when the server disconnects the miner with a message
2. Fixed QueueReader error when stopping the kernel
3. Several RPC protocol changes to reduce occurrence of idle miner problem
4. When idle the miner will now request more work every 15 seconds (this should eliminate idling in cases where the connection isn't lost)
5. LP now works in cases where the URL uses a query string (thanks to error for the patch, see page 30 for details)


@SchizophrenicX

You need to add the port after the server:

http://username.workername:workerpassword@api.bitcoin.cz:8332


Nope. Didn't work. seriously. am I the only one kept having problems keeping a dedicated rig running 24/7 I really need some help


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: RedLine888 on June 15, 2011, 09:04:05 PM
Much less stales after update! Thanks!

What is so unique in hashskill that makes it faster than Phoenix+Phatk?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on June 15, 2011, 10:40:01 PM
Much less stales after update! Thanks!

What is so unique in hashskill that makes it faster than Phoenix+Phatk?

My guess is that hashkill has less overhead from host <--> device transfers:


Another thing is (don't know if that's possible with pyopencl) - don't use clenqueuereadbuffer() (or whatever it's equivalent is). Use clenqueuemapbuffer() instead. It's noticably faster. Hm really started wondering about modifying some python miner to incorporate that kernel there, looks like a quick way to make it portable to windows. Besides, there are obvious problems with the non-ocl part which are due to code inmaturity.

I have looked at the hashkill OpenCL kernel in AMD's KernelAnalyzer and theoretically it should be the same speed as phatk on SDK 2.4


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mousepotato on June 16, 2011, 03:43:07 AM
Awesome! 1.50 totally eliminated the "miner is idle" lines I was seeing every so often!

Edit: I take that back.  I"m seeing the "miner is idle" lines again, although less frequent than before.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dikidera on June 16, 2011, 04:54:07 AM
Hmm, for me, i see a drop of 2 Mhash/s with 1.50. Not something to kill for, but 2 mhash/s more is the equivalent of 5 mhz overclock for me.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on June 16, 2011, 06:04:48 AM
Awesome! 1.50 totally eliminated the "miner is idle" lines I was seeing every so often!

Edit: I take that back.  I"m seeing the "miner is idle" lines again, although less frequent than before.

The problem that was fixed in 1.50 was the miner getting stuck idle due to a bug in the RPC protocol. You will still get "miner is idle" from time to time, but it shouldn't get stuck idle unless it can't connect to the server.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Peao on June 16, 2011, 04:52:23 PM
First, congratulations for keeping the good work jedi95! I already sent another donation.

I noticed a decrease in cases of miners remain stuck after a warning of "miner is idle".

But some still get stuck... Normally my rigs with Ubuntu (maybe it's a coincidence, but W7 rigs are running fine).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on June 16, 2011, 08:09:58 PM
Quote
[16/06/2011 20:21:48] Server gave new work; passing to WorkQueue
[16/06/2011 20:22:01] Result 000000002f4255ac... accepted
[16/06/2011 20:22:06] Result 00000000956163ae... accepted
[16/06/2011 20:22:08] Result 000000006244c69e... accepted
[16/06/2011 20:22:15] Server gave new work; passing to WorkQueue
[16/06/2011 20:22:42] Server gave new work; passing to WorkQueue
[16/06/2011 20:23:08] Result 0000000068e4507d... rejected
[16/06/2011 20:23:08] Result 00000000e2b80025... rejected
[16/06/2011 20:23:09] Server gave new work; passing to WorkQueue
[16/06/2011 20:23:10] New block (WorkQueue)
[16/06/2011 20:23:13] Result 000000003717b83f... accepted
[16/06/2011 20:23:25] Result 00000000706aa557... accepted
[16/06/2011 20:23:28] Result 00000000edf564dc... accepted
[16/06/2011 20:23:37] Warning: work queue empty, miner is idle
[0 Khash/sec] [859 Accepted] [23 Rejected] [RPC (+LP)]
v1.50
did not restart for two hours...

Seven other miner instances worked fine, one of them on the same GPU. Could it be something with the socket connection?

anything we can do to help debug?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: SchizophrenicX on June 16, 2011, 09:39:31 PM
after fresh reinstall of Ubuntu and following the guide completely again. Phoenix is working now. I'm doing AGGRESSION=13 + backup pool with poclbm -f60.

Still have no idea why it didn't work previously, but since I couldn't get much help from the forum I reinstalled everything, works fine now. Btw jedi. Nice job on the new release. No more freezing workers :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on June 17, 2011, 12:48:02 AM
Quote
[16/06/2011 20:21:48] Server gave new work; passing to WorkQueue
[16/06/2011 20:22:01] Result 000000002f4255ac... accepted
[16/06/2011 20:22:06] Result 00000000956163ae... accepted
[16/06/2011 20:22:08] Result 000000006244c69e... accepted
[16/06/2011 20:22:15] Server gave new work; passing to WorkQueue
[16/06/2011 20:22:42] Server gave new work; passing to WorkQueue
[16/06/2011 20:23:08] Result 0000000068e4507d... rejected
[16/06/2011 20:23:08] Result 00000000e2b80025... rejected
[16/06/2011 20:23:09] Server gave new work; passing to WorkQueue
[16/06/2011 20:23:10] New block (WorkQueue)
[16/06/2011 20:23:13] Result 000000003717b83f... accepted
[16/06/2011 20:23:25] Result 00000000706aa557... accepted
[16/06/2011 20:23:28] Result 00000000edf564dc... accepted
[16/06/2011 20:23:37] Warning: work queue empty, miner is idle
[0 Khash/sec] [859 Accepted] [23 Rejected] [RPC (+LP)]
v1.50
did not restart for two hours...

Seven other miner instances worked fine, one of them on the same GPU. Could it be something with the socket connection?

anything we can do to help debug?

I am completely out of ideas for fixing this. I have looked through the RPC protocol code countless times and I can't find the cause. At this point I'm going to have to leave it up to other developers to fix.

However, if someone can identify the cause of the problem I should be able to fix it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: OtaconEmmerich on June 17, 2011, 07:05:41 AM
Hey, Sevenwolf here on the forums had this problem while mining. Message him for details: http://pastie.org/2081416


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: testerx on June 17, 2011, 11:01:29 AM
I get a similar rate though for some odd reason guiminer shows Connecting for a reaaaaly long time even though it's clearly already connected and mining and submitting shares.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cyberchriss on June 17, 2011, 11:55:52 PM
Quote
MSG: upstream RPC error                                     
[18/06/2011 01:29:06] Disconnected from server             
[18/06/2011 01:29:18] Warning: work queue empty, miner is idle
[18/06/2011 01:29:19] Result: d8d7ccc4 accepted 
[18/06/2011 01:29:19] Connected to server       
[18/06/2011 01:29:43] Warning: work queue empty, miner is idle
[18/06/2011 01:31:13] Result: c8b213d5 accepted       
[18/06/2011 01:31:13] Result: 2dd8e44a accepted       
MSG: upstream RPC error                               
[18/06/2011 01:31:13] Disconnected from server         
[18/06/2011 01:31:23] Result: e5eb79fe accepted       
[18/06/2011 01:31:24] Result: d981469f accepted 
MSG: upstream RPC error                         
[18/06/2011 01:31:34] Failed to connect, retrying...
MSG: upstream RPC error                         
[18/06/2011 01:32:30] Failed to connect, retrying...
MSG: upstream RPC error                         
[18/06/2011 01:32:43] Failed to connect, retrying...
MSG: upstream RPC error                         
[18/06/2011 01:32:58] Failed to connect, retrying...
MSG: upstream RPC error                         
[18/06/2011 01:34:01] Failed to connect, retrying...
MSG: upstream RPC error                         
[18/06/2011 01:36:22] Failed to connect, retrying...
MSG: upstream RPC error                         
[18/06/2011 01:36:33] Failed to connect, retrying...
MSG: upstream RPC error                         
[18/06/2011 01:37:42] Failed to connect, retrying...
[0 Khash/sec] [1812 Accepted] [30 Rejected] [RPC]

This erro occurs with Version 1.5



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: disq on June 18, 2011, 12:08:57 AM
v1.50, I've been getting this from time to time:

Quote
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 519, in connectionLost
    protocol.connectionLost(reason)
  File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 826, in dispatcher
    return func(*args, **kwargs)
  File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 1438, in _connectionLost_WAITING
    self._disconnectParser(reason)
  File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 1367, in _disconnectParser
    parser.connectionLost(reason)
--- <exception caught here> ---
  File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 494, in connectionLost
    self.bodyDecoder.noMoreData()
  File "/usr/lib/python2.6/dist-packages/twisted/web/http.py", line 1388, in noMoreData
    finishCallback('')
  File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 409, in _finished
    self.finisher(rest)
  File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 1346, in _finishResponse
    self._giveUp(Failure(reason))
exceptions.UnboundLocalError: local variable 'reason' referenced before assignment


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mikecraft on June 18, 2011, 02:43:27 AM
Hey, I made a quick patch for Phoenix Miner 1.5. It just displays efficiency (accepted shares / get work requests * 100) along with the other stats. Additionally I copied the logging code from poclbm-mod (public domain so why not) because that doesn't make the status flicker on windows like phoenix did and because it's easier to print formatted strings (e.g. percent to two decimal places) that way. I also changed a few parts of the status to fit better on 80 character lines (accepted -> ACC rejected  -> REJ).

Patch can be found here: http://pastebin.com/basCaTXM


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: brunoshady on June 18, 2011, 03:01:40 AM
post pic of your patch plz =)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mikecraft on June 18, 2011, 03:32:20 AM
As requested: http://i.imgur.com/OQqKd.png


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on June 18, 2011, 10:03:55 AM
I had two hard crashes / freezes with v1.50 but never before. anyone else? maybe it's time to switch from drivers 10.12 to 11.6.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: peedee on June 18, 2011, 09:01:26 PM
Getting the following error on my mac :
Code:
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/twisted/internet/_sslverify.py:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead
  import itertools, md5
Traceback (most recent call last):
  File "./phoenix.py", line 29, in <module>
    import minerutil
  File "/Users/Dittie/Downloads/phoenix-1.50/minerutil/__init__.py", line 25, in <module>
    from RPCProtocol import RPCClient
  File "/Users/XXXXXXX/Downloads/phoenix-1.50/minerutil/RPCProtocol.py", line 26, in <module>
    from twisted.web.iweb import IBodyProducer
ImportError: cannot import name IBodyProducer



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Legion on June 19, 2011, 05:47:31 AM
Hi, Phoenix has been causing hard resets for me when mining with both cards. I can mine with one indefinately, or run a furmark instance on both with no issues. Game on one while mining on other, etc with no problems at all. But if I start two Phoenix miners my computer will just suddenly reset within two minutes. However, if I give one of the miners no arguments at all this doesn't happen. I started a thread about the issue I'm having: http://forum.bitcoin.org/index.php?topic=19289.0

Never had a rejected share or artifacts, and can furmark on both cards, so it can't be a hardware problem.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: brunoshady on June 19, 2011, 06:48:12 AM
this could be temperature... with arguments both stay at the limit and temperatures go at the top


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Legion on June 19, 2011, 07:06:49 AM
Nope. Not temps. Like I said, I can run FURMARK on both cards at the same time, no issues. Furmark makes them hotter than Bitcoin mining does.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: brunoshady on June 19, 2011, 04:15:09 PM
hmmm


strange...


have your tried different kernels? or miners?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: PcChip on June 20, 2011, 06:17:50 AM
Nope. Not temps. Like I said, I can run FURMARK on both cards at the same time, no issues. Furmark makes them hotter than Bitcoin mining does.

That is by far one of the strangest issues I've ever seen, please let us know if you ever figure it out!

Things I'd start with - swapping PSU's, swapping PCI-E slot order of the cards, making sure PCI-E bus is at exactly 100MHz, FSB isn't overclocked, RAM is running at spec (or under spec to be safe), maybe try ORTHOS set to "blend" mode to make sure it's not something between the cpu and the gpu core that's causing errors (furmark only loads the GPU, not the bus from the CPU _to_ the GPU)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Legion on June 20, 2011, 07:35:13 AM
Nope. Not temps. Like I said, I can run FURMARK on both cards at the same time, no issues. Furmark makes them hotter than Bitcoin mining does.

That is by far one of the strangest issues I've ever seen, please let us know if you ever figure it out!

Things I'd start with - swapping PSU's, swapping PCI-E slot order of the cards, making sure PCI-E bus is at exactly 100MHz, FSB isn't overclocked, RAM is running at spec (or under spec to be safe), maybe try ORTHOS set to "blend" mode to make sure it's not something between the cpu and the gpu core that's causing errors (furmark only loads the GPU, not the bus from the CPU _to_ the GPU)

I dropped both cards down to their stock clocks and suddenly it works. Tested for multiple hours twice. Once while working on the house and then again while out to dinner. For some reason Furmark & Shogun 2 don't expose the faulty OC (which was only 50MHZ per card core), but bitcoin mining and Modern Warfare 2 do. And Bitcoin mining causes a hard reset instead of a simple driver crash like MW2.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: DarkMatter on June 20, 2011, 07:41:36 AM
May be verywell a psu related issue.
Try using a new one, and overclock again.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: mmortal03 on June 20, 2011, 12:52:01 PM
Quote
MSG: upstream RPC error                                    
[18/06/2011 01:29:06] Disconnected from server              
[18/06/2011 01:29:18] Warning: work queue empty, miner is idle
[18/06/2011 01:29:19] Result: d8d7ccc4 accepted  
[18/06/2011 01:29:19] Connected to server        
[18/06/2011 01:29:43] Warning: work queue empty, miner is idle
[18/06/2011 01:31:13] Result: c8b213d5 accepted        
[18/06/2011 01:31:13] Result: 2dd8e44a accepted        
MSG: upstream RPC error                                
[18/06/2011 01:31:13] Disconnected from server        
[18/06/2011 01:31:23] Result: e5eb79fe accepted        
[18/06/2011 01:31:24] Result: d981469f accepted  
MSG: upstream RPC error                          
[18/06/2011 01:31:34] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:32:30] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:32:43] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:32:58] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:34:01] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:36:22] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:36:33] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:37:42] Failed to connect, retrying...
[0 Khash/sec] [1812 Accepted] [30 Rejected] [RPC]

This erro occurs with Version 1.5



I got this issue, as well as the just being stuck at 0 issue that another user mentioned, with 1.50 today.  What I did to get the Failed to connect error to stop and it to kick back into gear without restarting it was to simply load a website in Internet Explorer!

To see if it can be prevented, I've decided to run an automated ping of google.com every 10 mins, and am going to see if this prevents the problem from recurring.


Title: Hardware Watchdog Support
Post by: TeaRex on June 21, 2011, 06:12:45 PM
After losing a weekend's worth of mining when my computer locked up while I was 300km away from it, I've coded support for a QUANCOM hardware watchdog card into Phoenix. It starts the timer when Phoenix starts and re-triggers it whenever a share has been accepted by the server. If there is any prolonged problem (server unresponsive, network problem, GPU refusing to work, computer locked up...) the watchdog will short the reset switch pins on the mainboard after a few minutes and thus cause a hard reboot. Of course the miner is set to auto-start with Windows.

The patch is fairly simple and probably not as pretty as it could be (I'm entirely new to Python coding), and it would have to be modified for Linux, but it does the job for now. If anybody is interested in it please send me a message.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bongo on June 21, 2011, 09:34:50 PM
After a halt, one of my systems got this strange error when starting a miner:

File "phoenix.py", line 18
SyntaxError: Non-ASCII character '\xd4' in file phoenix.py on line 18, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

After a fresh re-install of the phoenix miner that error was gone and the miners started normally. I am running an Ubuntu 10.10 with phoenix 1.50.

 


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Okama on June 22, 2011, 07:06:58 AM
Does 1.5ver supports backup pool (--backup=...) like the newest poclbm?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Ali on June 22, 2011, 02:32:07 PM
I'm using Phoenix on OSX 10.6 . Either I'm really unlucky or it couldn't find a single share within the last 30 minutes at 60 Mhash/s. New work gets pushed though.
What could be going wrong?

Here's some output:

[22/06/2011 15:58:54] Phoenix 1.50 starting...
[22/06/2011 15:58:54] Connected to server
[22/06/2011 16:20:06] LP: New work pushed               
[22/06/2011 16:24:50] LP: New work pushed             
[22/06/2011 16:28:58] LP: New work pushed             
[22/06/2011 16:31:18] LP: New work pushed             
[57.95 Mhash/sec] [0 Accepted] [0 Rejected] [RPC (+LP)]


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: modrobert on June 22, 2011, 04:59:43 PM
Quote
[16/06/2011 20:21:48] Server gave new work; passing to WorkQueue
[16/06/2011 20:22:01] Result 000000002f4255ac... accepted
[16/06/2011 20:22:06] Result 00000000956163ae... accepted
[16/06/2011 20:22:08] Result 000000006244c69e... accepted
[16/06/2011 20:22:15] Server gave new work; passing to WorkQueue
[16/06/2011 20:22:42] Server gave new work; passing to WorkQueue
[16/06/2011 20:23:08] Result 0000000068e4507d... rejected
[16/06/2011 20:23:08] Result 00000000e2b80025... rejected
[16/06/2011 20:23:09] Server gave new work; passing to WorkQueue
[16/06/2011 20:23:10] New block (WorkQueue)
[16/06/2011 20:23:13] Result 000000003717b83f... accepted
[16/06/2011 20:23:25] Result 00000000706aa557... accepted
[16/06/2011 20:23:28] Result 00000000edf564dc... accepted
[16/06/2011 20:23:37] Warning: work queue empty, miner is idle
[0 Khash/sec] [859 Accepted] [23 Rejected] [RPC (+LP)]
v1.50
did not restart for two hours...

Seven other miner instances worked fine, one of them on the same GPU. Could it be something with the socket connection?

anything we can do to help debug?

I'm assuming you are running Linux?

Code:
$ sudo sysctl -a | grep tcp_keepalive

net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75

Those are the default kernel parameters when running Linux (Ubuntu 11.04). First one gives keeps the TCP/IP connection alive for two hours (7200 seconds) without ack (eg. if you pull the network cable), second one is how many times it will try to reconnect/probe, and third one is how many seconds it will perform each probe. Only after all this is done will the application (python binary in this case) get the socket call terminated when the TCP/IP connection is bork.

I've only had the hang you describe once so far, all other times phoenix handles this. I think it depends on how the connection is broken against the pool, and somehow bypasses the exception handling in Phyton.

Anyway, to change the kernel parameters dynamically (until next reboot) you can issue this command.

Code:
sudo sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_probes=3 net.ipv4.tcp_keepalive_intvl=10

This will give a reconnection after one minute (60 seconds), and do three probe attempts lasting 10 seconds each.

To change permanently you can edit /etc/sysctl.conf (as root) with your favorite editor and add these lines.

Code:
net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_probes=3
net.ipv4.tcp_keepalive_intvl=10

Let me know if it seems to work for you.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on June 22, 2011, 07:35:19 PM
Hey, I have a question about using multiple GPU mining.  One thing that I've noticed is that the GPU miner tends to use one CPU core per GPU.  Having OpenCL capable CPUs makes this more of a problem since the GPU miners can actually run on the CPU cores, but let's not get into that.  Anyhow, I wanted to ask if what I said is accurate as to one CPU core per GPU since I'm hoping to put together a 4x HD6990 rig and can only really find 6 core CPUs.  If it won't work, then I won't invest in the 4th and useless card.  So I need someone to fill me in before I do something stupid.

Thanks!

Edit:  I have posted this question in this thread since I will most likely be using this miner until I find that one works better than another.  So my question applies mainly to this miner.  Feel free to answer for other miner programs too if their mining methods would change the outcome of the answer.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CptHook on June 22, 2011, 07:48:50 PM
I am trying to make a slightly modified version of the phoenix miner (specifically I want to make the output stream unbuffered)

Could you guys please tell me how to properly compile the source for this? I am no good with python, and I am having trouble compiling the source into a standalone exe..
I have tried with py2exe, but the resulting exe has a lot of dependencies. My exe is 22kB while the official exe is ~6800kB
I don't expect anyone to make a tutorial, but it would be nice to be pointed in the right direction.

Thank you.

- CptHook


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on June 22, 2011, 11:28:52 PM
Hey, I have a question about using multiple GPU mining.  One thing that I've noticed is that the GPU miner tends to use one CPU core per GPU.  Having OpenCL capable CPUs makes this more of a problem since the GPU miners can actually run on the CPU cores, but let's not get into that.  Anyhow, I wanted to ask if what I said is accurate as to one CPU core per GPU since I'm hoping to put together a 4x HD6990 rig and can only really find 6 core CPUs.  If it won't work, then I won't invest in the 4th and useless card.  So I need someone to fill me in before I do something stupid.

The CPU is maxed out but it's not actually used very much by Phoenix for any real work, typically less than 2% is real use. I'm not sure what it's actually doing all the time but I guess it's constantly polling the GPU to check whether it's done with its current bit of work. In Windows, use something like

start /affinity 0x8 phoenix.exe .....

to get all your miners to run on only one CPU core (not one each, but all on one, I use CPU #3, the last one of my 4 core CPU with numbering starting at 0, hence the 8 which is 2 to the 3rd power). Then only that one core will be maxed out, without any noticeable loss in mining speed. I run the Ufasoft CPU miner on the other cores to get a bit more out of the rig.

On Linux, you can prevent the CPU hogging altogether by saying

export GPU_USE_SYNC_OBJECTS=1

before you start the miner(s).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on June 22, 2011, 11:31:32 PM
Could you guys please tell me how to properly compile the source for this? I am no good with python, and I am having trouble compiling the source into a standalone exe..
I have tried with py2exe, but the resulting exe has a lot of dependencies. My exe is 22kB while the official exe is ~6800kB
I don't expect anyone to make a tutorial, but it would be nice to be pointed in the right direction.

Do you actually need a standalone exe? Or could you live with running your modified miner on Python? If the latter, check out the "Howto run Phoenix SVN" sticky on the Bitcoinpool.com forum, board "Miner discussion".


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Mikecraft on June 23, 2011, 03:06:10 AM
Hey, I have a question about using multiple GPU mining.  One thing that I've noticed is that the GPU miner tends to use one CPU core per GPU.  Having OpenCL capable CPUs makes this more of a problem since the GPU miners can actually run on the CPU cores, but let's not get into that.  Anyhow, I wanted to ask if what I said is accurate as to one CPU core per GPU since I'm hoping to put together a 4x HD6990 rig and can only really find 6 core CPUs.  If it won't work, then I won't invest in the 4th and useless card.  So I need someone to fill me in before I do something stupid.

Thanks!

Edit:  I have posted this question in this thread since I will most likely be using this miner until I find that one works better than another.  So my question applies mainly to this miner.  Feel free to answer for other miner programs too if their mining methods would change the outcome of the answer.

I had the same issue. My guess is that you're running at a pretty high aggression. I was running at aggression 12 and getting ~13% CPU usage across all 8 cores (really 4 cores with hyperthreading). You can set the affinity so it only runs on one core, and then I got ~95% CPU usage on just that core, or you can just turn down the aggression.

It took me hours of googling before someone suggested it, but simply going to aggression 9 dropped my CPU usage to 0. My hash rate is about the same and Windows is more responsive. The only downside is that my hashrate drops ~3 MHashs/s when I do things like move windows around or use any aero features.

I'd guess that the max aggression level before you run into CPU usage issues is different for each card, but just try going lower one at a time; from 10 to 9 was like night and day for me.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cuqa on June 23, 2011, 03:43:32 AM
Sorry if this question occured earlier ITT, but what exactly is the -q parameter? How does it work?

Appreciate ur help.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on June 23, 2011, 05:52:08 AM
Sorry if this question occured earlier ITT, but what exactly is the -q parameter? How does it work?

-q tells Phoenix to keep more than one work unit in its "to-do" queue. Advantage: When the miner can't immediately get new work from the pool server, it will have something to do anyway. Disadvantage: the amount of done work that has to be discarded when a new block is found by somebody else is higher.

So you might want to experiment with slightly increasing the value above 1 especially if you're mining on a rig with very high speed per GPU core. But don't go too high or you'll lose efficiency again due to more rejected shares.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cuqa on June 23, 2011, 11:18:35 AM
Sorry if this question occured earlier ITT, but what exactly is the -q parameter? How does it work?

-q tells Phoenix to keep more than one work unit in its "to-do" queue. Advantage: When the miner can't immediately get new work from the pool server, it will have something to do anyway. Disadvantage: the amount of done work that has to be discarded when a new block is found by somebody else is higher.

So you might want to experiment with slightly increasing the value above 1 especially if you're mining on a rig with very high speed per GPU core. But don't go too high or you'll lose efficiency again due to more rejected shares.

So this setting is only for high speed GPUs?

What I find somewhat weird is that I (with my crappy 35mh/s gpu) dont seem to get new work properly. I posted my prop in another thread: http://forum.bitcoin.org/index.php?topic=21330.0

Whenever I produce a rejected result within a block, I cant submit an accepted one after that until a new Block is started. However, when I restart phoenix I can.  I dont know if this has something to do with -q, but I am testing several values atm in testnet to get some comparion.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: zimpixa on June 23, 2011, 10:26:25 PM
Does 1.5ver supports backup pool (--backup=...) like the newest poclbm?


Where did You find poclbm that supports backup pool? Please support me with link.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: BitMinerN8 on June 23, 2011, 10:58:32 PM
Does 1.5ver supports backup pool (--backup=...) like the newest poclbm?


Where did You find poclbm that supports backup pool? Please support me with link.

I have never heard of a client that supports a native mechanism of a backup pool, as in "the primary is down, use backup". I have only read and have it setup through running multiple instances with either the -f30 (primary) and -f60 (backup) for poclmb, or with the aggression=11 (primary) and aggression=5 (backup) for phoenix. (those are just example numbers, choose what works for best for your miner)

And yes, a portion of the 2nd instance will be sending shares to the backup, adjusting the -f or aggression= numbers varies that load.

If anyone knows a way to make it 100% on primary, 0% on backup, then if there is a failure make the switch to the backup I'd love to see it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: zimpixa on June 23, 2011, 11:22:31 PM
Poclbm has backup feature now. Just enter their thread, go to source and u can see there 17 june version. It just need to be compiled.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Okama on June 23, 2011, 11:40:32 PM
Does 1.5ver supports backup pool (--backup=...) like the newest poclbm?


Where did You find poclbm that supports backup pool? Please support me with link.
You can find out with ./poclbm.py --help

The usage is adding --backup=worker_name:worker_pass@hostname:port. This new feature saved me sometimes :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 24, 2011, 04:54:34 PM
Hey, I have a question about using multiple GPU mining.  One thing that I've noticed is that the GPU miner tends to use one CPU core per GPU.  Having OpenCL capable CPUs makes this more of a problem since the GPU miners can actually run on the CPU cores, but let's not get into that.  Anyhow, I wanted to ask if what I said is accurate as to one CPU core per GPU since I'm hoping to put together a 4x HD6990 rig and can only really find 6 core CPUs.  If it won't work, then I won't invest in the 4th and useless card.  So I need someone to fill me in before I do something stupid.

Thanks!

Edit:  I have posted this question in this thread since I will most likely be using this miner until I find that one works better than another.  So my question applies mainly to this miner.  Feel free to answer for other miner programs too if their mining methods would change the outcome of the answer.

Get a CPU with hyper-threading (and 6-cores) and your miners will work among 12 virtual cores.  Having said that, there is something wrong (i.e. very slow CPU, bus and memory perhaps) if your miners are maxing out a CPU core when GPU mining.  I had two cards mining in my main desktop machine [i7 960 3.2GHz quad-core with hyper-threading] and never saw any spikes on any CPU core [of all 8 virtual that show in task manager or other tool].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on June 24, 2011, 05:55:00 PM
Get a CPU with hyper-threading (and 6-cores) and your miners will work among 12 virtual cores.  Having said that, there is something wrong (i.e. very slow CPU, bus and memory perhaps) if your miners are maxing out a CPU core when GPU mining.  I had two cards mining in my main desktop machine [i7 960 3.2GHz quad-core with hyper-threading] and never saw any spikes on any CPU core [of all 8 virtual that show in task manager or other tool].

Are you mining with ATI cards Veldy? AFAIK they always max out at least one core when one mines on them on Windows. If they don't on your system, care to describe your setup for others to replicate? Thanks!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 25, 2011, 01:29:25 AM
Get a CPU with hyper-threading (and 6-cores) and your miners will work among 12 virtual cores.  Having said that, there is something wrong (i.e. very slow CPU, bus and memory perhaps) if your miners are maxing out a CPU core when GPU mining.  I had two cards mining in my main desktop machine [i7 960 3.2GHz quad-core with hyper-threading] and never saw any spikes on any CPU core [of all 8 virtual that show in task manager or other tool].

Are you mining with ATI cards Veldy? AFAIK they always max out at least one core when one mines on them on Windows. If they don't on your system, care to describe your setup for others to replicate? Thanks!

Yes. I mine only with ATI cards, 6970s and 5850s, the former for the dual-purpose use of gaming and mining and the latter strictly for mining.

Setup.  I listed most of it above.  But if you want to know what the board is, it is an ASUS Rampage III Gene with the i7 960 3.2GHz quad-core with hyper-threading and 12GB of DDR3 PC10600 tri-channel memory.  In case you wonder, the 760 is a rare CPU apparently [far more references to the 765 and 770].  I build my machines myself and don't buy DELL, HP, etc "for the masses" crap unless it is for a single purpose that requires a quick purchase [as opposed to deliberation on a good build, waiting for the order and to assemble it.  For my Wife and Daughter .. pre-built is usually fine and in fact, they prefer laptops anyway, so no choice to build really.  Oh yes, Windows 7 x64 Pro [I had ultimate on my previous computer ... what a waste of money for Ultimate, even if buying OEM; only good if you have an MSDN subscription].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 25, 2011, 01:42:38 AM
Oh yes, a nice Corsair SATA6 SSD 128MB for the OS [swap is on a fast hard disk, but it really doesn't need to swap :)].  7.6 score on Windows 7 with all at 7.9 except the processor is at 7.6 (my i7 760).  If I find that I need more processing power, this board will take much improved yet [without a board upgrade].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: btcminer on June 25, 2011, 11:23:06 AM
Is there a way to limit the amount of memory phoenix miner uses? It eventually uses up all my memory and crashes on linux.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 25, 2011, 05:08:48 PM
Is there a way to limit the amount of memory phoenix miner uses? It eventually uses up all my memory and crashes on linux.

Sounds like a python problem.  I am not seeing this on any of my machines [all Windows, since I couldn't get near the hash rates on Linux Ubuntu].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: foreshadow on June 26, 2011, 01:25:54 AM
How do I run this as command line in Linux?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 26, 2011, 01:37:00 AM
How do I run this as command line in Linux?

If you have the proper version of python installed [which presumably you do as either it was installed as a dependency or compiled as one, depending upon how you put it on your system and the distribution that you use], in the directory where they phoenix.py is located:

Quote
python ./phoenix.py

Or, presumably, the phoenix.py file is marked as executable, and if not, you can mark it that way by: chmod u+x phoenix.py

Quote
./phoenix.py

Or course, pass the command line arguments as required [if you don't know, search the forums].

Good luck.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: beeph on June 27, 2011, 06:07:12 AM
I cant get this to run on windows XP SP3, catalyst 11.6, stream SDK 2.4, radeon 5830.  CPU mining works fine but when i try to mine
with [0-0] Cypress, it says 'connected' then [0 hash/s 0 accepted 0 rejected], forever

any ideas?



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phants on June 27, 2011, 01:02:27 PM
Please add to new version - http://forum.bitcoin.org/index.php?topic=23067.0


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on June 27, 2011, 02:26:58 PM
Please add to new version - http://forum.bitcoin.org/index.php?topic=23067.0

This has been added to the SVN, and it will be released with a new version shortly. In the mean time, it is possible to edit kernel.cl and apply this change even with the compiled version.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 28, 2011, 06:00:08 AM
Please add to new version - http://forum.bitcoin.org/index.php?topic=23067.0

This has been added to the SVN, and it will be released with a new version shortly. In the mean time, it is possible to edit kernel.cl and apply this change even with the compiled version.

FWIW, I am finding that Phoenix 1.5 [with optimization in both kernels] runs faster using the poclbm kernel than the phatk kernel on my 6970.  Just barely.  I don't know if this will reflect in reduced stales or not. 

1128 (0.35%)   Prop.  6970
894 (0.11%)   Prop.  5850
934 (0.00%)   Prop.  5850

Note that before the change, I was using the POCLBM miner itself for my 6970 and I usually get 0.25-0.40% with Deepbit, but when I used Phoenix 1.5 (poclbm ... phatk I never tried with 1.5 since it was always considerable slower in previous Phoenix versions), I saw slower rates [similar to the POCLBM miner], but high stale rates [over 1.0-1.5%].  All based on a stable Deepbit :)  The other miners, the 5850s, always used Phoenix with the phatk kernel [and thus used 1.5 since I learned of it several days ago] and I was seeing somewhere in the realm of 0.6-1.0% IIRC.  So, this fix has obviously affected stale rates.  Having said that, running with the poclbm kernel on my 6970 for just a few minutes has already resulted in a valid stale [not the local stale I reported earlier].  I will continue to run the phatk kernel I think, but for some, the poclbm kernel should still be considered on the 69xx series ... I may make some test runs myself, but first, I need to vet phatk and phoenix 1.5 (patched) against more hostile "environments" :)

Rock and roll!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: qed on June 28, 2011, 07:11:16 AM
I have some 6950 and i manually changed the kernel line. Miners are actually faster and my stale rate _is_ normal (0.3% - 0.6% after 8h).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TurdHurdur on June 28, 2011, 08:14:37 PM
Is there a way to limit the amount of memory phoenix miner uses? It eventually uses up all my memory and crashes on linux.
I use a crontab to restart instances daily. The script in my sig, Automatically Identify Disconnection and Switch(.pl) pools (https://forum.bitcoin.org/index.php?topic=21649.0), also restarts on various issues.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on June 29, 2011, 12:31:32 PM
I am trying to figure out the idle bug / help figure it out. I have phoenix running from source.

added some log commands:

Code:
Miner.py:
    def idleFixer(self):
        self.logger.log("idleFixer: called")
        if self.idle:
            self.logger.log("idleFixer: requesting")
            self.connection.requestWork()
            reactor.callLater(15, self.idleFixer)
        self.logger.log("idleFixer: done")

RPCProtocol.py:
        def idleFix(x):
            print "idleFix: called"
            try:
                x.errback(failure.Failure())
                print "idleFix: success"
            except:
                print "idleFix: exception"



output when the bug hits me:
Code:
[29/06/2011 14:08:58] Server gave new work; passing to WorkQueue
[29/06/2011 14:09:13] Result 00000000ad90ac5c... accepted
[184.40 Mhash/sec] [666 Accepted] [32 Rejected] [RPC (+LP)]idleFix: called
idleFix: exception
[29/06/2011 14:09:31] Server gave new work; passing to WorkQueue
[29/06/2011 14:09:33] Result 00000000006b901a... accepted
[29/06/2011 14:09:36] Result 000000001ad89774... accepted
[184.66 Mhash/sec] [668 Accepted] [32 Rejected] [RPC (+LP)]idleFix: called
idleFix: exception
[29/06/2011 14:09:48] Server gave new work; passing to WorkQueue
[185.83 Mhash/sec] [668 Accepted] [32 Rejected] [RPC (+LP)]idleFix: called
idleFix: exception
[29/06/2011 14:10:09] Result 00000000050217c6... accepted
[29/06/2011 14:10:16] Server gave new work; passing to WorkQueue
[29/06/2011 14:10:34] Result 00000000e54ba30b... accepted
[186.39 Mhash/sec] [670 Accepted] [32 Rejected] [RPC (+LP)]idleFix: called
idleFix: exception
[29/06/2011 14:10:43] Server gave new work; passing to WorkQueue
[186.41 Mhash/sec] [670 Accepted] [32 Rejected] [RPC (+LP)]idleFix: called
idleFix: exception
[29/06/2011 14:11:03] Result 00000000a5b52411... accepted
[29/06/2011 14:11:12] Result 00000000c4513815... accepted
[29/06/2011 14:11:13] Server gave new work; passing to WorkQueue
[185.79 Mhash/sec] [672 Accepted] [32 Rejected] [RPC (+LP)]idleFix: called
idleFix: exception
[182.06 Mhash/sec] [672 Accepted] [32 Rejected] [RPC (+LP)]idleFix: called
idleFix: exception
[29/06/2011 14:11:56] Disconnected from server
[180.81 Mhash/sec] [672 Accepted] [32 Rejected] [RPC]idleFix: called
idleFix: exception
[29/06/2011 14:12:24] Warning: work queue empty, miner is idle
[29/06/2011 14:12:24] idleFixer: called
[29/06/2011 14:12:24] idleFixer: requesting
[29/06/2011 14:12:24] idleFixer: done
[29/06/2011 14:12:24] Failed to connect, retrying...
[29/06/2011 14:12:39] idleFixer: called
[29/06/2011 14:12:39] idleFixer: requesting
[29/06/2011 14:12:39] idleFixer: done
[0 Khash/sec] [672 Accepted] [32 Rejected] [RPC]idleFix: called
idleFix: exception
[29/06/2011 14:12:54] idleFixer: called
[29/06/2011 14:12:55] idleFixer: requesting
[29/06/2011 14:12:55] idleFixer: done
[29/06/2011 14:13:10] idleFixer: called
[29/06/2011 14:13:10] idleFixer: requesting
[29/06/2011 14:13:10] idleFixer: done
[29/06/2011 14:13:15] Failed to connect, retrying...
[29/06/2011 14:13:25] idleFixer: called
[29/06/2011 14:13:25] idleFixer: requesting
[29/06/2011 14:13:25] idleFixer: done
[0 Khash/sec] [672 Accepted] [32 Rejected] [RPC]idleFix: called
idleFix: exception
[29/06/2011 14:13:40] idleFixer: called
[29/06/2011 14:13:40] idleFixer: requesting
[29/06/2011 14:13:40] idleFixer: done
[29/06/2011 14:13:55] idleFixer: called
[29/06/2011 14:13:55] idleFixer: requesting
[29/06/2011 14:13:55] idleFixer: done
[29/06/2011 14:14:10] idleFixer: called
[29/06/2011 14:14:13] idleFixer: requesting
[29/06/2011 14:14:13] idleFixer: done
[29/06/2011 14:14:28] idleFixer: called
[29/06/2011 14:14:28] idleFixer: requesting
[29/06/2011 14:14:28] idleFixer: done
[29/06/2011 14:14:43] idleFixer: called
[29/06/2011 14:14:43] idleFixer: requesting
[29/06/2011 14:14:43] idleFixer: done
[29/06/2011 14:14:58] idleFixer: called
[29/06/2011 14:14:59] idleFixer: requesting
[29/06/2011 14:14:59] idleFixer: done
[29/06/2011 14:15:14] idleFixer: called
[29/06/2011 14:15:14] idleFixer: requesting
[29/06/2011 14:15:14] idleFixer: done
[29/06/2011 14:15:29] idleFixer: called
[29/06/2011 14:15:29] idleFixer: requesting
[29/06/2011 14:15:29] idleFixer: done
[29/06/2011 14:15:44] idleFixer: called
[29/06/2011 14:15:44] idleFixer: requesting
[29/06/2011 14:15:44] idleFixer: done
[29/06/2011 14:15:59] idleFixer: called
[29/06/2011 14:15:59] idleFixer: requesting
[29/06/2011 14:15:59] idleFixer: done
[29/06/2011 14:16:14] idleFixer: called
[29/06/2011 14:16:14] idleFixer: requesting
[29/06/2011 14:16:14] idleFixer: done
[29/06/2011 14:16:29] idleFixer: called
[29/06/2011 14:16:29] idleFixer: requesting
[29/06/2011 14:16:29] idleFixer: done
[29/06/2011 14:16:44] idleFixer: called
[29/06/2011 14:16:44] idleFixer: requesting
[29/06/2011 14:16:44] idleFixer: done
[29/06/2011 14:16:59] idleFixer: called
[29/06/2011 14:16:59] idleFixer: requesting
[29/06/2011 14:16:59] idleFixer: done
[29/06/2011 14:17:14] idleFixer: called
[29/06/2011 14:17:14] idleFixer: requesting
[29/06/2011 14:17:14] idleFixer: done
[29/06/2011 14:17:29] idleFixer: called
[29/06/2011 14:17:29] idleFixer: requesting
[29/06/2011 14:17:29] idleFixer: done
[29/06/2011 14:17:44] idleFixer: called
[29/06/2011 14:17:44] idleFixer: requesting
[29/06/2011 14:17:44] idleFixer: done
[29/06/2011 14:17:59] idleFixer: called
[29/06/2011 14:18:00] idleFixer: requesting
[29/06/2011 14:18:00] idleFixer: done
[29/06/2011 14:18:15] idleFixer: called
[29/06/2011 14:18:15] idleFixer: requesting
[29/06/2011 14:18:15] idleFixer: done
[29/06/2011 14:18:30] idleFixer: called
[29/06/2011 14:18:30] idleFixer: requesting
[29/06/2011 14:18:30] idleFixer: done
[29/06/2011 14:18:45] idleFixer: called
[29/06/2011 14:18:45] idleFixer: requesting
[29/06/2011 14:18:45] idleFixer: done
[29/06/2011 14:19:00] idleFixer: called
[29/06/2011 14:19:00] idleFixer: requesting
[29/06/2011 14:19:00] idleFixer: done
[29/06/2011 14:19:16] idleFixer: called
[29/06/2011 14:19:16] idleFixer: requesting
[29/06/2011 14:19:16] idleFixer: done
[29/06/2011 14:19:31] idleFixer: called
[29/06/2011 14:19:31] idleFixer: requesting
[29/06/2011 14:19:31] idleFixer: done
[0 Khash/sec] [672 Accepted] [32 Rejected] [RPC]

what does that tell me? idleFixer is being called after the problem occurs but does not help. idleFix is not being called.

any suggestions for debugging? are there any RPC status infos that I could have it spit out?





Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on June 29, 2011, 03:26:58 PM
I am trying to figure out the idle bug / help figure it out. I have phoenix running from source.

added some log commands:

what does that tell me? idleFixer is being called after the problem occurs but does not help. idleFix is not being called.

any suggestions for debugging? are there any RPC status infos that I could have it spit out?


The code you modified was my last ditch effort to create a workaround for the idle problem. As you can see, it didn't work. I have given up on the current RPCProtocol design because it doesn't work, and without the original developer present I can't seem to fix it. Personally I think the issue lies somewhere in the modification to the Twisted.web library to enable persistent connections.

I am working on a complete rewrite for RPCProtocol, but I'm not exactly an expert on netcode so it's taking a bit of time. Expect a release sometime in the next 2 weeks.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on June 29, 2011, 08:26:36 PM
I am trying to figure out the idle bug / help figure it out. I have phoenix running from source.

added some log commands:

what does that tell me? idleFixer is being called after the problem occurs but does not help. idleFix is not being called.

any suggestions for debugging? are there any RPC status infos that I could have it spit out?


The code you modified was my last ditch effort to create a workaround for the idle problem. As you can see, it didn't work. I have given up on the current RPCProtocol design because it doesn't work, and without the original developer present I can't seem to fix it. Personally I think the issue lies somewhere in the modification to the Twisted.web library to enable persistent connections.

I am working on a complete rewrite for RPCProtocol, but I'm not exactly an expert on netcode so it's taking a bit of time. Expect a release sometime in the next 2 weeks.
sweet. will be happy to test.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Lightspeed on June 30, 2011, 12:36:51 PM
hello

I just installed phoneix 1.5 on ubuntu 11.04

but when I run it CPU usage spikes and lags the shit out of the computer, its got an athlon X4 in it, and does it with just one 5850 mining;

I think SDK 2.1 is installed

do I need to install 2.4 ? if so is anyone able to tell me how to do this? otherwise what is the problem? here is the command I was using to start it:

./phoenix.py -u http://ABC.XYZ:123@ozco.in:8332/ -k phatk DEVICE=1 VECTORS AGGRESSION=11 BFI_INT FASTLOOP=FALSE WORKSIZE=128

I could really use the help... please please please

thanks guys

t


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: DarkMatter on June 30, 2011, 01:31:17 PM
hello

I just installed phoneix 1.5 on ubuntu 11.04

but when I run it CPU usage spikes and lags the shit out of the computer, its got an athlon X4 in it, and does it with just one 5850 mining;

I think SDK 2.1 is installed

do I need to install 2.4 ? if so is anyone able to tell me how to do this? otherwise what is the problem? here is the command I was using to start it:

./phoenix.py -u http://ABC.XYZ:123@ozco.in:8332/ -k phatk DEVICE=1 VECTORS AGGRESSION=11 BFI_INT FASTLOOP=FALSE WORKSIZE=128

I could really use the help... please please please

thanks guys

t

Lower your aggression value to 5 or 6 and you should be able to use it while mining.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 30, 2011, 02:45:25 PM
hello

I just installed phoneix 1.5 on ubuntu 11.04

but when I run it CPU usage spikes and lags the shit out of the computer, its got an athlon X4 in it, and does it with just one 5850 mining;

I think SDK 2.1 is installed

do I need to install 2.4 ? if so is anyone able to tell me how to do this? otherwise what is the problem? here is the command I was using to start it:

./phoenix.py -u http://ABC.XYZ:123@ozco.in:8332/ -k phatk DEVICE=1 VECTORS AGGRESSION=11 BFI_INT FASTLOOP=FALSE WORKSIZE=128

I could really use the help... please please please

thanks guys

t

Lower your aggression value to 5 or 6 and you should be able to use it while mining.

Even aggression of 9 should be fine (it is with my i7 960 with Aero on), but you want FASTLOOP (or FASTLOOP=true).


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: DarkMatter on June 30, 2011, 05:36:37 PM
hello

I just installed phoneix 1.5 on ubuntu 11.04

but when I run it CPU usage spikes and lags the shit out of the computer, its got an athlon X4 in it, and does it with just one 5850 mining;

I think SDK 2.1 is installed

do I need to install 2.4 ? if so is anyone able to tell me how to do this? otherwise what is the problem? here is the command I was using to start it:

./phoenix.py -u http://ABC.XYZ:123@ozco.in:8332/ -k phatk DEVICE=1 VECTORS AGGRESSION=11 BFI_INT FASTLOOP=FALSE WORKSIZE=128

I could really use the help... please please please

thanks guys

t

Lower your aggression value to 5 or 6 and you should be able to use it while mining.

Even aggression of 9 should be fine (it is with my i7 960 with Aero on), but you want FASTLOOP (or FASTLOOP=true).

I see a strong Mhash/s drop using fastloop (Q9650 + Ati 5770, sdk 2.4 + drivers 11.5)  so i always use it off.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: sang on June 30, 2011, 06:45:10 PM
On both of my mining machines it appears that after 12+hrs the miners slow down by 5-10%. You can see this represented in the MSI Afterburner GPU Usage % graphs here: http://imgur.com/RCMZ4 The very spikey GPU usage on the left is when i logged into my machine after it was running for 20hrs and on the right was after I restarted the miner clients.

This has been happening for weeks, I restart my miners every day because of it. Any idea what the cause is? It is going from a constant 98-100% GPU usage to 89-100% gpu usage spikes.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: fxgmblr on June 30, 2011, 09:15:12 PM
any ideas to reach 300+Mhash/sec on a 6870 using Phoenix 1.5?

running stock voltages and clock speeds I'm only getting 265Mhash/sec
any way to get that up to 300 w/o overclocking? (don't want to shorten the life of the card)
if not, then what should i overclock/underclock to hit 300Mhash/sec?

rig specs:
Ubuntu 11.04
2x HIS PCI-Express ATI Radeon HD6870 Video Card (Engine Clock: 900 MHz; Video Memory: 1GB DDR5; Memory Clock: 4.2 GHz; RAMDAC: 400 MHz)
AMD Sempron 140, Socket AM3, 2.7 GHz, 1 MB Cache, 45 Watts
ASRock AM3 processors AMD 770-140W 4DDR3/ATI CrossFireX motherboard
Seagate Barracuda 7200.12 500 GB 7200RPM SATA 6Gb/s with NCQ 16MB Cache
Kingston ValueRAM 2 GB 1333MHz PC3-10600 DDR3 DIMM Desktop Memory
Thermaltake V3 Black Edition SECC / Plastic ATX Mid Tower Computer Case
Antec EA-650 Green ATX Energy Star Certified Power Supply


running:
python phoenix.py -u http://user:pass@server:8832 -k phatk VECTORS BFI_INT AGGRESSION=12 DEVICE=0

thanks in advanced!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on June 30, 2011, 09:43:53 PM
hello

I just installed phoneix 1.5 on ubuntu 11.04

but when I run it CPU usage spikes and lags the shit out of the computer, its got an athlon X4 in it, and does it with just one 5850 mining;

I think SDK 2.1 is installed

do I need to install 2.4 ? if so is anyone able to tell me how to do this? otherwise what is the problem? here is the command I was using to start it:

./phoenix.py -u http://ABC.XYZ:123@ozco.in:8332/ -k phatk DEVICE=1 VECTORS AGGRESSION=11 BFI_INT FASTLOOP=FALSE WORKSIZE=128

I could really use the help... please please please

thanks guys

t

Lower your aggression value to 5 or 6 and you should be able to use it while mining.

Even aggression of 9 should be fine (it is with my i7 960 with Aero on), but you want FASTLOOP (or FASTLOOP=true).

I see a strong Mhash/s drop using fastloop (Q9650 + Ati 5770, sdk 2.4 + drivers 11.5)  so i always use it off.

You shouldn't at low aggression levels (9 or below).  It will drop while you are using the machine however [which is what it is for, to help reduce lag].  FASTLOOP is neutral at best and detrimental in practice at aggression levels higher than 9 (older versions of Phoenix it was patently obvious).

In fact, I just shut my miner off, set FASTLOOP=false and restarted it and my hash rate dropped about 5MH/s (it varies a little obviously).  I turned it back on and the rate is back where it should be.  Here is what I use with my 6970 930MHz core clock with all else at stock.  This machine is my Windows 7 x64 Pro with Catalyst 11.6 drivers installed.  I use this machine all day for work (VPN with Remote Desktop) and run many services for development purposes as well as iTunes going and Aero on.

Quote
-k phatk VECTORS BFI_INT FASTLOOP WORKSIZE=128 AGGRESSION=9



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Lightspeed on June 30, 2011, 09:59:31 PM
hello

I just installed phoneix 1.5 on ubuntu 11.04

but when I run it CPU usage spikes and lags the shit out of the computer, its got an athlon X4 in it, and does it with just one 5850 mining;

I think SDK 2.1 is installed

do I need to install 2.4 ? if so is anyone able to tell me how to do this? otherwise what is the problem? here is the command I was using to start it:

./phoenix.py -u http://ABC.XYZ:123@ozco.in:8332/ -k phatk DEVICE=1 VECTORS AGGRESSION=11 BFI_INT FASTLOOP=FALSE WORKSIZE=128

I could really use the help... please please please

thanks guys

t

Lower your aggression value to 5 or 6 and you should be able to use it while mining.

Even aggression of 9 should be fine (it is with my i7 960 with Aero on), but you want FASTLOOP (or FASTLOOP=true).

I see a strong Mhash/s drop using fastloop (Q9650 + Ati 5770, sdk 2.4 + drivers 11.5)  so i always use it off.

You shouldn't at low aggression levels (9 or below).  It will drop while you are using the machine however [which is what it is for, to help reduce lag].  FASTLOOP is neutral at best and detrimental in practice at aggression levels higher than 9 (older versions of Phoenix it was patently obvious).

In fact, I just shut my miner off, set FASTLOOP=false and restarted it and my hash rate dropped about 5MH/s (it varies a little obviously).  I turned it back on and the rate is back where it should be.  Here is what I use with my 6970 930MHz core clock with all else at stock.  This machine is my Windows 7 x64 Pro with Catalyst 11.6 drivers installed.  I use this machine all day for work (VPN with Remote Desktop) and run many services for development purposes as well as iTunes going and Aero on.

Quote
-k phatk VECTORS BFI_INT FASTLOOP WORKSIZE=128 AGGRESSION=9



thanks everyone for your help my cards are now performing the same as my win 7 box woot

ill test fastloop now; i couldn't see any real difference with it on or off

anyway thanks again


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: fxgmblr on June 30, 2011, 10:22:31 PM
hello

I just installed phoneix 1.5 on ubuntu 11.04

but when I run it CPU usage spikes and lags the shit out of the computer, its got an athlon X4 in it, and does it with just one 5850 mining;

I think SDK 2.1 is installed

do I need to install 2.4 ? if so is anyone able to tell me how to do this? otherwise what is the problem? here is the command I was using to start it:

./phoenix.py -u http://ABC.XYZ:123@ozco.in:8332/ -k phatk DEVICE=1 VECTORS AGGRESSION=11 BFI_INT FASTLOOP=FALSE WORKSIZE=128

I could really use the help... please please please

thanks guys

t

Lower your aggression value to 5 or 6 and you should be able to use it while mining.

Even aggression of 9 should be fine (it is with my i7 960 with Aero on), but you want FASTLOOP (or FASTLOOP=true).

I see a strong Mhash/s drop using fastloop (Q9650 + Ati 5770, sdk 2.4 + drivers 11.5)  so i always use it off.

You shouldn't at low aggression levels (9 or below).  It will drop while you are using the machine however [which is what it is for, to help reduce lag].  FASTLOOP is neutral at best and detrimental in practice at aggression levels higher than 9 (older versions of Phoenix it was patently obvious).

In fact, I just shut my miner off, set FASTLOOP=false and restarted it and my hash rate dropped about 5MH/s (it varies a little obviously).  I turned it back on and the rate is back where it should be.  Here is what I use with my 6970 930MHz core clock with all else at stock.  This machine is my Windows 7 x64 Pro with Catalyst 11.6 drivers installed.  I use this machine all day for work (VPN with Remote Desktop) and run many services for development purposes as well as iTunes going and Aero on.

Quote
-k phatk VECTORS BFI_INT FASTLOOP WORKSIZE=128 AGGRESSION=9



thanks everyone for your help my cards are now performing the same as my win 7 box woot

ill test fastloop now; i couldn't see any real difference with it on or off

anyway thanks again

so do you find your hashing rate differences negligible between linux and win7?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: brunoshady on July 01, 2011, 12:27:37 AM
just installed phoenix on ubuntu 11, but when I try to run, I get something like "cant find kernel" or something like that... what is wrong?


same thing with poclbm kernel...

and the files seems to be correct...

pyrhon.py
kernels/phatk/...
kernels/poclbm/...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bboques on July 01, 2011, 02:06:23 AM
I had a computer shop build me a cheap $600 build around a ATI 5830 and just installed Ubuntu via USB, this computer does not have internet so everything is going on through USB.

If someone can be there as a sounding board for my issues I'd really appreciate it and I''ll give everything I have generated in Bitcoinplus.com over the last week. BTC0.01.

I put the file bitcoin-0.3.23-linux.tar.gz onto the USB, and see it in ubuntu when I plug it in. What are the next steps to take? Double clicking and Extracting are not getting it running.  Is it because I'm using the Natty version of Ubuntu and they aren't compatible? I may miss your response so if you try to help please PM me with a link to your post and if it gets me there I'll send it over.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on July 01, 2011, 02:21:58 AM
hello

I just installed phoneix 1.5 on ubuntu 11.04

but when I run it CPU usage spikes and lags the shit out of the computer, its got an athlon X4 in it, and does it with just one 5850 mining;

I think SDK 2.1 is installed

do I need to install 2.4 ? if so is anyone able to tell me how to do this? otherwise what is the problem? here is the command I was using to start it:

./phoenix.py -u http://ABC.XYZ:123@ozco.in:8332/ -k phatk DEVICE=1 VECTORS AGGRESSION=11 BFI_INT FASTLOOP=FALSE WORKSIZE=128

I could really use the help... please please please

thanks guys

Lower your aggression value to 5 or 6 and you should be able to use it while mining.

Even aggression of 9 should be fine (it is with my i7 960 with Aero on), but you want FASTLOOP (or FASTLOOP=true).

I see a strong Mhash/s drop using fastloop (Q9650 + Ati 5770, sdk 2.4 + drivers 11.5)  so i always use it off.

You shouldn't at low aggression levels (9 or below).  It will drop while you are using the machine however [which is what it is for, to help reduce lag].  FASTLOOP is neutral at best and detrimental in practice at aggression levels higher than 9 (older versions of Phoenix it was patently obvious).

In fact, I just shut my miner off, set FASTLOOP=false and restarted it and my hash rate dropped about 5MH/s (it varies a little obviously).  I turned it back on and the rate is back where it should be.  Here is what I use with my 6970 930MHz core clock with all else at stock.  This machine is my Windows 7 x64 Pro with Catalyst 11.6 drivers installed.  I use this machine all day for work (VPN with Remote Desktop) and run many services for development purposes as well as iTunes going and Aero on.

Quote
-k phatk VECTORS BFI_INT FASTLOOP WORKSIZE=128 AGGRESSION=9


thanks everyone for your help my cards are now performing the same as my win 7 box woot

ill test fastloop now; i couldn't see any real difference with it on or off

anyway thanks again

I believe that I saw you were using AGGRESSION=11, correct?  Phoenix 1.50 (maybe a little bit earlier even) modified things enough that FASTLOOP essentially has no impact beyond a certain aggression; I believe > 9.  I do know that FASTLOOP is now on by default, so passing FASTLOOP or FASTLOOP=yes is redundant (I still have FASTLOOP in my options for my workstation).  So, that would explain why you didn't notice a difference.  If you are using the machine as dual use, I would recommend a maximum of AGGRESSION=9 and leave FASTLOOP on.  You can always restart the miner to the more aggressive settings when you aren't using it.  I use this for my 5850s and probably should have this as an option for my workstation while running overnight.

Quote
-k phatk VECTORS BFI_INT WORKSIZE=128 FASTLOOP=false AGGRESSION=12

Sorry for quoting all that, but I think it is needed in context (the initial question with options for instance) and since the model here is "forum in a single thread", it isn't easy to view the topic in a threaded manner.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on July 01, 2011, 02:37:17 AM
just installed phoenix on ubuntu 11, but when I try to run, I get something like "cant find kernel" or something like that... what is wrong?


same thing with poclbm kernel...

and the files seems to be correct...

pyrhon.py
kernels/phatk/...
kernels/poclbm/...

Change to the directory where phoenix.py is located and then execute.   It uses the current working directory as reference to find the kernels and should probably look in the directory where phoenix.py resides.  Since most people use a script to launch their console miners anyway, it is not really an issue to just add the directory change into it.  On Linux, many people launch it and use screen to detach it from the console allowing them to remotely access it at any time [via a shell, such as SSH or telnet into the machine]. 

FWIW, I have found Linux performed far worse than with Windows.  I used the latest Ubuntu at the time [3 weeks ago perhaps].  Finally put my old Vista Ultimate x64 on there [OEM, registered on a computer I built but died a terrible death ... some short between the board, case and power supply and lost a second power supply to it when I replaced it not thinking that I should have checked for a short first], and it activated fine.  I could have called Microsoft and I am sure they would have allowed me to activate it considering the original computer was recycled, but I didn't have too.  I think the difference for me was a solid 20%.  Modifying clock, fan, and other settings is mildly annoying as well since you have to restart X each time [well, at least for the clock settings].  I have read about a lot of posts that show people getting great hash rates on their Linux boxes though, roughly equal to Windows x64 (not sure about x86), so either there was more I could have done, or my hardware config was not optimal under Linux [auto-configure with Ubuntu perhaps did me an injustice that Windows did apparently correctly].

Linux -vs- Windows hash rate performance?  My experience says Windows, but by posts that I have read, I would say about equal and if what a few said are true, maybe a little better on Linux.  Tough to beat the cost of Linux through [I have been an avid Linux and FreeBSD user since Dec 1996 with the last 6 months being the first time I do not run a server based on one of these two in the home ... although my phone and my Tivo run Linux :)].


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: slippyrocks on July 01, 2011, 01:47:40 PM
Phoenix goes a lot faster when you use this fix.

http://forum.bitcoin.org/index.php?topic=23067.0

HD 6950 @ 890 || 360MH/s

Already been added to the latest poclbm.

And thanks OP works cherry in Win7 is PnP.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: brunoshady on July 01, 2011, 01:55:52 PM
just installed phoenix on ubuntu 11, but when I try to run, I get something like "cant find kernel" or something like that... what is wrong?


same thing with poclbm kernel...

and the files seems to be correct...

pyrhon.py
kernels/phatk/...
kernels/poclbm/...

Change to the directory where phoenix.py is located and then execute.   It uses the current working directory as reference to find the kernels and should probably look in the directory where phoenix.py resides.  Since most people use a script to launch their console miners anyway, it is not really an issue to just add the directory change into it.  On Linux, many people launch it and use screen to detach it from the console allowing them to remotely access it at any time [via a shell, such as SSH or telnet into the machine]. 

no success here...

the error is "Could not locate the specified kernel!"

I've copied and pasted the kernels files in the same root folder, the kernels folders in the root folder, but no success...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: CNMOH on July 01, 2011, 04:03:16 PM
Make sure you apply this fix if you haven't already:

http://forum.bitcoin.org/index.php?topic=23067.0

6% performance increase for me :D


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on July 01, 2011, 09:36:17 PM
Make sure you apply this fix if you haven't already:

http://forum.bitcoin.org/index.php?topic=23067.0

6% performance increase for me :D

This has been on the SVN since Monday, and since kernels are not part of the compiled binary I'm not planning another release until I finish the RPC re-write.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on July 02, 2011, 04:27:01 AM
Make sure you apply this fix if you haven't already:

http://forum.bitcoin.org/index.php?topic=23067.0

6% performance increase for me :D

Mathematically, it can only be about 3% [although ever so slight variation due to quantum effects, meaning you submit single shares, not partial shares, so there is variation in any given analysis window and also a change in the amount of work dumped or lost as stale when a block changes (the faster the miner, the less stale in a perfect world I think)].

The reason that it has to be about 3% is it was a rearrangement such that fewer computations on the GPU needed to be performed for a given unit of work ... so the performance increase is actually fixed.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on July 02, 2011, 04:30:32 AM
Make sure you apply this fix if you haven't already:

http://forum.bitcoin.org/index.php?topic=23067.0

6% performance increase for me :D

This has been on the SVN since Monday, and since kernels are not part of the compiled binary I'm not planning another release until I finish the RPC re-write.

Have you considered branching your releases?  I, for one am always hesitant to run live with HEAD (or TIP, or whatever people refer to it as) code.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: phelix on July 02, 2011, 08:16:31 AM
finally the idle bug seems to be gone for good. not sure wha it was in the end.  =)

v1.50

changes:
windows update (xp);
installation of some modules and dlls to get phoenix running from source (though now it is not)
- pyopencl
- boost
- twisted
- zope
- to system 32
  - general dlls (from vc 9)
    - msvcp90.dll
    - msvcr90.dll
  - a bunch of 24 boost dlls

?

---------edit----------------------------
once again that was a false alarm. will not says anything about this any more. got one more idle stall. the last always happened on deepbit.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Jazkal on July 02, 2011, 06:37:20 PM
WinXp x64
HD 6970

Was getting 420 Mh/s, but with the new version, I can't get over 405 Mh/s.

command line used:
WORKSIZE=128 BFI_INT AGGRESSION=11 VECTORS

What do I need to change to get back the missing speed?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on July 02, 2011, 09:13:17 PM
WinXp x64
HD 6970

Was getting 420 Mh/s, but with the new version, I can't get over 405 Mh/s.

command line used:
WORKSIZE=128 BFI_INT AGGRESSION=11 VECTORS

What do I need to change to get back the missing speed?

+1 same here in Ubuntu 11.04.
It very strange that while running smartcoin with phoenix as miner gives 427+ Mhash/s , but when run standalone phoenix gives only 404 Mhash/s


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Veldy on July 02, 2011, 09:28:19 PM
WinXp x64
HD 6970

Was getting 420 Mh/s, but with the new version, I can't get over 405 Mh/s.

command line used:
WORKSIZE=128 BFI_INT AGGRESSION=11 VECTORS

What do I need to change to get back the missing speed?

Are you sure that you were actually getting that speed?  Meaning, were you producing more stales?  Phoenix was rumored to be showing artificially high hash rates, although I cannot confirm this personally.

EDIT:  Add FASTLOOP=false

Fastloop is on by default and while it is not supposed to affect higher aggression levels like it used to, it is better safe than sorry.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Jazkal on July 02, 2011, 09:41:32 PM
Add FASTLOOP=false

Fastloop is on by default and while it is not supposed to affect higher aggression levels like it used to, it is better safe than sorry.
That fixed it for me. Thanks.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on July 03, 2011, 04:40:21 AM
WinXp x64
HD 6970

Was getting 420 Mh/s, but with the new version, I can't get over 405 Mh/s.

command line used:
WORKSIZE=128 BFI_INT AGGRESSION=11 VECTORS

What do I need to change to get back the missing speed?

Are you sure that you were actually getting that speed?  Meaning, were you producing more stales?  Phoenix was rumored to be showing artificially high hash rates, although I cannot confirm this personally.

EDIT:  Add FASTLOOP=false

Fastloop is on by default and while it is not supposed to affect higher aggression levels like it used to, it is better safe than sorry.

No change


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Sukrim on July 05, 2011, 11:11:53 PM
A possible bug/error (at least it looks to me on being at least partially on your end):

I played a bit with writing my own pool backend and phoenix currently throws the following error when connecting to my local "pool" (on Windows):

Code:
[0 Khash/sec] [0 Accepted] [0 Rejected]Unhandled Error
Traceback (most recent call last):
  File "twisted\internet\tcp.pyc", line 529, in connectionLost

  File "minerutil\_newclient3420.pyc", line 826, in dispatcher

  File "minerutil\_newclient3420.pyc", line 1438, in _connectionLost_WAITING

  File "minerutil\_newclient3420.pyc", line 1367, in _disconnectParser

--- <exception caught here> ---
  File "minerutil\_newclient3420.pyc", line 494, in connectionLost

  File "twisted\web\http.pyc", line 1366, in noMoreData

  File "minerutil\_newclient3420.pyc", line 409, in _finished

  File "minerutil\_newclient3420.pyc", line 1346, in _finishResponse

[b]exceptions.UnboundLocalError: local variable 'reason' referenced before assignme
nt[/b]
Looks like this variable is really not there, at least when phoenix gets one of the weird getworks from my <100 lines "pool server".
If needed for debugging I can also share that code so you can test it better.

Edit:
poclbm seems to get shares fine, so either they are less picky in accepting shares or there's an error on your side (I guess the former...)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: r4in on July 07, 2011, 06:36:00 PM
Hi all,

I have found a serious bug in phoenix that I can reproduce with 2 different mining pcs i have:

When the pool server is down and phoenix tries to reconnect a few times phoenix.exe will crash and the whole pc dies shortly after (=freeze, no bsod etc however)

Im using standard catalyst 2.4 and no overclocking at all (4x 6870 @ 900/500)

Thanks alot :)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: gellimac on July 07, 2011, 08:26:17 PM
hi

I use phoenix through GUIMiner (when I use phoenix in CMD it told me couldn't find kernel) but when I use phoenix it often disconnect for no reson and reconnect later.
I run this option on 5850 on windows 7 64 bit : -v -k phatk VECTORS BFI_INT AGGRESSION=13 FASTLOOP=false WORKSIZE=256

Do you know what's wrong?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: shivansps on July 08, 2011, 08:23:37 AM
i just did an small mod to the phoenix code, to export the hashrate to a plain text file... i did it to make remote monitoring easier.

phoenix.py
Code:
#!/usr/bin/python

# Copyright (C) 2011 by jedi95 <jedi95@gmail.com> and
#                       CFSworks <CFSworks@gmail.com>
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
# THE SOFTWARE.

import imp
from sys import exit
from twisted.internet import reactor
from optparse import OptionParser

import minerutil
from ConsoleLogger import ConsoleLogger
from WorkQueue import WorkQueue
from Miner import Miner

class CommandLineOptions(object):
    """Implements the Options interface for user-specified command-line
    arguments.
    """

    def __init__(self):
        self.parsedSettings = None
        self.url = None

        self.logger = None
        self.connection = None
        self.kernel = None
        self.queue = None
        self.logtotext = None

        self.kernelOptions = {}

        self._parse()

    def _parse(self):
        parser = OptionParser(usage="%prog -u URL [-k kernel] [kernel params]")
        parser.add_option("-v", "--verbose", action="store_true",
            dest="verbose", default=False, help="show debug messages")
        parser.add_option("-k", "--kernel", dest="kernel", default="poclbm",
            help="the name of the kernel to use")
        parser.add_option("-u", "--url", dest="url", default=None,
            help="the URL of the mining server to work for [REQUIRED]")
        parser.add_option("-q", "--queuesize", dest="queuesize", type="int",
            default=1, help="how many work units to keep queued at all times")
        parser.add_option("-a", "--avgsamples", dest="avgsamples", type="int",
            default=10,
            help="how many samples to use for hashrate average"),
        parser.add_option("-l", "--logtotext", dest="logtotext", default="none")

        self.parsedSettings, args = parser.parse_args()

        if self.parsedSettings.url is None:
            parser.print_usage()
            exit()
        else:
            self.url = self.parsedSettings.url

        for arg in args:
            self._kernelOption(arg)

    def getQueueSize(self):
        return self.parsedSettings.queuesize
    def getAvgSamples(self):
        return self.parsedSettings.avgsamples

    def _kernelOption(self, arg):
        pair = arg.split('=',1)
        if len(pair) < 2:
            pair.append(None)
        var, value = tuple(pair)
        self.kernelOptions[var.upper()] = value

    def makeLogger(self, requester, miner):
        if not self.logger:
            self.logger = ConsoleLogger(miner,self.parsedSettings.verbose,self.parsedSettings.logtotext)
        return self.logger

    def makeConnection(self, requester):
        if not self.connection:
            try:
                self.connection = minerutil.openURL(self.url, requester)
            except ValueError, e:
                print(e)
                exit()
        return self.connection

    def makeKernel(self, requester):
        if not self.kernel:
            module = self.parsedSettings.kernel
            try:
                file, filename, smt = imp.find_module(module, ['kernels'])
            except ImportError:
                print("Could not locate the specified kernel!")
                exit()
            kernelModule = imp.load_module(module, file, filename, smt)
            self.kernel = kernelModule.MiningKernel(requester)
        return self.kernel

    def makeQueue(self, requester):
        if not self.queue:
            self.queue = WorkQueue(requester, self)
        return self.queue

if __name__ == '__main__':
    options = CommandLineOptions()
    miner = Miner()
    miner.start(options)

    reactor.run()

ConsoleLogger.py
Code:
# Copyright (C) 2011 by jedi95 <jedi95@gmail.com> and
#                       CFSworks <CFSworks@gmail.com>
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
# THE SOFTWARE.

import sys
from time import time
from datetime import datetime

def formatNumber(n):
    """Format a positive integer in a more readable fashion."""
    if n < 0:
        raise ValueError('can only format positive integers')
    prefixes = 'KMGTP'
    whole = str(int(n))
    decimal = ''
    i = 0
    while len(whole) > 3:
        if i + 1 < len(prefixes):
            decimal = '.%s' % whole[-3:-1]
            whole = whole[:-3]
            i += 1
        else:
            break
    return '%s%s %s' % (whole, decimal, prefixes[i])

class ConsoleLogger(object):
    """This class will handle printing messages to the console."""

    TIME_FORMAT = '[%d/%m/%Y %H:%M:%S]'

    UPDATE_TIME = 1.0

    def __init__(self, miner, verbose=False, logtotext="none"):
        self.verbose = verbose
        self.miner = miner
        self.logtotext = logtotext
        self.lastUpdate = time() - 1
        self.rate = 0
        self.accepted = 0
        self.invalid = 0
        self.lineLength = 0
        self.connectionType = None

    def reportRate(self, rate, update=True):
        """Used to tell the logger the current Khash/sec."""
        self.rate = rate
        if update:
            self.updateStatus()

    def reportType(self, type):
        self.connectionType = type

    def reportBlock(self, block):
        self.log('Currently on block: ' + str(block))

    def reportFound(self, hash, accepted):
        if accepted:
            self.accepted += 1
        else:
            self.invalid += 1

        hexHash = hash[::-1]
        hexHash = hexHash[:8].encode('hex')
        if self.verbose:
            self.log('Result %s... %s' % (hexHash,
                'accepted' if accepted else 'rejected'))
        else:
            self.log('Result: %s %s' % (hexHash[8:],
                'accepted' if accepted else 'rejected'))

    def reportMsg(self, message):
        self.log(('MSG: ' + message), True, True)

    def reportConnected(self, connected):
        if connected:
            self.log('Connected to server')
        else:
            self.log('Disconnected from server')

    def reportConnectionFailed(self):
        self.log('Failed to connect, retrying...')

    def reportDebug(self, message):
        if self.verbose:
            self.log(message)

    def updateStatus(self, force=False):
        #only update if last update was more than a second ago
        dt = time() - self.lastUpdate
        if force or dt > self.UPDATE_TIME:
            rate = self.rate if (not self.miner.idle) else 0
            type = " [" + str(self.connectionType) + "]" if self.connectionType is not None else ''
            status = (
                "[" + formatNumber(rate) + "hash/sec] "
                "[" + str(self.accepted) + " Accepted] "
                "[" + str(self.invalid) + " Rejected]" + type)
            self.say(status)
            if self.logtotext != "none":
                try:
                        f = open(self.logtotext,"w")
                        f.write(status)
                        f.close()
                except IOError as e:
                        print("({})".format(e))
            self.lastUpdate = time()

    def say(self, message, newLine=False, hideTimestamp=False):
        #add new line if requested
        if newLine:
            message += '\n'
            if hideTimestamp:
                timestamp = ''
            else:
                timestamp = datetime.now().strftime(self.TIME_FORMAT) + ' '

            message = timestamp + message

        #erase the previous line
        if self.lineLength > 0:
            sys.stdout.write('\b \b' * self.lineLength)
            sys.stdout.write(' ' * self.lineLength)
            sys.stdout.write('\b \b' * self.lineLength)

        #print the line
        sys.stdout.write(message)
        sys.stdout.flush()

        #cache the current line length
        if newLine:
            self.lineLength = 0
        else:
            self.lineLength = len(message)

    def log(self, message, update=True, hideTimestamp=False):
        self.say(message, True, hideTimestamp)
        if update:
            self.updateStatus(True)

Added new command line argument:  -l filename.txt

What it does is to export "status(hashrate and other stats)" to a plain text file, in a single line for easier use.
Like this:
Quote
[400.31 Mhash/sec] [0 Accepted] [0 Rejected] [RPC]

You can use routes too, like this -l /usr/hashrate.txt, but you going to need to run the miner with sudo.

It seems to be working fine.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JaTochNietDan on July 09, 2011, 01:39:22 AM
Code:
[09/07/2011 02:36:59] Phoenix r101 starting...
[09/07/2011 02:37:03] Connected to server
[09/07/2011 02:37:03] Currently on block: 135403
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

It never moves up in hashes....can anyone help?

I'm running Ubuntu 10.10 with an ATI 5850 and using these parameters:

Code:
-k poclbm DEVICE=1 VECTORS BFI_INT AGGRESSION=7

I ran it without the device parameter and it showed me a list of my devices, the second one which is ID 1 is displayed as Cypress which I assume is my ATI card? The first one is my processor. It does work when I select my processor as the device, although as expected it's extremely slow.

Followed this (http://forum.bitcoin.org/?topic=7514.0) tutorial exactly, except I didn't use 11.04 as I don't have access to it currently. Any suggestions besides updating to 11.04?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: brunoshady on July 09, 2011, 02:51:58 AM
Code:
[09/07/2011 02:36:59] Phoenix r101 starting...
[09/07/2011 02:37:03] Connected to server
[09/07/2011 02:37:03] Currently on block: 135403
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

It never moves up in hashes....can anyone help?

I'm running Ubuntu 10.10 with an ATI 5850 and using these parameters:

Code:
-k poclbm DEVICE=1 VECTORS BFI_INT AGGRESSION=7

I ran it without the device parameter and it showed me a list of my devices, the second one which is ID 1 is displayed as Cypress which I assume is my ATI card? The first one is my processor. It does work when I select my processor as the device, although as expected it's extremely slow.

Followed this (http://forum.bitcoin.org/?topic=7514.0) tutorial exactly, except I didn't use 11.04 as I don't have access to it currently. Any suggestions besides updating to 11.04?

try to remove vectors and BFI_INT and probably will work... I guess it's something wrong with your drivers, or your card doesnt support neither vectors or bfi_int


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JaTochNietDan on July 09, 2011, 03:15:08 AM
Code:
[09/07/2011 02:36:59] Phoenix r101 starting...
[09/07/2011 02:37:03] Connected to server
[09/07/2011 02:37:03] Currently on block: 135403
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

It never moves up in hashes....can anyone help?

I'm running Ubuntu 10.10 with an ATI 5850 and using these parameters:

Code:
-k poclbm DEVICE=1 VECTORS BFI_INT AGGRESSION=7

I ran it without the device parameter and it showed me a list of my devices, the second one which is ID 1 is displayed as Cypress which I assume is my ATI card? The first one is my processor. It does work when I select my processor as the device, although as expected it's extremely slow.

Followed this (http://forum.bitcoin.org/?topic=7514.0) tutorial exactly, except I didn't use 11.04 as I don't have access to it currently. Any suggestions besides updating to 11.04?

try to remove vectors and BFI_INT and probably will work... I guess it's something wrong with your drivers, or your card doesnt support neither vectors or bfi_int

Have tried it like that too, same results :(


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: brunoshady on July 09, 2011, 04:20:24 AM
Code:
[09/07/2011 02:36:59] Phoenix r101 starting...
[09/07/2011 02:37:03] Connected to server
[09/07/2011 02:37:03] Currently on block: 135403
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

It never moves up in hashes....can anyone help?

I'm running Ubuntu 10.10 with an ATI 5850 and using these parameters:

Code:
-k poclbm DEVICE=1 VECTORS BFI_INT AGGRESSION=7

I ran it without the device parameter and it showed me a list of my devices, the second one which is ID 1 is displayed as Cypress which I assume is my ATI card? The first one is my processor. It does work when I select my processor as the device, although as expected it's extremely slow.

Followed this (http://forum.bitcoin.org/?topic=7514.0) tutorial exactly, except I didn't use 11.04 as I don't have access to it currently. Any suggestions besides updating to 11.04?

try to remove vectors and BFI_INT and probably will work... I guess it's something wrong with your drivers, or your card doesnt support neither vectors or bfi_int

Have tried it like that too, same results :(


hmm, try another kernell...

and why your phoenix starts with r101 starting... when you download this?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: JaTochNietDan on July 09, 2011, 10:02:22 AM
Code:
[09/07/2011 02:36:59] Phoenix r101 starting...
[09/07/2011 02:37:03] Connected to server
[09/07/2011 02:37:03] Currently on block: 135403
[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]

It never moves up in hashes....can anyone help?

I'm running Ubuntu 10.10 with an ATI 5850 and using these parameters:

Code:
-k poclbm DEVICE=1 VECTORS BFI_INT AGGRESSION=7

I ran it without the device parameter and it showed me a list of my devices, the second one which is ID 1 is displayed as Cypress which I assume is my ATI card? The first one is my processor. It does work when I select my processor as the device, although as expected it's extremely slow.

Followed this (http://forum.bitcoin.org/?topic=7514.0) tutorial exactly, except I didn't use 11.04 as I don't have access to it currently. Any suggestions besides updating to 11.04?

try to remove vectors and BFI_INT and probably will work... I guess it's something wrong with your drivers, or your card doesnt support neither vectors or bfi_int

Have tried it like that too, same results :(


hmm, try another kernell...

and why your phoenix starts with r101 starting... when you download this?

I got it from the topic I linked with the git clone command, only a few hours ago so it should be the latest version.

I think I'll just switch to a lightweight Windows installation, Ubuntu has been causing problems on that mining rig that I've setup. 11.04 wouldn't even boot on it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bcforum on July 09, 2011, 05:31:44 PM
any ideas to reach 300+Mhash/sec on a 6870 using Phoenix 1.5?

running stock voltages and clock speeds I'm only getting 265Mhash/sec
any way to get that up to 300 w/o overclocking? (don't want to shorten the life of the card)
if not, then what should i overclock/underclock to hit 300Mhash/sec?

rig specs:
Ubuntu 11.04
2x HIS PCI-Express ATI Radeon HD6870 Video Card (Engine Clock: 900 MHz; Video Memory: 1GB DDR5; Memory Clock: 4.2 GHz; RAMDAC: 400 MHz)
AMD Sempron 140, Socket AM3, 2.7 GHz, 1 MB Cache, 45 Watts
ASRock AM3 processors AMD 770-140W 4DDR3/ATI CrossFireX motherboard
Seagate Barracuda 7200.12 500 GB 7200RPM SATA 6Gb/s with NCQ 16MB Cache
Kingston ValueRAM 2 GB 1333MHz PC3-10600 DDR3 DIMM Desktop Memory
Thermaltake V3 Black Edition SECC / Plastic ATX Mid Tower Computer Case
Antec EA-650 Green ATX Energy Star Certified Power Supply


running:
python phoenix.py -u http://user:pass@server:8832 -k phatk VECTORS BFI_INT AGGRESSION=12 DEVICE=0

thanks in advanced!

Try different values of WORKSIZE and see what helps. Also, try the poclbm kernel as well.

I'm using:
-k poclbm DEVICE=0 AGGRESSION=13 BFI_INT WORKSIZE=64 VECTORS FASTLOOP=false

because the phatk kernel is about 4% slower than poclbm.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Tx2000 on July 10, 2011, 11:37:28 AM
Are there parameters or plan to include a failover similiar to that of poclbm?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Druas on July 10, 2011, 07:49:07 PM
I have seen one or two optimization to phoenix in the past two weeks. Any chance these could be released as a 1.51?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: irosaurus on July 11, 2011, 04:59:21 PM
hi everybody,

I have a quick question. I noticed that the phoenix miner is using one out of four cpu cores completely. so on my quadcore, I have a constant cpu use of about 25%. when I use poclbm instead, it will only use about 1% of my cpu. Is this a normal behaviour of the phoenix miner? because phoenix miner is about 5% faster in mining than poclbm on my system (hd5770). so I would prefer to use the phoenix miner, but with the high cpu usuage, it will cost me more electricity and it produces more heat, what isn't good at all, and eats up the higher efficiency in mining.
is there any possibility to fix the cpu usuage?

cheers iro


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: pandemic on July 11, 2011, 07:05:29 PM
hi everybody,

I have a quick question. I noticed that the phoenix miner is using one out of four cpu cores completely. so on my quadcore, I have a constant cpu use of about 25%. when I use poclbm instead, it will only use about 1% of my cpu. Is this a normal behaviour of the phoenix miner? because phoenix miner is about 5% faster in mining than poclbm on my system (hd5770). so I would prefer to use the phoenix miner, but with the high cpu usuage, it will cost me more electricity and it produces more heat, what isn't good at all, and eats up the higher efficiency in mining.
is there any possibility to fix the cpu usuage?

cheers iro

I'm wondering the same thing. I've got a 5830 and a 4870 in the same machine running CCC 11.7. The 4870 is running at 84mh/s and the 5830 is going at 304mh/s.

Looking at phoenix.exe, both instances of the program are running at 50% cpu usage. My CPU is a Core 2 duo overclocked to 3.2ghz.

This really needs to be looked into.

Strange thing is I don't think it was always this way. I don't know what changed but I think in earlier versions of phoenix my CPU usage was far lower.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: redshark1802 on July 11, 2011, 07:09:08 PM
has someone of you the same issues as described here?
http://forum.bitcoin.org/index.php?topic=27045.0


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dikidera on July 12, 2011, 08:20:24 PM
Why doesnt phoenix from source dont wanna run on python 2.7? I get an error, and it appears that pyopencl requires python26.dll...meaning python 2.6


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: RobertRibbeck on July 12, 2011, 11:19:42 PM
Just tried version 1.50

Congrats it's eating cpu cycles like crazy AGAIN


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: pandemic on July 13, 2011, 01:13:12 AM
Yep, it's pretty bad. 50% cpu usage per GPU. Something is seriously wrong.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Diapolo on July 13, 2011, 05:37:17 AM
Yep, it's pretty bad. 50% cpu usage per GPU. Something is seriously wrong.

Wow I checked this for my system (Phenom II X6 / Win7 x64 SP1) and Phoenix 1.5 eats one FULL CPU core per instance running (2 GPUs - 2 Cores eaten).
I downclock the cores to 800 MHz each, for Mining so one could think, if I raise the core freq. it will only use 1 core for 2 or more cards. No it eats one core and it doesn't matter, if it's clocked at 800 MHz or 3200 MHz, THAT IS crazy.

Jedi, is there any explanation for this, can we help to track the issue down!?

Dia


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on July 13, 2011, 08:25:56 AM
Yep, it's pretty bad. 50% cpu usage per GPU. Something is seriously wrong.

Wow I checked this for my system (Phenom II X6 / Win7 x64 SP1) and Phoenix 1.5 eats one FULL CPU core per instance running (2 GPUs - 2 Cores eaten).
I downclock the cores to 800 MHz each, for Mining so one could think, if I raise the core freq. it will only use 1 core for 2 or more cards. No it eats one core and it doesn't matter, if it's clocked at 800 MHz or 3200 MHz, THAT IS crazy.

Jedi, is there any explanation for this, can we help to track the issue down!?

Dia

Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dishwara on July 13, 2011, 10:27:42 AM
Yep, it's pretty bad. 50% cpu usage per GPU. Something is seriously wrong.

Wow I checked this for my system (Phenom II X6 / Win7 x64 SP1) and Phoenix 1.5 eats one FULL CPU core per instance running (2 GPUs - 2 Cores eaten).
I downclock the cores to 800 MHz each, for Mining so one could think, if I raise the core freq. it will only use 1 core for 2 or more cards. No it eats one core and it doesn't matter, if it's clocked at 800 MHz or 3200 MHz, THAT IS crazy.

Jedi, is there any explanation for this, can we help to track the issue down!?

Dia

Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.

+ you can use granola software & put it in lowest speed(for some strange reason MiserWare also uses more CPU), that will put the temperature of that core under 65C & also you won't feel any lagging in windows.
I have 2 * 5870 GPU's mining in Windows 7 with Aero enabled giving 434 & 442 Mhash/s


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Schleicher on July 13, 2011, 03:38:03 PM
Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.
Well, on my system it goes like this:
 1% CPU with AGGRESSION=9
17% CPU with AGGRESSION=10
33% CPU with AGGRESSION=11

This is with an Athlon 64 X2 6000+, one 6870 card and Catalyst 11.6/SDK 2.4


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on July 13, 2011, 04:04:15 PM
Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.
Well, on my system it goes like this:
 1% CPU with AGGRESSION=9
17% CPU with AGGRESSION=10
33% CPU with AGGRESSION=11

This is with an Athlon 64 X2 6000+, one 6870 card and Catalyst 11.6/SDK 2.4

Well, I have no idea what's going on there. If you were having the problem described above your CPU load would be pegged at 50% (1 core out of 2 at 100%) regardless of miner settings. I don't know how it can end up using more CPU at higher aggression, since there are fewer kernel executions per second. On miners without the 100% problem the most CPU usage I have seen is 2-3%


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: pandemic on July 13, 2011, 07:18:23 PM
Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.
Well, on my system it goes like this:
 1% CPU with AGGRESSION=9
17% CPU with AGGRESSION=10
33% CPU with AGGRESSION=11

This is with an Athlon 64 X2 6000+, one 6870 card and Catalyst 11.6/SDK 2.4

Well, I have no idea what's going on there. If you were having the problem described above your CPU load would be pegged at 50% (1 core out of 2 at 100%) regardless of miner settings. I don't know how it can end up using more CPU at higher aggression, since there are fewer kernel executions per second. On miners without the 100% problem the most CPU usage I have seen is 2-3%

And the only way around this is to either mine with one card or change affinity? I'll have to knock the CPU OC back down to 2.6 to save on heat/electric. This is a major bummer.

Is there any way we could inform ATI of the bug to get it ironed out?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: deepceleron on July 13, 2011, 08:40:37 PM
Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.
Well, on my system it goes like this:
 1% CPU with AGGRESSION=9
17% CPU with AGGRESSION=10
33% CPU with AGGRESSION=11

This is with an Athlon 64 X2 6000+, one 6870 card and Catalyst 11.6/SDK 2.4

Well, I have no idea what's going on there. If you were having the problem described above your CPU load would be pegged at 50% (1 core out of 2 at 100%) regardless of miner settings. I don't know how it can end up using more CPU at higher aggression, since there are fewer kernel executions per second. On miners without the 100% problem the most CPU usage I have seen is 2-3%

The 11.7 driver that is being used causes a CPU core to go to 100% usage per miner instance. That is what changed in the previous poster's setup. Reverting to 11.6/SDK 2.4 will likely solve the problem.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: pandemic on July 13, 2011, 11:21:26 PM
Nothing can be done on my end. For Windows if you have more than 1 ATI GPU installed each instance will peg one CPU core at 100%. There is some stupid event loop in ATI's driver. The best way to minimize the problem is to change the process affinity so that all the instances run on the same CPU core. This doesn't reduce hashrate at all.
Well, on my system it goes like this:
 1% CPU with AGGRESSION=9
17% CPU with AGGRESSION=10
33% CPU with AGGRESSION=11

This is with an Athlon 64 X2 6000+, one 6870 card and Catalyst 11.6/SDK 2.4

Well, I have no idea what's going on there. If you were having the problem described above your CPU load would be pegged at 50% (1 core out of 2 at 100%) regardless of miner settings. I don't know how it can end up using more CPU at higher aggression, since there are fewer kernel executions per second. On miners without the 100% problem the most CPU usage I have seen is 2-3%

The 11.7 driver that is being used causes a CPU core to go to 100% usage per miner instance. That is what changed in the previous poster's setup. Reverting to 11.6/SDK 2.4 will likely solve the problem.

I've tried it with 11.2, same issue. It's not 11.7 only.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on July 14, 2011, 03:25:23 AM
The rewrite for the RPC protocol is finished, and has been uploaded to the SVN.

It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: hipaulshi on July 14, 2011, 05:32:42 AM
Quote
The rewrite for the RPC protocol is finished, and has been uploaded to the SVN.

It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.

i tested it and it resulted in constant disconnects from btcguild (all servers). I reverted back to r110 and the problem disappeared.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on July 14, 2011, 03:18:25 PM
Quote
The rewrite for the RPC protocol is finished, and has been uploaded to the SVN.

It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.

i tested it and it resulted in constant disconnects from btcguild (all servers). I reverted back to r110 and the problem disappeared.

Same here. I ran r111 against Chris Howie's mining proxy (on the same machine, so there shouldn't be any real connection issues), and got lots and lots of disconnects and idles. With r110 it works flawlessly.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Peao on July 16, 2011, 11:34:29 AM
Jedi, are you aware of this?

http://forum.bitcoin.org/index.php?topic=25719.0


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: xali on July 17, 2011, 03:41:43 AM
I read the first few posts, but obviously i didn't read the entire thread so I wouldn't know if it's been answered yet but is there any way to add some sort of delay? I made it aggression level=0 but i still feel it's too fast and would make the laptop too hot and stuff


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: NF6X on July 17, 2011, 04:49:44 AM
I'm new here, and I hope this isn't a dumb FAQ. I've successfully mined a bit with phoenix on an XFX 6790 under Debian Squeeze with SDK 2.4. Today I added a Diamond 6970, and it seems that I don't know how to mine on dual cards yet. I have one monitor plugged into each card, running with XINERAMA=on, if that matters. When I run phoenix, it's only mining on the first GPU (which happens to be the 6970). If I try DEVICE=1, then it runs on the built-in GPU in my CPU. Any hints for a clueless noob?

While I'm here, I notice that the 6970 runs a lot hotter than the 6790. With little or no overclocking, the 6970 is running at 90 deg. C while the 6790 runs at around 68 deg. C.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: NF6X on July 17, 2011, 10:40:06 AM
After a lot of flailing around and hair pulling, I managed to get my dual card, dual monitor setup working. I also found out how to crank up my GPU fan speed, and my rig is now mining along at about 540 MH/s with GPU temps of 72 and 65.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Okama on July 18, 2011, 08:29:00 AM
Quote
r112 | jedi95 | 2011-07-18 13:09:01 +0900 (Mon, 18 Jul 2011) | 1 line

Performance improvement for phatk
just updated to r112, but got my speed slow down from ~360Mhash --> ~330Mhash (Ubuntu 11.4, SDK 2.4, phatk on a 5850 850MHz). Rolled back to r111 & waiting for news.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on July 18, 2011, 08:45:14 AM
Quote
r112 | jedi95 | 2011-07-18 13:09:01 +0900 (Mon, 18 Jul 2011) | 1 line

Performance improvement for phatk
just updated to r112, but got my speed slow down from ~360Mhash --> ~330Mhash (Ubuntu 11.4, SDK 2.4, phatk on a 5850 850MHz). Rolled back to r111 & waiting for news.

Odd, I'm running phatk r112 on 4 5870s and a 5830. The hashrate is slightly higher than what I get with r111.

I didn't make these particular changes to phatk, see this thread:
http://forum.bitcoin.org/index.php?topic=25860.0


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Diapolo on July 18, 2011, 09:28:59 AM
That huge drop seems weird ... a 5850 should benefit from the new kernel. What's your cards mem clock?
Jedi, on which of my versions is your kernel based? Did you use the one with modified init file? I hope it's not a "Linux thing", I'm on Win7 x64 and a 5830 and 5870 is faster than with the original phatk.

Dia


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Okama on July 18, 2011, 05:57:57 PM
the core/mem clock is 850/180, I've run at this clock for more than a month and happy with this ;D

However, when I changed the clock to 850/300, the speed went back to ~361, a litte better than before.

ps: my other 5850s, at 850/180 clock with the lastest poclbm, the speed is around 360Mhash.

/Diapolo: Thanks for the hard work on optimizing phatk kernel. Really appreciate it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Dyaheon on July 18, 2011, 10:04:54 PM
Was mining fine at first, then this (http://pastebin.com/yynKXtyZ) happened (100% rejected), on btcguild (USWest).

Meanwhile my poclbm miners on same rig were fine, so it seems something is wrong...

This was with r112 -k phatk VECTORS BFI_INT AGGRESSION=13 FASTLOOP=false WORKSIZE=256


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: simonk83 on July 19, 2011, 06:46:40 AM
Is there any chance of getting the --backup flag added/working?   I use Guiminer with Phoenix, and being able to switch to a backup pool is about the only thing I'm missing right now.

Thanks!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: twmz on July 23, 2011, 02:15:52 PM
FYI, phoenix now works with OS X in Lion.  It appears that Apple updated their twisted library sufficiently that phoenix is now happy to run.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Clipse on July 24, 2011, 03:02:14 PM
Does phoenix allow external adjustments to the gpu utilization, or would it be possible to add support for such a feature?

What I need to do is feed from external source to phoenixminer specific gpu utilization ie. external source parses to phoenix miner instance to utilise 29% of gpu cycles etc.


Title: Error in displaying shares?
Post by: bb on July 24, 2011, 05:50:22 PM
I've been watching my miner for quite a while now and I have observed some strange behaviour in share reporting.

When I raise the clock of my card:

http://i.imgur.com/a2Cml.png

the MHash/s rises:

http://i.imgur.com/7M7Kw.png

but the rate of growth of submitted shares stays the same:

http://i.imgur.com/TkhG7.png

Shouldn't more MHash/s mean more submitted shares?


Title: Re: Error in displaying shares?
Post by: bcforum on July 25, 2011, 08:23:50 AM
Shouldn't more MHash/s mean more submitted shares?

If you look closely at the bottom chart, it appears the upper portion has a slightly steeper slope than the lower section. Plot a differential chart (x[n+1] - x[n]) and you will see the change more clearly.


Title: Re: Error in displaying shares?
Post by: TeaRex on July 25, 2011, 09:21:43 AM
Shouldn't more MHash/s mean more submitted shares?

Where do you get the mhash0 number from? try using the -a parameter of phoenix with a large averaging period and see if it really goes up in the longer term. Sometimes an overclocked card will develop heat problems and stop itself or clock itself down for short periods again and again. Local overheating at some point of the chip can happen even if the overall temperature of the GPU is well within a sane range.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: c00w on July 26, 2011, 07:51:55 PM
Has anyone noticed a memory leak with phoenix? I seem to be getting roughly 27% of memory usage after two days of running it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Peao on July 26, 2011, 10:50:39 PM
Has anyone noticed a memory leak with phoenix? I seem to be getting roughly 27% of memory usage after two days of running it.

+1


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bcforum on July 28, 2011, 12:33:02 PM
Has anyone noticed a memory leak with phoenix? I seem to be getting roughly 27% of memory usage after two days of running it.

I did a quick experiment last night on Ubuntu.

% memstat | grep python | head -4
   9228k: PID  1747 (/usr/bin/python2.6)
 201956k: PID  2295 (/usr/bin/python2.6)
   9248k: PID  2311 (/usr/bin/python2.6)
 219828k: PID  2344 (/usr/bin/python2.6)

8 hours later:
% memstat | grep python | head -4
   9228k: PID  1747 (/usr/bin/python2.6)
 231140k: PID  2295 (/usr/bin/python2.6)
   9248k: PID  2311 (/usr/bin/python2.6)
 249004k: PID  2344 (/usr/bin/python2.6)

So yes, there is a definite memory leak.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: c00w on July 28, 2011, 08:07:08 PM
If someone could load it up in pdb and figure out what datastructure is doing it, I could probably fix it.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: simonk83 on July 28, 2011, 08:59:41 PM
That'd be great c00w.  Hopefully that'll fix this as well:  http://forum.bitcoin.org/index.php?topic=29977.msg376803#msg376803


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on July 29, 2011, 07:17:41 AM
If someone could load it up in pdb and figure out what datastructure is doing it, I could probably fix it.

I would start with the RPC code, including the modified Twisted.web library. I run my miners through MMP, and I usually run them for weeks at a time with >100,000 accepted shares between restarts. I don't see any performance problems or memory leaks running with MMP.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: c00w on July 29, 2011, 07:00:59 PM
I think its the rpc code itself not the modified twisted persistent client. bitHopper uses almost identical code from the bugfix and shows no memory gain.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cyberlync on August 02, 2011, 07:22:30 PM
Perhaps a stupid question, but where can I get the r110 version? When I go to the SVN it shows r112
I am getting a whole lot of idles and restarts on btcguild with the newest version.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dime on August 02, 2011, 09:31:41 PM
Perhaps a stupid question, but where can I get the r110 version? When I go to the SVN it shows r112
I am getting a whole lot of idles and restarts on btcguild with the newest version.

svn checkout -r 110 http://svn3.xp-dev.com/svn/phoenix-miner/trunk


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: dime on August 02, 2011, 09:46:22 PM
Quote
The rewrite for the RPC protocol is finished, and has been uploaded to the SVN.

It works fine in my testing, but more feedback would be great before pushing this as a new version. This SHOULD definitively fix the idle problem, since that was related to the old RPCProtocol.

i tested it and it resulted in constant disconnects from btcguild (all servers). I reverted back to r110 and the problem disappeared.

+1

I was mining for 2 days straight with constant disconnects from btcguild (all servers) and bitcoins.lc for about 10-15% rejected. There were no disconnects from slush's pool though.

Reverted to revision r110 and now all is good with btcguild and bitcoins.lc.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cyberlync on August 02, 2011, 11:03:49 PM
Perhaps a stupid question, but where can I get the r110 version? When I go to the SVN it shows r112
I am getting a whole lot of idles and restarts on btcguild with the newest version.

svn checkout -r 110 http://svn3.xp-dev.com/svn/phoenix-miner/trunk

After trying the URL, getting an error in firefox, installing chrome, retrying the url in chrome, I finally googled it, and found out it's for linux, Im a winblows nab, and can't for the love of bitcoins, figure out how I get the r110. Please help me, Im getting balder by the minute.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on August 02, 2011, 11:36:11 PM
After trying the URL, getting an error in firefox, installing chrome, retrying the url in chrome, I finally googled it, and found out it's for linux, Im a winblows nab, and can't for the love of bitcoins, figure out how I get the r110. Please help me, Im getting balder by the minute.

Install Tortoise SVN from http://tortoisesvn.net/downloads.html (http://tortoisesvn.net/downloads.html) and use it to perform the checkout.

Before you do that, you should know that running any SVN version of Phoenix requires you to have installed Phython and a bunch of extra Phyton packages. If you can't or won't do that, stick to the offical released version.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: cyberlync on August 03, 2011, 12:00:19 AM
After trying the URL, getting an error in firefox, installing chrome, retrying the url in chrome, I finally googled it, and found out it's for linux, Im a winblows nab, and can't for the love of bitcoins, figure out how I get the r110. Please help me, Im getting balder by the minute.

Install Tortoise SVN from http://tortoisesvn.net/downloads.html (http://tortoisesvn.net/downloads.html) and use it to perform the checkout.

Before you do that, you should know that running any SVN version of Phoenix requires you to have installed Phython and a bunch of extra Phyton packages. If you can't or won't do that, stick to the offical released version.

Thank you!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nomnomnom on August 03, 2011, 09:36:27 AM
If someone could load it up in pdb and figure out what datastructure is doing it, I could probably fix it.

I would start with the RPC code, including the modified Twisted.web library. I run my miners through MMP, and I usually run them for weeks at a time with >100,000 accepted shares between restarts. I don't see any performance problems or memory leaks running with MMP.

Hi,

I think it could be related to longpolling. For example when I mine on slush (rpc only) it works fine for days, as soon as
I mine on a pool that uses longpolling it starts to fill the memory. It happens on arsbitcoin and btcguild in my case.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bcforum on August 03, 2011, 11:37:25 AM
If someone could load it up in pdb and figure out what datastructure is doing it, I could probably fix it.

I would start with the RPC code, including the modified Twisted.web library. I run my miners through MMP, and I usually run them for weeks at a time with >100,000 accepted shares between restarts. I don't see any performance problems or memory leaks running with MMP.

Hi,

I think it could be related to longpolling. For example when I mine on slush (rpc only) it works fine for days, as soon as
I mine on a pool that uses longpolling it starts to fill the memory. It happens on arsbitcoin and btcguild in my case.


I don't get the same result.  When I mine solo against the standard client (RPC only, no long polling) memory fills up.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Odi on August 03, 2011, 11:11:23 PM
I'm another one with disconnect problems, here is my experience on Fedora Core 5 with ActivePython 2.7.2.5 in the Ars pool (phoenix with phatk kernel):

svn checkout http://svn3.xp-dev.com/svn/phoenix-miner/trunk

r111 from yesterday, 30 accepted, 4 rejected (1 real reject, 3 rejects because of disconnect), 188MH/s

Code:
[03/08/2011 15:19:53] Phoenix r111 starting...
[03/08/2011 15:19:53] Connected to server
[03/08/2011 15:19:53] Server gave new work; passing to WorkQueue
[03/08/2011 15:19:53] New block (WorkQueue)
[03/08/2011 15:19:53] Server gave new work; passing to WorkQueue
[03/08/2011 15:19:54] Using new LP URL /LP
[03/08/2011 15:19:54] LP connected to arsbitcoin.com:XXXX
[03/08/2011 15:20:16] Server gave new work; passing to WorkQueue
[03/08/2011 15:20:28] Result 000000001c389660... accepted
[03/08/2011 15:20:29] Result 0000000076722dbe... accepted
[03/08/2011 15:20:32] Result 00000000fc3029f4... accepted
[03/08/2011 15:20:39] Server gave new work; passing to WorkQueue
[03/08/2011 15:20:49] Result 0000000009f0a1e5... accepted
[03/08/2011 15:20:53] Result 00000000f1fbf3eb... accepted
[03/08/2011 15:21:01] Server gave new work; passing to WorkQueue
[03/08/2011 15:21:02] Result 000000004169e08d... accepted
[03/08/2011 15:21:24] Server gave new work; passing to WorkQueue
[03/08/2011 15:21:41] Result 00000000c3d105dc... accepted
[03/08/2011 15:21:47] Server gave new work; passing to WorkQueue
[03/08/2011 15:22:05] Result 000000005f316441... accepted
[03/08/2011 15:22:10] Result 0000000019c401ca... accepted
[03/08/2011 15:22:10] Server gave new work; passing to WorkQueue
[03/08/2011 15:22:23] Result 00000000bedb83ed... accepted
[03/08/2011 15:22:33] Server gave new work; passing to WorkQueue
[03/08/2011 15:22:45] Result 00000000819e2c9d... accepted
[03/08/2011 15:22:53] Result 00000000814424af... accepted
[03/08/2011 15:22:55] Server gave new work; passing to WorkQueue
[03/08/2011 15:23:18] Server gave new work; passing to WorkQueue
[03/08/2011 15:23:22] Server gave new work; passing to WorkQueue
[03/08/2011 15:23:22] New block (WorkQueue)
[03/08/2011 15:23:22] LP: New work pushed
[03/08/2011 15:23:22] Result 0000000095bb2fe8... rejected
[03/08/2011 15:23:22] Server gave new work; passing to WorkQueue
[03/08/2011 15:23:36] Result 00000000127cc49d... accepted
[03/08/2011 15:23:42] Result 00000000621b950d... accepted
[03/08/2011 15:23:45] Server gave new work; passing to WorkQueue
[03/08/2011 15:23:51] Result 000000004af6c2ac... accepted
[03/08/2011 15:24:08] Server gave new work; passing to WorkQueue
[03/08/2011 15:24:14] Server gave new work; passing to WorkQueue
[03/08/2011 15:24:14] New block (WorkQueue)
[03/08/2011 15:24:14] LP: New work pushed
[03/08/2011 15:24:14] Server gave new work; passing to WorkQueue
[03/08/2011 15:24:36] Server gave new work; passing to WorkQueue
[03/08/2011 15:24:38] Result 000000008f0f15dc... accepted
[03/08/2011 15:24:57] Result 00000000aa324577... accepted
[03/08/2011 15:24:59] Server gave new work; passing to WorkQueue
[03/08/2011 15:25:03] Result 00000000a21f563c... accepted
[03/08/2011 15:25:22] Server gave new work; passing to WorkQueue
[03/08/2011 15:25:26] Result 000000008d60ee63... accepted
[03/08/2011 15:25:31] Result 000000004db5858f... accepted
[03/08/2011 15:25:36] Result 0000000009cd448f... accepted
[03/08/2011 15:25:45] Server gave new work; passing to WorkQueue
[03/08/2011 15:25:58] Result 0000000087439926... accepted
[03/08/2011 15:26:08] Server gave new work; passing to WorkQueue
[03/08/2011 15:26:31] Server gave new work; passing to WorkQueue
[03/08/2011 15:26:35] Server gave new work; passing to WorkQueue
[03/08/2011 15:26:35] New block (WorkQueue)
[03/08/2011 15:26:35] LP: New work pushed
[03/08/2011 15:26:35] Server gave new work; passing to WorkQueue
[03/08/2011 15:26:58] Server gave new work; passing to WorkQueue
[03/08/2011 15:27:11] Disconnected from server
[03/08/2011 15:27:11] Result 00000000c4abbd72... rejected
[03/08/2011 15:27:21] Connected to server
[03/08/2011 15:27:21] Server gave new work; passing to WorkQueue
[03/08/2011 15:27:43] Server gave new work; passing to WorkQueue
[03/08/2011 15:28:06] Server gave new work; passing to WorkQueue
[03/08/2011 15:28:10] Result 0000000034ca9854... accepted
[03/08/2011 15:28:15] Result 000000006989ee7d... accepted
[03/08/2011 15:28:17] Result 00000000bc931382... accepted
[03/08/2011 15:28:29] Server gave new work; passing to WorkQueue
[03/08/2011 15:28:33] Result 00000000a7a0c3ad... accepted
[03/08/2011 15:28:38] Result 000000001922e028... accepted
[03/08/2011 15:28:52] Server gave new work; passing to WorkQueue
[03/08/2011 15:29:15] Server gave new work; passing to WorkQueue
[03/08/2011 15:29:25] Result 000000003e1f7bee... accepted
[03/08/2011 15:29:37] Server gave new work; passing to WorkQueue
[03/08/2011 15:30:00] Server gave new work; passing to WorkQueue
[03/08/2011 15:30:23] Server gave new work; passing to WorkQueue
[03/08/2011 15:30:43] Disconnected from server
[03/08/2011 15:30:43] Result 000000001770ff49... rejected
[03/08/2011 15:30:46] Connected to server
[03/08/2011 15:30:46] Server gave new work; passing to WorkQueue
[03/08/2011 15:30:55] Result 00000000babf0a08... accepted
[03/08/2011 15:31:09] Server gave new work; passing to WorkQueue
[03/08/2011 15:31:31] Server gave new work; passing to WorkQueue
[03/08/2011 15:31:54] Server gave new work; passing to WorkQueue
[03/08/2011 15:32:08] Disconnected from server
[03/08/2011 15:32:08] Result 0000000086bde4b3... rejected
[03/08/2011 15:32:16] Connected to server
[03/08/2011 15:32:16] Result 000000009beed6f1... accepted
[03/08/2011 15:32:17] Server gave new work; passing to WorkQueue

svn checkout http://svn3.xp-dev.com/svn/phoenix-miner/tags/release-1.50

The 1.50 version that I've had good success with, and I modified the #define Ma, 31 accepted, no rejected or disconnects, 186MH/s

Code:
[03/08/2011 15:44:30] Phoenix 1.50 starting...
[03/08/2011 15:44:30] Connected to server
[03/08/2011 15:44:30] Server gave new work; passing to WorkQueue
[03/08/2011 15:44:30] New block (WorkQueue)
[03/08/2011 15:44:32] Server gave new work; passing to WorkQueue
[03/08/2011 15:44:54] Server gave new work; passing to WorkQueue
[03/08/2011 15:45:17] Server gave new work; passing to WorkQueue
[03/08/2011 15:45:17] Result 00000000fc9d82a9... accepted
[03/08/2011 15:45:18] Result 0000000063e2ff80... accepted
[03/08/2011 15:45:40] Server gave new work; passing to WorkQueue
[03/08/2011 15:45:49] LP: New work pushed
[03/08/2011 15:45:49] Server gave new work; passing to WorkQueue
[03/08/2011 15:45:49] New block (WorkQueue)
[03/08/2011 15:45:49] Server gave new work; passing to WorkQueue
[03/08/2011 15:46:12] Server gave new work; passing to WorkQueue
[03/08/2011 15:46:35] Server gave new work; passing to WorkQueue
[03/08/2011 15:46:59] Server gave new work; passing to WorkQueue
[03/08/2011 15:47:10] Result 00000000dfd9c5ce... accepted
[03/08/2011 15:47:22] Server gave new work; passing to WorkQueue
[03/08/2011 15:47:45] Server gave new work; passing to WorkQueue
[03/08/2011 15:48:08] Server gave new work; passing to WorkQueue
[03/08/2011 15:48:16] Result 00000000f66b0d25... accepted
[03/08/2011 15:48:25] Result 00000000a8dc29b2... accepted
[03/08/2011 15:48:31] Server gave new work; passing to WorkQueue
[03/08/2011 15:48:54] Server gave new work; passing to WorkQueue
[03/08/2011 15:48:59] Result 0000000095e655b0... accepted
[03/08/2011 15:49:08] Result 000000001559c7a1... accepted
[03/08/2011 15:49:17] Server gave new work; passing to WorkQueue
[03/08/2011 15:49:40] Server gave new work; passing to WorkQueue
[03/08/2011 15:50:03] Server gave new work; passing to WorkQueue
[03/08/2011 15:50:17] Result 0000000060ef8b17... accepted
[03/08/2011 15:50:26] Server gave new work; passing to WorkQueue
[03/08/2011 15:50:49] Server gave new work; passing to WorkQueue
[03/08/2011 15:50:50] Result 0000000031dae576... accepted
[03/08/2011 15:50:50] Result 00000000b3c72d2c... accepted
[03/08/2011 15:51:00] Result 000000001bc7ceab... accepted
[03/08/2011 15:51:12] Result 00000000557c9e6f... accepted
[03/08/2011 15:51:13] Server gave new work; passing to WorkQueue
[03/08/2011 15:51:35] Server gave new work; passing to WorkQueue
[03/08/2011 15:51:58] Server gave new work; passing to WorkQueue
[03/08/2011 15:52:22] Server gave new work; passing to WorkQueue
[03/08/2011 15:52:29] Result 000000008fdb22f3... accepted
[03/08/2011 15:52:39] Result 000000001205cc4a... accepted
[03/08/2011 15:52:45] Server gave new work; passing to WorkQueue
[03/08/2011 15:52:50] Result 00000000b1d01806... accepted
[03/08/2011 15:52:53] Result 000000005d550742... accepted
[03/08/2011 15:53:08] Server gave new work; passing to WorkQueue
[03/08/2011 15:53:23] Result 000000002ca8dcdc... accepted
[03/08/2011 15:53:25] Result 00000000d22cc6d8... accepted
[03/08/2011 15:53:31] Server gave new work; passing to WorkQueue
[03/08/2011 15:53:54] Server gave new work; passing to WorkQueue
[03/08/2011 15:54:17] Server gave new work; passing to WorkQueue
[03/08/2011 15:54:40] Server gave new work; passing to WorkQueue
[03/08/2011 15:54:49] Result 00000000e90515ef... accepted
[03/08/2011 15:54:52] Result 00000000429bbab9... accepted
[03/08/2011 15:55:04] Result 00000000efdb7449... accepted
[03/08/2011 15:55:04] Server gave new work; passing to WorkQueue
[03/08/2011 15:55:26] Server gave new work; passing to WorkQueue
[03/08/2011 15:55:33] Result 00000000d6231842... accepted
[03/08/2011 15:55:41] Result 0000000045d609a3... accepted
[03/08/2011 15:55:45] Result 000000006d1961d6... accepted
[03/08/2011 15:55:49] Server gave new work; passing to WorkQueue
[03/08/2011 15:55:49] Result 000000001de475e4... accepted
[03/08/2011 15:55:50] Result 00000000453ceef2... accepted
[03/08/2011 15:55:55] Result 00000000d98eebe8... accepted
[03/08/2011 15:56:06] LP: New work pushed
[03/08/2011 15:56:06] Server gave new work; passing to WorkQueue
[03/08/2011 15:56:06] New block (WorkQueue)
[03/08/2011 15:56:07] Server gave new work; passing to WorkQueue
[03/08/2011 15:56:30] Server gave new work; passing to WorkQueue
[03/08/2011 15:56:53] Server gave new work; passing to WorkQueue
[03/08/2011 15:56:53] Result 000000005d89ad5e... accepted
[03/08/2011 15:57:16] Server gave new work; passing to WorkQueue
[03/08/2011 15:57:39] Server gave new work; passing to WorkQueue
[03/08/2011 15:57:43] Result 00000000de4c7f98... accepted
[03/08/2011 15:57:44] Result 000000005706b190... accepted
[03/08/2011 15:57:55] Result 00000000e2b690fd... accepted


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nomnomnom on August 04, 2011, 03:47:07 AM

I don't get the same result.  When I mine solo against the standard client (RPC only, no long polling) memory fills up.

Hmm, thats weird, look at my memory graph, most of it is slush and at the end is arsbitcoin :)
http://lulzimg.com/i24/903c77.png

Maybe there is some other difference between those pools that triggers this, oh well... ::)








Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bcforum on August 04, 2011, 11:29:25 AM

Very curious. I switched to:

Code:
#!/bin/sh
export DISPLAY=:0
while true; do
    timeout -k 60 24h python phoenix.py -v \
-u http://user:pass@localhost:8332 \
-k phatk_dia DEVICE=0 AGGRESSION=13 BFI_INT WORKSIZE=128 \
VECTORS FASTLOOP=false
done

to force a restart every 24 hours, so I can't collect the data anymore.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nomnomnom on August 10, 2011, 01:02:18 PM
I noticed the memory leak does not happen on bitcoins.lc and they use longpolling.
Looking at the network traffic, it seems that bitcoins.lc uses keep-alive (slush also has keep-alive)
while the other pools (which are leaking memory) do not seem to use keep-alive!

Also there is something else which is weird.
Everything looks normal until phoenix sends out 2 similiar looking packets.
The server answers this with a error 400 bad request, which is followed by 2 RST.
This happens after every communication between miner and server.

This here is btcguild, but arsbitcoin behaves exactly the same.
Code:
14:04:20.907806 IP (tos 0x0, ttl 64, id 11848, offset 0, flags [DF], proto TCP (6), length 52)
    10.23.42.151.33398 > 69.42.216.173.8332: Flags [.], cksum 0x52ac (incorrect -> 0x91b8), seq 481, ack 182, win 123, options [nop,nop,TS val 718992981 ecr 132504115], length 0
        0x0000:  0014 bfa5 8817 0024 1d8a cc03 0800 4500  .......$......E.
        0x0010:  0034 2e48 4000 4006 b9f6 0a17 2a97 452a  .4.H@.@.....*.E*
        0x0020:  d8ad 8276 208c f8a3 dcc3 b6ca 5f86 8010  ...v........_...
        0x0030:  007b 52ac 0000 0101 080a 2ada f655 07e5  .{R.......*..U..
        0x0040:  da33                                     .3
14:04:21.179311 IP (tos 0x0, ttl 64, id 11849, offset 0, flags [DF], proto TCP (6), length 52)
    10.23.42.151.33398 > 69.42.216.173.8332: Flags [F.], cksum 0x52ac (incorrect -> 0x90a7), seq 481, ack 182, win 123, options [nop,nop,TS val 718993253 ecr 132504115], length 0
        0x0000:  0014 bfa5 8817 0024 1d8a cc03 0800 4500  .......$......E.
        0x0010:  0034 2e49 4000 4006 b9f5 0a17 2a97 452a  .4.I@.@.....*.E*
        0x0020:  d8ad 8276 208c f8a3 dcc3 b6ca 5f86 8011  ...v........_...
        0x0030:  007b 52ac 0000 0101 080a 2ada f765 07e5  .{R.......*..e..
        0x0040:  da33                                     .3
14:04:21.353823 IP (tos 0x0, ttl 54, id 34045, offset 0, flags [DF], proto TCP (6), length 316)
    69.42.216.173.8332 > 10.23.42.151.33398: Flags [P.], cksum 0x2324 (correct), seq 182:446, ack 482, win 54, options [nop,nop,TS val 132504159 ecr 718993253], length 264
        0x0000:  0024 1d8a cc03 0014 bfa5 8817 0800 4500  .$............E.
        0x0010:  013c 84fd 4000 3606 6c39 452a d8ad 0a17  .<..@.6.l9E*....
        0x0020:  2a97 208c 8276 b6ca 5f86 f8a3 dcc4 8018  *....v.._.......
        0x0030:  0036 2324 0000 0101 080a 07e5 da5f 2ada  .6#$........._*.
        0x0040:  f765 4854 5450 2f31 2e31 2034 3030 2042  .eHTTP/1.1.400.B
        0x0050:  6164 2052 6571 7565 7374 0d0a 436f 6e74  ad.Request..Cont
        0x0060:  656e 742d 5479 7065 3a20 7465 7874 2f68  ent-Type:.text/h
        0x0070:  746d 6c0d 0a43 6f6e 6e65 6374 696f 6e3a  tml..Connection:
        0x0080:  2063 6c6f 7365 0d0a 4461 7465 3a20 5765  .close..Date:.We
        0x0090:  642c 2031 3020 4175 6720 3230 3131 2031  d,.10.Aug.2011.1
        0x00a0:  323a 3033 3a33 3320 474d 540d 0a43 6f6e  2:03:33.GMT..Con
        0x00b0:  7465 6e74 2d4c 656e 6774 683a 2031 3334  tent-Length:.134
        0x00c0:  0d0a 0d0a 3c48 544d 4c3e 3c48 4541 443e  ....<HTML><HEAD>
        0x00d0:  0a3c 5449 544c 453e 3430 3020 4261 6420  .<TITLE>400.Bad.
        0x00e0:  5265 7175 6573 743c 2f54 4954 4c45 3e0a  Request</TITLE>.
        0x00f0:  3c2f 4845 4144 3e3c 424f 4459 3e0a 3c48  </HEAD><BODY>.<H
        0x0100:  313e 4d65 7468 6f64 204e 6f74 2049 6d70  1>Method.Not.Imp
        0x0110:  6c65 6d65 6e74 6564 3c2f 4831 3e0a 496e  lemented</H1>.In
        0x0120:  7661 6c69 6420 6d65 7468 6f64 2069 6e20  valid.method.in.
        0x0130:  7265 7175 6573 743c 503e 0a3c 2f42 4f44  request<P>.</BOD
        0x0140:  593e 3c2f 4854 4d4c 3e0a                 Y></HTML>.
14:04:21.353861 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.23.42.151.33398 > 69.42.216.173.8332: Flags [R], cksum 0xe4ef (correct), seq 4171488452, win 0, length 0
        0x0000:  0014 bfa5 8817 0024 1d8a cc03 0800 4500  .......$......E.
        0x0010:  0028 0000 4000 4006 e84a 0a17 2a97 452a  .(..@.@..J..*.E*
        0x0020:  d8ad 8276 208c f8a3 dcc4 0000 0000 5004  ...v..........P.
        0x0030:  0000 e4ef 0000                           ......
14:04:21.354062 IP (tos 0x0, ttl 54, id 34046, offset 0, flags [DF], proto TCP (6), length 52)
    69.42.216.173.8332 > 10.23.42.151.33398: Flags [F.], cksum 0x8fb7 (correct), seq 446, ack 482, win 54, options [nop,nop,TS val 132504159 ecr 718993253], length 0
        0x0000:  0024 1d8a cc03 0014 bfa5 8817 0800 4500  .$............E.
        0x0010:  0034 84fe 4000 3606 6d40 452a d8ad 0a17  .4..@.6.m@E*....
        0x0020:  2a97 208c 8276 b6ca 608e f8a3 dcc4 8011  *....v..`.......
        0x0030:  0036 8fb7 0000 0101 080a 07e5 da5f 2ada  .6..........._*.
        0x0040:  f765                                     .e
14:04:21.354068 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.23.42.151.33398 > 69.42.216.173.8332: Flags [R], cksum 0xe4ef (correct), seq 4171488452, win 0, length 0
        0x0000:  0014 bfa5 8817 0024 1d8a cc03 0800 4500  .......$......E.
        0x0010:  0028 0000 4000 4006 e84a 0a17 2a97 452a  .(..@.@..J..*.E*
        0x0020:  d8ad 8276 208c f8a3 dcc4 0000 0000 5004  ...v..........P.
        0x0030:  0000 e4ef 0000                           ......

I am not sure, but this does not look normal to me, with the bad request and all.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: zargon on August 10, 2011, 03:59:01 PM
new to phoenix and linux mining

just got a linuxcoin .2b worker up

phoneix.py  -v -k poclbm BFI_INT FASTLOOP=false AGGRESSION=11 DEVICE=0 WORKSIZE=128

on my 6950 2gb @ 840/1000 is pulling 315 hash.

seems a little low, my 6950 on my win7 box and guiminer is doing 330 with lower mem settings(and a lower fan speed in a hotter room)

is it low or am I just too used to staring at my 5870 miners?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: harm on August 11, 2011, 10:25:57 AM
Is the kernel 2.2 inlcuded in the latest phoenix-miner (r111)? I am getting the same results with miner r111 and r111+2.2: 403MHash on XFX HD 5850 @ 970/300


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: harm on August 11, 2011, 10:31:23 AM
By the way:
I am selling two XFX 5850;)
https://bitcointalk.org/index.php?topic=34882.msg434195#msg434195 (https://bitcointalk.org/index.php?topic=34882.msg434195#msg434195)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 11, 2011, 08:57:05 PM
Is the kernel 2.2 inlcuded in the latest phoenix-miner (r111)? I am getting the same results with miner r111 and r111+2.2: 403MHash on XFX HD 5850 @ 970/300

The phatk 2.2 kernel is included with the latest SVN revision under the name phatk2. It is also used as the default kernel in the absence of the -k argument.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on August 11, 2011, 10:27:04 PM
The RPC code in the newest SVN version r115 is still not working right. Connections go up and down all the time with lots of idles. Maybe revert it back for the time being? I can do that by hand of course if need be but it's a bit of a hassle to maintain.

FWIW, the phatk2 kernel is exactly as fast as the r115 phatk kernel on my 6990. I measured over 24 hours with one of them on the first and one on the second GPU core of that card; there was no significant deviation in the number of shares produced by each core, less than 10 shares difference.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 11, 2011, 11:29:29 PM
The RPC code in the newest SVN version r115 is still not working right. Connections go up and down all the time with lots of idles. Maybe revert it back for the time being? I can do that by hand of course if need be but it's a bit of a hassle to maintain.

FWIW, the phatk2 kernel is exactly as fast as the r115 phatk kernel on my 6990. I measured over 24 hours with one of them on the first and one on the second GPU core of that card; there was no significant deviation in the number of shares produced by each core, less than 10 shares difference.


I think I found the source of the memory leak in the previous RPCClient. If it works in my testing then I will be switching it back.

As for phatk2, it's faster than the phatk kernel for me using my 5870s, but keep in mind that the 69xx cards use VLIW4 instead of VLIW5.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 12, 2011, 07:16:25 AM
Version 1.6.0 has been released.

Changes:
1. Added the new phatk 2.2 kernel under the name phatk2 (use -k phatk2)
2. Default kernel changed to phatk2
3. Fixed RPC memory leaks and various other bugs
4. Added a timeout to ask() within the RPC code. This will definitively eliminate idling due to protocol bugs.
5. Moved project to GitHub
6. Small change to the version number scheme

The new GitHub URL for the project is here:
https://github.com/jedi95/Phoenix-Miner

Download:
Windows binaries (https://github.com/jedi95/Phoenix-Miner/archives/master)
Source code/Linux release (https://github.com/jedi95/Phoenix-Miner/tarball/master) (requires Python, Twisted, and PyOpenCL)


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: anty on August 12, 2011, 01:08:18 PM
The 1.6.0 version crashes my Ubuntu on one of my 5850. When I use the kernel on the other card, everything works fine. I now mine with phatk2 on one card and phatk on the other. This combination works.
I think it has something to do with the video output. I have the screen plugged in on the card that i mine with phatk2 with. The other one, that crashes doesn't have a screen or dummy plug.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nomnomnom on August 12, 2011, 06:36:50 PM
[...]
3. Fixed RPC memory leaks and various other bugs
[...]

Thank you very very much, I am gonna send you a bitcoin  ;)
But I am seeing a high rate of rejects now, not sure what is going on, but usually they were ~1%.

[12/08/2011 20:22:07] [317.82 Mhash/sec] [654 Accepted] [72 Rejected] [RPC (+LP)]
[12/08/2011 20:22:07] [318.03 Mhash/sec] [674 Accepted] [53 Rejected] [RPC (+LP)]

The 1.6.0 version crashes my Ubuntu on one of my 5850. When I use the kernel on the other card, everything works fine. I now mine with phatk2 on one card and phatk on the other. This combination works.
I think it has something to do with the video output. I have the screen plugged in on the card that i mine with phatk2 with. The other one, that crashes doesn't have a screen or dummy plug.

Interesting, I too have some problems since a few days on my 2x 5850 rig, one always locks up, sometimes after 2minutes
sometimes after 12 hours. (maybe since I changed to phatk 2.x?? this was also a few days ago...hmm)
Was already thinking I have some hardware problems, switched the 5850s to phatk 1 now, lets see if this is stable again.






Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 12, 2011, 07:09:46 PM

Thank you very very much, I am gonna send you a bitcoin  ;)
But I am seeing a high rate of rejects now, not sure what is going on, but usually they were ~1%.

[12/08/2011 20:22:07] [317.82 Mhash/sec] [654 Accepted] [72 Rejected] [RPC (+LP)]
[12/08/2011 20:22:07] [318.03 Mhash/sec] [674 Accepted] [53 Rejected] [RPC (+LP)]


The 1.6.0 version crashes my Ubuntu on one of my 5850. When I use the kernel on the other card, everything works fine. I now mine with phatk2 on one card and phatk on the other. This combination works.
I think it has something to do with the video output. I have the screen plugged in on the card that i mine with phatk2 with. The other one, that crashes doesn't have a screen or dummy plug.

Interesting, I too have some problems since a few days on my 2x 5850 rig, one always locks up, sometimes after 2minutes
sometimes after 12 hours. (maybe since I changed to phatk 2.x?? this was also a few days ago...hmm)
Was already thinking I have some hardware problems, switched the 5850s to phatk 1 now, lets see if this is stable again.


I currently have 8 5870s running on phatk 2.2. (same version included in Phoenix 1.6.0)

I have not seen any crashes or lockups since switching, so I don't think the kernel itself is broken. It might be that it stresses the GPU more than the older phatk kernel, which could explain the stability issues.

Either way, I didn't write phatk 2.2 so you may want to consider posting in the phatk thread for help.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on August 12, 2011, 07:58:57 PM
Hello jedi95,

first I'd like to thank you for going from SVN to Git and for today's fixes and addition.

With the current (as of the time of this posting) RPC code in Git I don't get the constant disconnects and reconnects as I had with the last SVN version; but I still get far more rejected shares, up from 1 or 2% to about 10%, compared to the code from SVN r101.

Also with the current RPC code the miner at some point just stopped mining, possibly because my Internet connection is behaving a bit like a moody child today. However this time it didn't reconnect when the line came back a short time later. Maybe your new idle timeout at work here? Or is this a misunderstanding on my part, I have to admit I haven't yet checked the code.

Keep up the good work!


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 12, 2011, 09:46:16 PM
Version 1.6.1 released.

Changes:
1. BFI_INT now enabled by default for phatk/phatk2
2. Added automatic failover to backup server if specified with -b
3. Additional memory leak fix for client3420.py
4. Fixed persistent connections

Download:
Windows binaries (https://github.com/jedi95/Phoenix-Miner/archives/master)
Source code/Linux release (https://github.com/jedi95/Phoenix-Miner/tarball/master) (requires Python, Twisted, and PyOpenCL)


Hello jedi95,

first I'd like to thank you for going from SVN to Git and for today's fixes and addition.

With the current (as of the time of this posting) RPC code in Git I don't get the constant disconnects and reconnects as I had with the last SVN version; but I still get far more rejected shares, up from 1 or 2% to about 10%, compared to the code from SVN r101.

Also with the current RPC code the miner at some point just stopped mining, possibly because my Internet connection is behaving a bit like a moody child today. However this time it didn't reconnect when the line came back a short time later. Maybe your new idle timeout at work here? Or is this a misunderstanding on my part, I have to admit I haven't yet checked the code.

Keep up the good work!

Could you run Phoenix with the -v option and post the last few log entries before the miner stopped working? The "idle timeout" simply ensures that ask() always returns after no more than 15 seconds. The idle issue on RPC was caused by a combination of the memory leaks and ask() never running its callbacks. By fixing the memory leaks and adding a timeout to ask() it should prevent the RPC protocol from hanging.

The increase in stale shares might be due to your internet connection not working normally. It also might be due to the keep-alive issue I just fixed in 1.6.1. Try 1.6.1 out once your internet connection is working normally again and see if you still have a high stale count.

Also, I am considering forcing a failover if the miner goes idle for more than 1 minute. This will make getting stuck idling impossible, (assuming the backup server is up) since the entire protocol object is destroyed and re-created when switching servers.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on August 12, 2011, 10:24:03 PM
There appears to be a problem running the phatk2 kernel on an ATI HD5450 under Windows.  It crashes the program once it starts the kernel.  I can run the kernel on my CPU (only as a test) and it works without crashing.  Any thoughts on this?  Phatk kernel works okay on it, but I would like the extra speed boost.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 12, 2011, 10:41:19 PM
There appears to be a problem running the phatk2 kernel on an ATI HD5450 under Windows.  It crashes the program once it starts the kernel.  I can run the kernel on my CPU (only as a test) and it works without crashing.  Any thoughts on this?  Phatk kernel works okay on it, but I would like the extra speed boost.

Have you tried specifying a WORKSIZE? The problem with phatk2 is that the kernel needs to know the worksize before it can be compiled. This prevents automatically setting the worksize to the maximum supported because that can only be detected once the kernel has been compiled. I added some code to phatk2 which checks if the worksize is supported by the device after compiling the kernel. If the worksize specified is too large then it will show an error. If setting a smaller worksize fixes the problem for you, then I will include this change in the next version.

See if specifying WORKSIZE=64 allows the kernel to run.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on August 12, 2011, 10:53:52 PM
There appears to be a problem running the phatk2 kernel on an ATI HD5450 under Windows.  It crashes the program once it starts the kernel.  I can run the kernel on my CPU (only as a test) and it works without crashing.  Any thoughts on this?  Phatk kernel works okay on it, but I would like the extra speed boost.

Have you tried specifying a WORKSIZE? The problem with phatk2 is that the kernel needs to know the worksize before it can be compiled. This prevents automatically setting the worksize to the maximum supported because that can only be detected once the kernel has been compiled. I added some code to phatk2 which checks if the worksize is supported by the device after compiling the kernel. If the worksize specified is too large then it will show an error. If setting a smaller worksize fixes the problem for you, then I will include this change in the next version.

See if specifying WORKSIZE=64 allows the kernel to run.
We have ignition!  Thank you so much!  I'll try to toss a donation your way...well, once I get enough to donate.  Worksize of 128 was max.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on August 13, 2011, 08:37:18 AM
Could you run Phoenix with the -v option and post the last few log entries before the miner stopped working? The "idle timeout" simply ensures that ask() always returns after no more than 15 seconds. The idle issue on RPC was caused by a combination of the memory leaks and ask() never running its callbacks. By fixing the memory leaks and adding a timeout to ask() it should prevent the RPC protocol from hanging.

The increase in stale shares might be due to your internet connection not working normally. It also might be due to the keep-alive issue I just fixed in 1.6.1. Try 1.6.1 out once your internet connection is working normally again and see if you still have a high stale count.

Also, I am considering forcing a failover if the miner goes idle for more than 1 minute. This will make getting stuck idling impossible, (assuming the backup server is up) since the entire protocol object is destroyed and re-created when switching servers.

Did another git pull this morning, and the stale shares issue is gone now, back to well below 1% for the last few hours. Jood job.

The miner hasn't yet locked up again so I can't tell if whatever problem that caused it is also solved. I'll add a -v as soon as I'm back at my machine tonight and then we will see.

About failover... I'm pointing the miner at my local mining proxy (cdhowie) which lives on the same machine. What do you think, should I use the same address as backup url, so even if not actually switching servers it will still reset the protocol if it's idle? Of course that wouldn't help with the proxy itself going down, but in my experience the proxy is very well behaved once you've figured out how to configure the underlying Apache for more concurrent threads and longer timeouts.

EDIT: One more thing, the phatk2 kernel produces a warning about variable t1 being defined but never used in the kernel (line 153 I think) on start-up, but then works fine as it seems. Is that normal and expected behaviour? Or am I missing out on an optimization that way?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 13, 2011, 09:44:58 AM

Did another git pull this morning, and the stale shares issue is gone now, back to well below 1% for the last few hours. Jood job.

The miner hasn't yet locked up again so I can't tell if whatever problem that caused it is also solved. I'll add a -v as soon as I'm back at my machine tonight and then we will see.

About failover... I'm pointing the miner at my local mining proxy (cdhowie) which lives on the same machine. What do you think, should I use the same address as backup url, so even if not actually switching servers it will still reset the protocol if it's idle? Of course that wouldn't help with the proxy itself going down, but in my experience the proxy is very well behaved once you've figured out how to configure the underlying Apache for more concurrent threads and longer timeouts.

EDIT: One more thing, the phatk2 kernel produces a warning about variable t1 being defined but never used in the kernel (line 153 I think) on start-up, but then works fine as it seems. Is that normal and expected behaviour? Or am I missing out on an optimization that way?

The t1 variable in phatk2 is a dummy to make the compiler behave a certain way. I'm not quite sure why defining a dummy variable results in better performance, but if you need more information about the OpenCL level tweaks I recommend asking in the phatk thread:

https://bitcointalk.org/index.php?topic=7964

From kernel.cl:
Code:
u W[124];
u Vals[8];

//Dummy Variable to prevent compiler from reordering between rounds
u t1;

//Vals[0]=state0;
Vals[1]=B1;
Vals[2]=C1;
Vals[3]=D1;


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: TeaRex on August 13, 2011, 11:50:03 AM
The t1 variable in phatk2 is a dummy to make the compiler behave a certain way.

I figured as much; my question was more along the lines of, if the OpenCL compiler (I use the one from the Windows Catalyst 11.7 drivers) complains about it being unused, will it still "behave a certain way" then, or will t1 just be removed and the desired behaviour doesn't happen.

Whatever, just answers this if you feel like it, I don't want to steal more of your time. Thanks again for such a great miner.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Remember remember the 5th of November on August 13, 2011, 10:32:43 PM
So, i heard that phoenix checks all the 2^32 noncespace. However i feel that the "documentation" about it is scarce at best.

What exactly are these avg samples? What are the best settings for my 5870 so i can make phoenix really scan all the nonces.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 14, 2011, 10:58:39 AM
So, i heard that phoenix checks all the 2^32 noncespace. However i feel that the "documentation" about it is scarce at best.

What exactly are these avg samples? What are the best settings for my 5870 so i can make phoenix really scan all the nonces.

Phoenix will automatically scan the entire nonce space as long as the server you are connecting to has some way of pushing work. (either MMP or RPC + LP) This is the reason Phoenix has a queue. When the queue size falls below the value specified with -q the miner requests more work.

The average samples are just how many samples are used for the hashrate display. Higher values will give a more stable hashrate display while smaller values will show the fluctuations in hashrate better.

Recommended settings for a 5870 right now:

-k phatk2 VECTORS BFI_INT AGGRESSION=8

You can increase AGGRESSION if you don't plan on using the computer while mining. Higher values will improve hashrate, but also increase the amount of lag. You will also need to specify which OpenCL device to run on using DEVICE=X.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: carlo on August 14, 2011, 11:24:01 AM
Hello,

the failover feature seems to be a bit slow, i tested it with a iptables drop. About 1-2 minutes than the miner switched the server.
Than i removed the iptables rule but the miner didnt switch back to the primary server, maybe i didnt wait long enough.
I would like to have a parameter that tells the miner: If there are more than X idles in the last Y minutes than switch for Z shares.

And there is another question: Is AGGRESSION=16 possible for a linux dedicated miner ? Whats the max value for AGGRESSION ?

Thx for the nice miner and your support.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on August 14, 2011, 03:32:45 PM
Hi, I was just wondering under what circumstances quad-vectors are used?  I happened upon the option VECTORS4 in the code and it's undocumented in your first post as to its use.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nomnomnom on August 14, 2011, 03:51:19 PM
Hi, it seems the mem leak is back in 1.61 ;D (at least for me)

In this commit https://github.com/jedi95/Phoenix-Miner/commit/7bc2bf7b452ce48b7f8be8f5d6b6a95db13e1c8f

I have changed client3420.py from line 788 till the end back to how it was in 1.60 (while protos ...)
and now it is not leaking anymore. Still seems to work fine, only my inet was down for a few minutes and it
somehow did not reconnect itself, but my watchdog script took care of that.




Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: carlo on August 14, 2011, 05:08:19 PM
Yes, 1.61 leaks memory.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 14, 2011, 07:30:41 PM
Hi, it seems the mem leak is back in 1.61 ;D (at least for me)

In this commit https://github.com/jedi95/Phoenix-Miner/commit/7bc2bf7b452ce48b7f8be8f5d6b6a95db13e1c8f

I have changed client3420.py from line 788 till the end back to how it was in 1.60 (while protos ...)
and now it is not leaking anymore. Still seems to work fine, only my inet was down for a few minutes and it
somehow did not reconnect itself, but my watchdog script took care of that.


Thanks for spotting that, I have committed a reverted client3420. Please test with this version to make sure it's not leaking. If that fixes it I will go ahead and release 1.6.2 with this change.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on August 15, 2011, 02:34:57 AM

Did another git pull this morning, and the stale shares issue is gone now, back to well below 1% for the last few hours. Jood job.

The miner hasn't yet locked up again so I can't tell if whatever problem that caused it is also solved. I'll add a -v as soon as I'm back at my machine tonight and then we will see.

About failover... I'm pointing the miner at my local mining proxy (cdhowie) which lives on the same machine. What do you think, should I use the same address as backup url, so even if not actually switching servers it will still reset the protocol if it's idle? Of course that wouldn't help with the proxy itself going down, but in my experience the proxy is very well behaved once you've figured out how to configure the underlying Apache for more concurrent threads and longer timeouts.

EDIT: One more thing, the phatk2 kernel produces a warning about variable t1 being defined but never used in the kernel (line 153 I think) on start-up, but then works fine as it seems. Is that normal and expected behaviour? Or am I missing out on an optimization that way?

The t1 variable in phatk2 is a dummy to make the compiler behave a certain way. I'm not quite sure why defining a dummy variable results in better performance, but if you need more information about the OpenCL level tweaks I recommend asking in the phatk thread:

https://bitcointalk.org/index.php?topic=7964

From kernel.cl:
Code:
u W[124];
u Vals[8];

//Dummy Variable to prevent compiler from reordering between rounds
u t1;

//Vals[0]=state0;
Vals[1]=B1;
Vals[2]=C1;
Vals[3]=D1;
Ironically, I believe this causes a cache miss and signals the automatic prefetch to engage.  Ideally, the prefetch would be called upon normally by a command in the code, but this is a means to have the processor pay more attention and pre-empt the required data.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: owowo on August 15, 2011, 06:59:02 AM
hi, is there a way to get hashrate, stales, etc. values and send it to munin (monitoring)? like for 1.5 there was a patch...


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Remember remember the 5th of November on August 15, 2011, 02:12:41 PM
Ok jedi95, but can you tell me a bit more of what exactly FASTLOOP does. Does it check less nonces or something?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bcforum on August 15, 2011, 02:25:16 PM
Ok jedi95, but can you tell me a bit more of what exactly FASTLOOP does. Does it check less nonces or something?

AGGRESSION sets the number of nonces hashed per kernel run.
FASTLOOP adjusts the number of nonces hashed per kernel run to try and get it under one frame time, ostensibly to improve desktop performance.

Ultimately, alll 2^32 nonces are tested in multiple kernel runs.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 15, 2011, 02:50:42 PM
Ok jedi95, but can you tell me a bit more of what exactly FASTLOOP does. Does it check less nonces or something?

AGGRESSION sets the number of nonces hashed per kernel run.
FASTLOOP adjusts the number of nonces hashed per kernel run to try and get it under one frame time, ostensibly to improve desktop performance.

Ultimately, alll 2^32 nonces are tested in multiple kernel runs.

That's not quite accurate regarding FASTLOOP.

FASTLOOP does not change the number of nonces per kernel execution. The purpose of FASTLOOP is to improve hashrate at low AGGRESSION. The WorkQueue isn't fast enough to directly feed the kernel without a performance drop once you go above about 30-50 executions per second. FASTLOOP requests larger NonceRanges from the queue and splits them up into smaller pieces.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: nomnomnom on August 15, 2011, 04:11:08 PM
Thanks for spotting that, I have committed a reverted client3420. Please test with this version to make sure it's not leaking. If that fixes it I will go ahead and release 1.6.2 with this change.

Looks much better I think,

this morning   - 306832 VSZ 74092 RSS
12 hours later - 380564 VSZ 74344 RSS

It has grown a little bit, but that's nothing compared to what was happening with earlier versions.

hi, is there a way to get hashrate, stales, etc. values and send it to munin (monitoring)? like for 1.5 there was a patch...
If it is the logtotext or xmlrpc patch, they still work, just that the patching fails and saves something to phoenix.py.rej.
But it is only one line which can be added manually to phoenix.py.



Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: owowo on August 15, 2011, 05:17:09 PM
ok, thx, then I have just to find that one little line for the xmlrpc.

EDIT: well. It was more the "one little line" actually it was four little lines. But it works.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 16, 2011, 01:17:10 AM
Version 1.6.2 released.

Changes:
1. Reverted some changes in client3420 to resolve a memory leak.
2. Added logging of share reject reason if provided by the server. (Only visible with -v)
3. Fixed phatk2 errors with BFI_INT disabled.
4. Added warning to phatk2 if WORKSIZE set too large.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: bboques on August 16, 2011, 06:42:47 PM
What does this mean?

bit@Bit:~$ aticonfig --odgc --adapter=all
aticonfig: This program must be run as root when no X server is active


I just bought a new computer, had a computer shop make it, and went through all the steps but I can't tell what number my GPUs are.  I am mining successfully on my CPU so it works, but why won't my cards show up?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 16, 2011, 07:13:38 PM
What does this mean?

bit@Bit:~$ aticonfig --odgc --adapter=all
aticonfig: This program must be run as root when no X server is active


I just bought a new computer, had a computer shop make it, and went through all the steps but I can't tell what number my GPUs are.  I am mining successfully on my CPU so it works, but why won't my cards show up?

You need an X server running in order to do basically anything with the ATI drivers in Linux. This isn't a problem with the miner. Without an X server running your GPUs are not visible to OpenCL so they can't be used for mining.

Find a setup guide for mining on Linux. I'm not sure if they go over setting up an X server though.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Seraphim401 on August 17, 2011, 02:38:17 AM
Wow!8-10 Mh/s more on my 4 miners combined.
Thanks a lot.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on August 17, 2011, 11:59:44 AM
Hey, I've noticed a major decrease in the number of shares since the last revision.  I don't know what you changed to fix the memory leak, but I've had the same hash rate with about 10x less submitted shares.  Granted, there was a difficulty change today, but 10x is still a lot.  Is there a means to re-download the older one?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on August 17, 2011, 06:04:01 PM
Well, looks like it's picked-up since last night.  It must have been a random streak of bad luck or something.  Sorry.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: pandemic on August 18, 2011, 01:20:56 AM
Does 1.6.2 use these mods?

further improved phatk OpenCL Kernel (> 4% increase) for Phoenix - 2011-08-11
http://bitcointalk.org/index.php?topic=25860.0

I started using 1.6.2 over 1.5 and haven't seen any increase.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: jedi95 on August 18, 2011, 06:51:41 AM
Does 1.6.2 use these mods?

further improved phatk OpenCL Kernel (> 4% increase) for Phoenix - 2011-08-11
http://bitcointalk.org/index.php?topic=25860.0

I started using 1.6.2 over 1.5 and haven't seen any increase.

Phoenix uses Diapolo's latest kernel (the one from the thread you linked above) for phatk. The phatk2 kernel is based on Phateus's phatk 2.2 from the original phatk thread. I modified the python portion of his kernel a bit though.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: hugolp on August 18, 2011, 10:03:27 AM
How does the backup pool works? Does it try to connect back to the main pool? How long does it take and can it be configurable?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Boing7898 on August 18, 2011, 10:19:33 AM
FATAL kernel error: Failed to apply BFI_INT patch to kernel! Is BFI_INT supported on this hardware?

Using a 5770 with 11.8 drivers on Windows.
phoenix.exe -u http:/worker:pass@pool.bitp.it:8334/ -k phatk2 PLATFORM=0 DEVICE=0 VECTORS FASTLOOP=false AGGRESSION=12 WORKSIZE=256


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on August 18, 2011, 11:27:54 AM
FATAL kernel error: Failed to apply BFI_INT patch to kernel! Is BFI_INT supported on this hardware?

Using a 5770 with 11.8 drivers on Windows.
phoenix.exe -u http:/worker:pass@pool.bitp.it:8334/ -k phatk2 PLATFORM=0 DEVICE=0 VECTORS FASTLOOP=false AGGRESSION=12 WORKSIZE=256
Fun fact: Your CPU is capable of running OpenCL as well.  Unfortunately, it doesn't offer the BFI_INT support that your card does.  Coincidentally, it also happens to be your device 0.  Try 1 instead.  ^_^


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: carlo on August 18, 2011, 11:29:00 AM
Backup function:

so far i have tested it a bit.
It seems that if the primary server is not available, the miner tries to use the backup server, sometimes my miner got stuck and it didnt switch to the backup server.
The normal switching time about 1-2 minutes.
When the miner pointed to the backup server it will not switch back to the primary.

i dont know if its configurable, i didn't see any parameters to make it more comfortable.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Boing7898 on August 18, 2011, 11:31:11 AM
FATAL kernel error: Failed to apply BFI_INT patch to kernel! Is BFI_INT supported on this hardware?

Using a 5770 with 11.8 drivers on Windows.
phoenix.exe -u http:/worker:pass@pool.bitp.it:8334/ -k phatk2 PLATFORM=0 DEVICE=0 VECTORS FASTLOOP=false AGGRESSION=12 WORKSIZE=256
Fun fact: Your CPU is capable of running OpenCL as well.  Unfortunately, it doesn't offer the BFI_INT support that your card does.  Coincidentally, it also happens to be your device 0.  Try 1 instead.  ^_^
No device specified or device not found, use DEVICE=ID to specify one of the fol
lowing

   
  • AMD Phenom(tm) II X4 965 Processor
[0 Khash/sec] [0 Accepted] [0 Rejected]

o.o
Where is my HD5770?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on August 18, 2011, 11:34:09 AM
FATAL kernel error: Failed to apply BFI_INT patch to kernel! Is BFI_INT supported on this hardware?

Using a 5770 with 11.8 drivers on Windows.
phoenix.exe -u http:/worker:pass@pool.bitp.it:8334/ -k phatk2 PLATFORM=0 DEVICE=0 VECTORS FASTLOOP=false AGGRESSION=12 WORKSIZE=256
Fun fact: Your CPU is capable of running OpenCL as well.  Unfortunately, it doesn't offer the BFI_INT support that your card does.  Coincidentally, it also happens to be your device 0.  Try 1 instead.  ^_^
No device specified or device not found, use DEVICE=ID to specify one of the fol
lowing

   
  • AMD Phenom(tm) II X4 965 Processor
[0 Khash/sec] [0 Accepted] [0 Rejected]

o.o
Where is my HD5770?
I got hungry and eated it?  Let me run a check myself to see if it's a driver related issue.  Had you been using 11.7 before hand since the drive is new?  And are you certain that you didn't download ONLY the driver and not the whole package?


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Boing7898 on August 18, 2011, 11:37:51 AM
FATAL kernel error: Failed to apply BFI_INT patch to kernel! Is BFI_INT supported on this hardware?

Using a 5770 with 11.8 drivers on Windows.
phoenix.exe -u http:/worker:pass@pool.bitp.it:8334/ -k phatk2 PLATFORM=0 DEVICE=0 VECTORS FASTLOOP=false AGGRESSION=12 WORKSIZE=256
Fun fact: Your CPU is capable of running OpenCL as well.  Unfortunately, it doesn't offer the BFI_INT support that your card does.  Coincidentally, it also happens to be your device 0.  Try 1 instead.  ^_^
No device specified or device not found, use DEVICE=ID to specify one of the fol
lowing

   
  • AMD Phenom(tm) II X4 965 Processor
[0 Khash/sec] [0 Accepted] [0 Rejected]

o.o
Where is my HD5770?
I got hungry and eated it?  Let me run a check myself to see if it's a driver related issue.  Had you been using 11.7 before hand since the drive is new?  And are you certain that you didn't download ONLY the driver and not the whole package?
:@

Yesterday I installed the 11.8 drivers, I think I had the 11.6 before. I installed the new Phoneix and now my HD5770 is gone.
I installed the whole package, the first link in the site.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: d3m0n1q_733rz on August 18, 2011, 11:41:00 AM
FATAL kernel error: Failed to apply BFI_INT patch to kernel! Is BFI_INT supported on this hardware?

Using a 5770 with 11.8 drivers on Windows.
phoenix.exe -u http:/worker:pass@pool.bitp.it:8334/ -k phatk2 PLATFORM=0 DEVICE=0 VECTORS FASTLOOP=false AGGRESSION=12 WORKSIZE=256
Fun fact: Your CPU is capable of running OpenCL as well.  Unfortunately, it doesn't offer the BFI_INT support that your card does.  Coincidentally, it also happens to be your device 0.  Try 1 instead.  ^_^
No device specified or device not found, use DEVICE=ID to specify one of the fol
lowing

   
  • AMD Phenom(tm) II X4 965 Processor
[0 Khash/sec] [0 Accepted] [0 Rejected]

o.o
Where is my HD5770?
I got hungry and eated it?  Let me run a check myself to see if it's a driver related issue.  Had you been using 11.7 before hand since the drive is new?  And are you certain that you didn't download ONLY the driver and not the whole package?
:@

Yesterday I installed the 11.8 drivers, I think I had the 11.6 before. I installed the new Phoneix and now my HD5770 is gone.
I installed the whole package, the first link in the site.
And you've restarted your computer since then?  I know that restarting isn't usually necessary with the ATI drivers, but it will help to get the OpenCL software properly in place.


Title: Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Post by: Boing7898 on August 18, 2011, 11:42:25 AM