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 binariesSource code/Linux release (requires Python, Twisted, and PyOpenCL) SVN: http://svn3.xp-dev.com/svn/phoenix-miner/ |
|
|
|
Please change the cookies you are storing to be "session" cookies - they will expire at the end of the browser session instead of at a specific date. This will close a security hole where someone that has access to a person's PC can access and change the bitcoin address without authenticating. I'll think about this as an option, not enabled by default because people don't like it. Also, e-mail confirmation is mandatory for bitcoin address change now. also: can I hide my 2nd/3rd etc worker password? cus they're visible, only the main worker's pass is hidden. You could make them all hidden and make a button to retrieve the passwords via email. What's the point? The only thing someone can do with the worker password is mine more BTC for you.  |
|
|
|
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. |
|
|
|
So many people say lower memory clock speed up mining speed.
I am using Win7 x64 with 11.4 drivers and the default SDK (I am guessing it is 2.4. How to check it to make sure?).
Running Phoenix 1.47 and poclbm kernel.
With sapphire 5850, core at 840, I lowered the memory clock from 1000 to 300.
What I saw was a 3-6MH/s DROP in hashing rate. This is opposite of what everyone else is getting.
Just to make sure, how do you guys measure the hash rate?
I just look at the command line outputs, where it updates the hashrate every second or so.
With SDK 2.4 you should also try the phatk kernel. (thread is linked in the first post of the Phoenix miner thread, and it's included in 1.48) |
|
|
|
Hi guys,
Just got into mining a few days ago (from the Reddit post), and I've been mining on my main video card (used for gaming & dual monitors) GTX570 (112.5 Mh/s),
but I am thinking about pulling my brother's old 4870 out of the closet and mining on that as well, however I do not know what to expect from trying to install and use
an AMD product for OpenCL alongside my main NVidia card with CUDA.
Has anyone ever experimented with this combination and had any success?
Any suggestions?
Thanks!
This works fine, I'm currently running a GTX 580 and 2 5870s in my main system. CUDA will work exactly as before, but for OpenCL you will need to specify the OpenCL platform that the miner should use. |
|
|
|
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. |
|
|
|
You should be able to recover the cards by flashing them from a bootable USB stick or CD. IIRC the 3D clocks don't get applied until the driver is loaded by the OS. (which would explain crashing just before you get to the desktop)
You could also try booting in safe mode, since that doesn't load the GPU drivers.
Trying that now jedi95, thanks again! Edit: Ok so I was indeed able to boot into windows safe mode, but unfortunately I was unable to flash the cards using RBE inside of windows safe mode due to administrator rights restrictions. I am able to load the RBE software as an administrator, but it loads the WinFlash utility separately and that needs to be run as administrator as well. I tried to edit the compatability options of the winflash utility to force it to start running as an administrator but apparently "you cannot add to compatability options in safe mode, only disable them". Which makes sense I suppose.... Ok now I am going to reboot into windows using only one good working card, change both RBE and WinFlash's compatability options to force them to start as administrator, and then boot back into safe mode with the dead cards. Wish me luck! Edit: No luck. Even though both programs started in safe mode, I received the same message... perhaps another .exe file somewhere requires to be an administrator as well but I am not going to bother looking for it... On to trying to flash the bios using atiflash and a usb drive. If safe mode works you could uninstall the drivers then reboot in normal mode. However, it's probably easier to try running winflash as admin by itself instead of going through RBE. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
Usually this means there are no devices with OpenCL support. Did you try updating the drivers? The 9600 supports OpenCL but older drivers don't have it.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
You should be able to recover the cards by flashing them from a bootable USB stick or CD. IIRC the 3D clocks don't get applied until the driver is loaded by the OS. (which would explain crashing just before you get to the desktop)
You could also try booting in safe mode, since that doesn't load the GPU drivers.
|
|
|
|
|
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.
|
|
|
|
Jedi95 there something can be done about this?  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. |
|
|
|
5xxx maxes out at a worksize of 256.
My dual 5870 (w/o CF bridges) maxes out at WORKSIZE=128. Nope, that too maxes out at 256. What I said was 768 simply is not valid for 5xxx hardware. Phoenix should output the error OpenCL is returning instead of covering it up. I'll probably add this in the next version, but for now it just uses the maximum supported if you enter a higher value. |
|
|
|
|
Be careful when overvolting 5970s. The stock cooler doesn't provide sufficient cooling for the VRMs if you up the voltage too much. This will cause the card to downclock and reduce your hashrate. Personally I wouldn't use more than 1.1v for the core voltage.
Another thing you can do to keep the temps down is underclock the memory to 300MHz. With Phoenix this won't reduce your hashrate at all. I'm not sure how to do this on Linux other than flashing the BIOS though.
|
|
|
|
|
This could be very useful if implemented into a kernel for Phoenix. Especially when combined with MMP which supports sending meta to the server. That would allow for some interesting remote monitoring capabilities. Right now I have to run another script alongside the miners to update the temps.
|
|
|
|
I've found a bug:
if I stop bitcoin and I check the hashrates of my miners via JSON-RPC request I see about 20% slower rates than their maximum however their real hash rates are 0.
I don't know much about python. Has anyone any idea how to fix this?
This is a bug in Phoenix. Right now it only displays 0 Mhash/sec in the GUI. It still continues to push the last hashrate in the META. It will be corrected in the next version. |
|
|
|
how hard is it to create an MMP?
Not very hard, you just use MultiMiner: http://bitcointalk.org/index.php?topic=5210.0MultiMiner also accepts RPC connections, but it lacks long polling so MMP is highly recommended. The only miner that supports MMP right now is Phoenix. |
|
|
|
|
Show Posts
