I asked a few posts ago if you could change something in your code, I'm not asking you to agree just an answer and your opinion if you don't mind giving it.
I got lost in the angry discussions following it. Was it the IP address issues, the working with a proxy server, the requiring built-in support for merged mining, the mining on multiple block chains, your one pool that doesn't like cgminer, or something else? In summary I'm not abject to fixing issues, but I don't work around unique pool designs and will never support multiple different block chains (that's not the same as merged mining, I know). That leaves the others up to discussion.
|
|
|
Quite a number of people have suggested to me adding a donation option to cgminer as an opt-out feature. This would redirect a nominal amount of shares, say 0.5% to myself, which could be disabled on the command line. I've been resisting taking such an approach, but how do other people feel about that? It would certainly make me happier to keep supporting this project.
|
|
|
Yes I haven't put anything explicitly in place separating out management of GPUs from the cards only being mined on. I have to fix that.
|
|
|
NEW VERSION: 2.0.4
Hi, pre-built package for Ubuntu 64bit doesn't support any of the GPU fan/speed tuning options. That said, there's a BTC coming your way : very nice miner. Oops, my bad. * ckolivas quietly replaces the packages before anyone else notices. Redownload please
|
|
|
NEW VERSION: 2.0.4
- Confused Longpoll messages should be finally fixed with cgminer knowing for sure who found the new block and possibly avoiding a rare crash. - Display now shows the actual hash and will say BLOCK! if a block is deemed solved. - Extra spaces, which would double space lines on small terminals, have been removed. - Fan speed change is now damped if it is already heading in the correct direction to minimise overshoot. - Building without opencl libraries is fixed. - GPUs are autoselected if there is only one when in the GPU management menu. - GPU menu is refreshed instead of returning to status after a GPU change.
Thanks to Kano for some of these changes.
|
|
|
Thanks for donation. I know about PID controllers, I just think it's just far too complicated to bother trying to implement, as I said in git issues. Most people find the simple approach works fine. I'd happily take well done patches implementing it though. I will damp is slightly next release.
edit: It could also simply be that your hardware doesn't accept the smaller values being passed to it and it ignores them till it gets some coarse value it accepts.
|
|
|
It's a target temperature. It tries with fan to keep it under target temperature and if that fails with gpu throttling. The gpu throttling happens a bit later, at target temp + hysteresis. If it hits "overheat" temperature it immediately throttles gpu speed to lowest. You probably want something like: --temp-target 75 --temp-hysteresis 10 --temp-overheat 90
Note however that it will NOT raise GPU speed if it's above the target temp.
|
|
|
I better check that then, aticonfig i assume.
This is why cgminer reports back the actual speeds to you after you set them on the fly in the menu, as the driver can lie, saying it set the speed fine but the card just refuses it.
|
|
|
Is this a windows only problem perhaps? CPU load under ubuntu is 0.5% while producing 320MH/s (5850). If you want to reproduce the nice high CPU loads on linux as well, you can too, by upgrading from the 11.6 catalyst driver to 11.7 or 11.8.
|
|
|
Actually the 1/3rd rule has proven to be sheer coincidence. There is no obvious relationship between the GPU and memory clock speeds that equates to any 1:3 equation. It just happens that there's some kind of performance peak if you lower memory speed (on some, not all) ATI cards to ~35-40% of the speed, not to mention the heat advantages.
|
|
|
Try clearing out your drivers entirely with some kind of driver removal program whatever they're called on windows, and install the 11.6 driver instead.
|
|
|
1st, wanted to thank you again for your program. sent ya another donation, 1.1122113 BTC.
those days of fiddling with clocks and fans with external programs are but a distant memory now. made a batch file with 4 choices (quiet while using computer, quiet while not using it, flat out while using, flat out while not using) thats so simple my wife can use it. tamed the day to day main computers mining perfectly. no more wondering if the card would overheat during hot days, or wasting fan cycles or wasting hash rate. cgminer keeps it maxing out hash rate given specific noise and display smoothness parameters now. that auto GPU clocking is Da Bomb!
Thanks man, and thanks a lot for donation
|
|
|
I think I know what I do <_<
oh, I'm just posting it in this thread for my own reference, lol an ideal algorithm would look at the rate of change of temperature if (temp < ga->targettemp && rate > 0) { } //do nothing and wait until temperature stops rising if (temp < ga->targettemp && rate <= 0) { newpercent = ga->targetfan - 5; } if (temp > ga->targettemp && rate => 0) { newpercent = ga->targetfan + 5; } if (temp > ga->targettemp && rate < 0) { newpercent = ga->targetfan + 1; } //still increase, but slower or something like that if you include the hysterisis as well for slower dropping of temperature when close to the target Oh yes I know only too well how to make a control system. Considered it, thought it was too complicated, and decided that a simple approach was perfectly fine. After some initial relatively safe overshoot, it settles down anyway. So I don't see the point, but feel free to play with your own code
|
|
|
I think I know what I do <_<
|
|
|
I got a new graphics card, and wow, the fan was retarded on it, it wouldn't turn on until 95 degrees!
That's why I tried out the auto-fan feature in cgminer, and it works very well! Thanks for this! It kind of overspins for a little while, underspins for a little while, but EVENTUALLY finds the RPM to keep my GPU at 75 degrees or so (which is ~40 percent) What's the commandline argument to start the fan at 41 percent?
May I suggest that cgminer display the fan as a percentage, instead of RPM? It would take less space
Yeah most fans are designed for low noise and not calibrated to run GPUs flat out the way we do while mining. Sounds like it does precisely what you need. --gpu-fan 41 will set it at that, but if you use auto-fan, which I recommend you do, do not pass it any parameters as default usually works best. The RPM is safer to demonstrate in case the fan is reportedly set to a percentage but has jammed, failed in some other way and the rpm would read 0. Safe is my primary concern. Cards that do not support RPM monitoring, cgminer will show the percentage instead.
|
|
|
New version: 2.0.3 - mainly bugfixes, links in top post.
- Various modes of failure to set fanspeeds and adl values have been addressed and auto-fan should work now on most hardware, and possibly other values which previously would not have worked. - Fixed a crash that can occur on switching pools due to longpoll thread races. - Use ATISTREAMSDKROOT if available at build time. - Fanspeed management is returned to the driver default on exit instead of whatever it was when cgminer was started. - Logging of events deemed WARNING or ERR now will display even during periods where menu input is being awaited on.
|
|
|
Thanks very much Gilles . Could you be so kind as to email me patches for these instead or provide a git branch that I could pull off? That would be most helpful.
|
|
|
You do not need to go into quiet mode to be able to log. In fact, you should be able to still log stderr while having the curses formatted text output as cgminer is designed to do those independently. Yes, the DEAD in uppercase should only appear when a device is declared dead.
|
|
|
Holy moly this software is amazing! Why didn't I get off my lazy butt and trying this out a long time ago instead of sticking with guiminer? I just replaced guiminer AND Sapphire Trixx with *one* program. And I'm able to use just one mining account for all GPU's instead of separate like other programs. *happy dance*
Lovely feedback, thanks
|
|
|
Just sent you a 3.63 donation!
Also, an issue I just noticed with the program yesterday (I'm using 2.0.2) was a scenario where both mining threads went dead, and after I tried manually restarting the GPU with that feature you already have built in, it didn't help. However, then I closed out cgminer and opened it back up, and it had no problems mining again. Based on this, can you build into the program an option to have the program automatically restart itself if the mining threads go dead? Of course, it should first try to automatically restart the GPU, but doesn't it already try this? I think this latter complete restart could help work around a lot of issues where mining still gets stuck. Thanks!
Thanks very much for your donation! I can't do that because there are many scenarios where a dead device implies a driver hang. Restarting cgminer in that circumstance will crash everything since the problem is at such a low level that the system would normally need a reboot. The idea is to only soft restart devices that have soft failed and then recover. The default behaviour has to be the least harmful. Some people grep the output of cgminer and force a restart if they get the DEAD message.
|
|
|
|