Running Win 7 x64, with 11.4 catalyst, and the default SPP that came with it. GPU 830MHz, Memory 900MHz. My settings on the miner: Start /DD:\phoenix-1.3 phoenix -u http://xxx@xxx.com_3:xxxx@deepbit.net:8332/ -k poclbm DEVICE=0 VECTORS BFI_INT AGGRESSION=7 Changing the Aggression anything higher than 7 doesn't make any difference for me. What changes do you guys suggest for a 5850 to get higher hash rates? I've seen people running 5830 over 300MH/s, and 5830 has far fewer shaders. I am still trying to figure out how to lower memory speed below 700 without crashing the system. Few things: 1. Update to Phoenix 1.4, there is a bug with RPC reconnecting to LP enabled servers in 1.3 2. I have a 5830 under similar conditions (Win7 x64 + 11.3 + SDK 2.2) and it gets 291 Mhash/sec overclocked to 980Mhz. 3. With AGGRESSION=7 you might try adding FASTLOOP to your command line. Note that this is actually bad if you decide to increase the AGGRESSION to 9 or higher. 4. Most of the users who are getting higher rates have their cards overclocked above 900MHz core. |
|
|
|
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: 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)
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
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) |
|
|
|
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) |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
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? |
|
|
|
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= |
|
|
|
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. |
|
|
|
|
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
|
|
|
|
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. |
|
|
|
5870 @990/300 getting 414 M hash/sec with Phoenix (-k poclbm DEVICE=0 VECTORS AGGRESSION=13 BFI_INT) .
I´m using:
win 7 64
Catalyst 11.4 prerelease
SDK 2.4
It would be nice if everyone posted their config soft, commands in Phoenix and hard.
Well I guess I have quite a bit of data to contribute here: Linux: (all these use VECTORS BFI_INT AGGRESSION=11) 425.5 Mhash/s - 5870 @ 960/300 (Ubuntu 10.10, driver 11.2, SDK 2.1) 419.0 Mhash/s - 5870 @ 945/300 (Ubuntu 10.10, driver 11.2, SDK 2.1) 412.5 Mhash/s - 5870 @ 930/300 (Ubuntu 10.10, driver 11.2, SDK 2.1) 305.0 Mhash/s - 5830 @ 980/300 (Ubuntu 10.10, driver 11.2, SDK 2.1) Windows: 436.5 Mhash/s - 5870 @ 1030/300 (Win7 x64, driver 11.2, SDK 2.2) (VECTORS BFI_INT AGGRESSION=10) 394.5 Mhash/s - 5870 @ 930/300 (Win7 x64, driver 11.2, SDK 2.2) (VECTORS BFI_INT AGGRESSION=10) 393.5 Mhash/s - 5870 @ 930/300 (Win7 x64, driver 11.3, SDK 2.4) (VECTORS BFI_INT AGGRESSION=8 FASTLOOP) |
|
|
|
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. |
|
|
|
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%? |
|
|
|
|
Show Posts
