Well, I got half the 30 BTC bounty, thanks! 15 to go...
As soon as I am paid for today's mining, I'll send you my 5  I've compiled your 2.0.9 and it hasn't crashed on me yet  I haven't really done anything with the RPC yet though. Maybe tomorrow on the train I'll get a little something written. Thanks. Do be aware 2.0.9 is a development release and I won't be releasing an "official" version till I'm sure it all works fine. There was a race on longpoll switch that has been a bitch to nail down but I hope I'm there now. Also, a fried motherboard in my main miner will significantly slow down the final release  |
|
|
|
|
Well, I got half the 30 BTC bounty, thanks! 15 to go...
|
|
|
|
I just tested connecting to your pool: [2011-12-24 08:00:33] Pool 0 http://api.bitcoin.cz:8332 active [2011-12-24 08:00:33] Long-polling activated for http://api.bitcoin.cz:8401 Then I waited for a longpoll which worked. Seems to work fine as far as I can tell. Yes, that looks fine. Great that it works! Indeed, but it doesn't explain the bug report occurring in the first place, unless they entered the pool details wrongly into cgminer. |
|
|
|
Received, thanks |
|
|
|
After auditing the code, the API branch has been merged into my cgminer master branch now. Please refer any further API discussion to the regular cgminer thread.
There is 30 BTC pledge towards integration into mainline. Do you want it sent to your signature address? 148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq That will be fine, thanks. |
|
|
|
I use auto-fan to keep the card temp steady at 70C. I've noticed that cgminer sets the fan high when it starts (for safety?) and then slowly works it down to the speed that maintains temp. I don't like that as it's really noisy for a while. I modified my code here to set the fan to moderate 55% value at start because that's not noisy but high enough that the gpu doesn't start hot, and it's close to what I end up running long term - usually 55-65% depending on how hot a day it is here. You know that if you specify a single fanspeed and --auto-fan, then it will start at the fanspeed you set already instead of 85% ? |
|
|
|
Thanks. I didn't say "dirty" I just said unique, and there really is no "standard" for anything really, just precedence, and deepbit was first. Their precedence was just a url, not a different port. Anyway I'll think about it since this is really just providing better support for slush and has no influence on any other pool.
"Just a URL" - it's exactly the reason why I said I'm following deepbit's specification, as I'm using standard URL in LP response. And yes, port is the part of URL, too. Sorry to hear that it's problem in C++, but it's currently almost impossible to change implementation to run on the same port. I hope you'll resolve the issue on your side and it will run without any problem. I just tested connecting to your pool: [2011-12-24 08:00:33] Pool 0 http://api.bitcoin.cz:8332 active [2011-12-24 08:00:33] Long-polling activated for http://api.bitcoin.cz:8401 Then I waited for a longpoll which worked. Seems to work fine as far as I can tell. |
|
|
|
|
After auditing the code, the API branch has been merged into my cgminer master branch now. Please refer any further API discussion to the regular cgminer thread.
|
|
|
|
For those who got less hash with 12.1 with cgminer
Try worksize 64 with vectors 4
That's interesting because each GPU will report what its "preferred vector size" is, and often it comes out to 4, yet despite that, virtually all GPUs had much better performance (with the older SDK) and 2 vectors. Perhaps they live up to their promise now? |
|
|
|
I've sync'd my local code to 2.0.8 now and the values for gpu settings are taken from ADL variables. This has been working for me and I think likely prevents a zero value ever getting written. I should make a patch and get this out to a few others for testing.
My code also has a display option for "fan in percent" as well (which is what I much prefer). If the RPM drops to zero it overrides percent and shows 0 RPM, just to be safe since apparently sometimes percents don't show correctly when the fan stops.
Percent values are only what PWM settings the card is sending to its fan, and may have absolutely no correlation with what RPM the fan is actually running at. That's why it defaults to showing RPM instead which is actually the detected speed. On the other hand, the idea to show RPM when it's zero is a good safety mechanism, but I assume you take into account that many cards don't report RPM speed? |
|
|
|
|
A value of 0 in the configuration implies "not set" which means cgminer does not try to set the value it has received.
|
|
|
|
|
I believe the problem is actually that the vddc is saved as a range instead of a single number. I will look into it at some stage...
|
|
|
|
Well I think the 100% CPU usage is not a fault in AMDs drivers but it comes from how I process the OpenCL buffer, which holds nonces.
To speed up kernel execution I removed control-flow (if-statements) from the kernel, but now check the whole buffer for valid nonces, even if there are none ... this leads (my guess) to an endless processing loop in Phoenix, which is the drawback of the kernel changes.
Just as a data point, cgminer does not do this. It does not check the whole buffer. |
|
|
|
ckolivas: Yes, it's still using another port, because long polling daemon is separate application. There's nothing 'dirty' on such approach; if your miner have correct support for long polling standard and follows redirects of URL correctly, it will work.
Thanks. I didn't say "dirty" I just said unique, and there really is no "standard" for anything really, just precedence, and deepbit was first. Their precedence was just a url, not a different port. Anyway I'll think about it since this is really just providing better support for slush and has no influence on any other pool. |
|
|
|
If he ssh's into the machine with X forwarding active,
Aaah, gotcha. But why on earth would you forward X for mining? Because the GPU driver through X does the mining. i.e. you must use X and the GPU driver to mine with. They are absolutely essential (at this stage). |
|
|
|
|
I've temporarily pulled Kano's changes into a new api branch on my own git tree. Pending further testing and auditing by myself, it will eventually be pulled into the master branch and be incorporated into the next release whenever I get around to it. Thanks so very much for taking on this task, Kano.
|
|
|
|
|
Is this pool still using a port for its longpoll instead of a /lp or similar type URL? I need to know if I have to special code support for this unique approach to longpoll that no other pool uses.
|
|
|
|
Hi,
Just installed CGMINER 2.08 on a windows rig with a 5870 overclocked to 990 MHZ, i was getting 400 Mhash/s.
Quite low i thought, so i tried 2.05.
Now i'm getting 440 MHash/s.
Did some code changed from 2.05 to 2.08 that can get this difference in performance?
No |
|
|
|
If one of my GPUs dies, cgminer hasn't ever successfully restarted it. If I hit "q" to quit, it hangs. I've just been rebooting the server and that works easy enough. 5970 and a 5830 on BAMT. There are numerous potential modes of failure for a GPU, some soft hangs that cgminer successfully restarts, some soft hangs that cgminer cannot restart, and some hard hangs like the one you describe. I spent literally a month trying to find the right balance with the restarts such that more than anything else, cgminer would not immediately crash the machine or stop mining with whatever was remaining. The restart we're talking about above, however, is for when cgminer voluntarily stops the GPU due to overheat, not because the GPU has stoppped responding to the code. This should be safe to restart at any time, PROVIDED I modify the code to know the GPU has not died, but has been voluntarily shut down. It will take some more code to do this of course, but I'm waiting for the RPC mods by Kano to be completed before doing anything more to cgminer. It makes it much easier for him to hack on if the code target does not move. Also, Merry non-denominational festive season, everyone. |
|
|
|
|
Show Posts
