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. |
|
|
|
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? |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
***Item already bought***The fan in one of my 5870s died and I need a replacement. I am only interested in the reference cooler, no aftermarket stuff please. I would also be willing to buy a broken card with a working cooler. To make sure it's clear what I am looking for, I mean this style of cooler: 
|
|
|
|
Ok, many thanks for your reply.
So in other words , when I see the 'not sending' I can think of that as hashes that didn't solve the block? When I see one that is accepted that means that I solved the block and thus will get the reward?
again, thanks for helping a newbe.
You can look at all of the "not sending" results as "shares" that didn't solve the block. It's expensive performance wise to have the OpenCL kernel check full difficulty. Since the number of difficulty 1 results is relatively small (one every 10 seconds or so on a fast 5870) it's easier to just check full difficulty on the CPU. Anytime you get an accepted it means you found the solution to a block. This doesn't guarantee that the block will be valid though, only that your bitcoin RPC server accepted it. In most cases this should mean a valid block though. |
|
|
|
Ok, call me paranoid but I would like to ensure that this is expected behavior.
I am mining to my local bitcoin application running with the -server flag with the phoenix miner. I have verbose on as you will see from the output;
[08/05/2011 20:47:55] Result didn't meet full difficulty, not sending
[08/05/2011 20:48:07] Result didn't meet full difficulty, not sending
[08/05/2011 20:48:08] Server gave new work; passing to WorkQueue
[291.65 Mhash/sec] [0 Accepted] [0 Rejected] [RPC]
The 'Result didn't meet full difficulty, not sending' is making me nervous as I want to ensure that everything is actually working. I don't see the accepted raising as I do when I am connected to a pool and I don't to mine locally for weeks/months, only to find out that it wasnt working.
Does anyone else see this and if so, have you won a block?
thanks in advance.
This is working exactly as designed. The OpenCL kernel returns results that meet a difficulty of 1. (H == 0) Since you are solo mining the only results that will be sent to the server are the ones that meet the full difficulty. (like 109K at the moment) In your case "accepted" would mean that you found a full difficulty result and that your local bitcoin accepted it. You will see a LOT of these results not being sent before you get lucky and find a full difficulty one. |
|
|
|
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. |
|
|
|
|
I can see 2 possible issues here:
1. From your other thread - The GPU might not be visible to OpenCL and this will obviously cause the patching to fail.
2. One of the devices you selected is the CPU, which is either device 0 (on SDK 2.3 and older) or the last device on 2.4.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
The quad 5870 setup stats can be viewed here: (host alpha)
Multiminer cluster status I'm running a single 5870 right now (on poclbm not overclocked) and I'm only getting 290mhash out of it. Jedi95 can you or someone please tell me how to get it up to the speeds listed at this site? You are probably using an older version of poclbm that doesn't have BFI_INT support. I also have the cards overclocked to the highest I could get on stock voltage. (930-1020MHz) You can either update to the latest poclbm or try Phoenix: (developed by CFSworks and myself) Phoenix Miner |
|
|
|
Nice, maybe add wattage used too to calculate electricity costs.
That's a lot harder to do since wattage can't be obtained from internal sensors like temperature can. It's also meaningless for me since I don't pay for electricity. |
|
|
|
Wow, nice setup jedi! You must've had a heck of a deal on those 5780's to get four of them, and a complete build, under $1070. Also, you're getting more MH/s than any of the listings on the wiki... is the wiki just horribly outdated? Anyone want to update it?
The quad 5870 setup stats can be viewed here: (host alpha) Multiminer cluster statusI think the wiki page is outdated, since there has been a large speed increase lately thanks to BFI_INT enabled miners. |
|
|
|
Wow! Thanks for the great info everyone! Does anyone know if this motherboard: Motherboard: MSI 790FX GD70, but any 4xPCI-E AMD that allows 4 dual-slot GPUs to fit works - $185
Some alternatives are the newer MSI 890FX GD70 (more expensive, easier to find) and the much older MSI K9A2 Platinum. (very hard to find) would be capable of supporting 4x 6990's down the road should I want to upgrade? Thanks! It's possible to fit 4x 6990 in that motherboard, but cooling those cards is another matter entirely. Without something like PCI-E extenders there is no way that 375W cards are going to be able to function with highly restricted airflow. |
|
|
|
This setup worked great for me in terms of both Mhash/$ and Mhash/watt: GPUs: 4x reference design 5870s. These can be found used for about $200, but the downside is finding them with an intact warranty is difficult. If you prefer having a warranty you can substitute 4x 2GB 6950s and unlock them to 6970s. With recent mining developments (BFI_INT) the 69xx cards are more attractive than before. At $270 you can buy 4 of these for less than 2 6990s. Cheap 5850s are also an option, but most of the ones you can buy new don't use the reference cooler and as a result you can run into heat problems with a quad GPU setup. If you want to go the 2x5850 route you can substitute the motherboard and PSU for cheaper ones. CPU: Cheapest AMD Sempron you can find - $39You can go cheaper if you don't mind buying a used motherboard, but sadly AM2 4xPCI-E motherboards are extremely hard to find with an intact warranty. RAM: Any cheap 1GB stick, you don't need more than that for a dedicated miner - $13Memory bandwidth on the host machine makes no difference for GPU mining. Motherboard: MSI 790FX GD70, but any 4xPCI-E AMD that allows 4 dual-slot GPUs to fit works - $185Some alternatives are the newer MSI 890FX GD70 (more expensive, easier to find) and the much older MSI K9A2 Platinum. (very hard to find) PSU: Corsair TX950 - $150This is just personal preference, but in my experience using cheap, low-quality PSUs for 100% load 24/7 applications is a bad idea. Obviously this is up to individual user to decide, but make sure that the PSU can support 8x PCI-E 6-pin connections. (using the molex -> PCI-E adapters is fine) HDD: Cheapest you can find, alternatively you can use a USB stick or boot from LAN. I'm not going to go into specifics here since there are many alternatives to buying a new HDD for each node. Just keep in mid that you don't need much HDD space for a dedicated miner. I was able to build my quad 5870 setup for $1070 and it produces 1.7 Ghash/sec while consuming about 900W from the wall. Overheating and noise are not a problem, I can run the cards at 65% fan and get temps in the mid 70s. However I had an extra HDD and RAM on-hand already, so expect to pay more this. |
|
|
|
Thank you for the very detailed response, jedi!
If it is possible to run 2 hashes instead of 1, why not 3 or 100 hashes instead of 1?
I noticed that my first GPU miner seemed to work (without vectors) just until I began running the second GPU miner. Then the first miner shut down and the second one did soon afterwards.
The reason you can't run run an unlimited number of hashes per thread is the number of available GPRs. (general purpose registers) At some point the bottleneck shifts from ALU operations to GPR availability, and you end up with reduced performance. |
|
|
|
I was just pulling my hair out for a few minutes because all of my cards were showing the dreaded "verification failed, check hardware" on the command line interface after just a few seconds of mining. Thank goodness grinder made this post here: http://bitcointalk.org/index.php?topic=1334.msg97772#msg97772I added -v (vectors) to my poclbm variables and it began to generate flawlessly. Going on 20 minutes now with no "verification failed" messages (fingers crossed!). Can anybody explain to me what exactly "vectors" are? Am I still using the BFI_INT calculations with vectors on? (I am using the latest POCLBM version which I believe calculates BFI_INT now as well?) With vectors enabled each thread on the GPU runs 2 hashes instead of 1. This improves performance on ATI hardware because it gives the compiler more opportunities to extract ILP (Instruction-level parallelism) compared with only running a single hash. The latest poclbm always uses BFI_INT on ATI/AMD hardware if cl_amd_media_ops is detected. I am not sure why enabling vectors can "fix" the problem when all it does is run 2 hashes per thread on the GPU instead of 1. This may be a problem with poclbm's BFI_INT patcher, which I haven't looked at in detail yet. I don't think the OpenCL kernel itself is the problem because as m0mchil mentioned it is virtually identical to the OpenCL kernel used in Phoenix now. I have yet to see any users have this problem without vectors on Phoenix though, which is why I suspect the BFI_INT patching code. That said, vectors should be faster on most ATI hardware anyway, so this shouldn't be a problem for the majority of users. |
|
|
|
|
Show Posts
