OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[simonk83]

Hmm.   So I have 4 GPUs at the mo.  Here's my bat file:

start /B /affinity 8 cgminer -o http://127.0.0.1:8337 -u simonk83 -p x -I 9 --auto-fan --auto-gpu --gpu-engine 930,930,900,930 --gpu-memclock 305 2>"%date:~4,2%-%date:~7,2%-%date:~12,2%%time:~0,2%-%time:~3,2%-%time:~6,2%.log"

That 3rd GPU I set to 900 as it runs really hot (stock is 850).    Everything has been fine up until now as the temps have been cool in my house, but now that things are starting to heat up I've noticed an issue.     This card is hitting over 80 occasionally, and I've now just noticed that cgminer has throttled it back to 850.    I was under the impression though that it'd scale it back up to 900 once the temps dropped under the overheat temp (which is 85 isn't it), but it's not doing that.     It just stays at 850mhz.

Is it waiting for the temps to drop to (or under) 75 before it scales the clocks back up?    If that's the case, it's probably not going to happen   Is it possible to change it so that it scales the clocks back up when it drops under the overheat threshold (85)?   I would have thought that's what it's supposed to be doing, but it's not (in my case at least).

Ta

EDIT:  It's done it to GPU 2 as well.  Currently at 885mhz at 78 degrees.  Should be at 930.

EDIT2:  Just restarted, and it seems to start throttling the GPU at 78 degrees rather than 85....     I don't think this happened with 2.0.2 or earlier....

[1714161661]

1714161661

[1714161661]

1714161661

[1714161661]

1714161661

[kano]

That request makes no sense ...

It would seem illogical to increase the GPU Mhz (or decrease the fan RPM) while the temp is above the requested temperature ... no?

The default requested temp is 75 - while it stays above that, it obviously wouldn't increase the GPU Mhz ...

[simonk83]

That request makes no sense ...

It would seem illogical to increase the GPU Mhz (or decrease the fan RPM) while the temp is above the requested temperature ... no?

The default requested temp is 75 - while it stays above that, it obviously wouldn't increase the GPU Mhz ...

Welllllll, the readme says:

"GPU control in auto gpu tries to maintain as high a clock speed as possible
while not reaching overheat temperatures."

It's not doing this, strictly speaking   It's not reaching "overheat" temps (classed as 85 degrees by default right?), so it should be keeping the GPU clock as high as possible until overheat is reached, THEN it should throttle it.

Going by that, it shouldn't have throttled the GPU at all, as the temps never reached overheat.

[kano]

Hmm - you want a higher target then set a higher target ... ?

Edit: also again that makes no sense.
If it was to put it back up as soon as it gets under 85, then it would go straight back over 85 ... you'd end up jumping up and down OVER the overheat temperature, not the requested temperature.

[simonk83]

Hmm - you want a higher target then set a higher target ... ?

I don't want a higher target....  I want it to do what the readme says it should do.....

It should maintain the highest clock speeds possible (in this case 900mhz for GPU3) until that GPU hits 85 degrees, then it'll start to throttle it back.  This isn't happening.

I'm not sure you're grasping this so I'll just wait for con to chime in.  Perhaps the readme is just worded incorrectly, or perhaps there's a bug.   I'm trying to clarify that.

To your EDIT, I'm not concerned about that.  If the temps get that high then I'm happy for it to be throttled back until I can get to it.    My issue is that it's throttling it too early.

[kano]

But 75 is the target temperature, not 85.
Again, if you want a higher target, then set a higher target.

Also rather than reading it to mean what you want, read a little further on:

If fan speed control is not available or already optimal, then GPU clock speed
is only decreased if it goes over the target temperature by the hysteresis
amount, which is set to 3 by default

--temp-hysteresis
If the temperature drops below the target temperature, and engine clock speed
is not at the highest level set at startup, cgminer will raise the clock speed.

[simonk83]

But 75 is the target temperature, not 85.
Again, if you want a higher target, then set a higher target.

Yes, and 85 is the overheat temp!  I'm hardly reading it to mean what I want, it's quite clear...

"GPU control in auto gpu tries to maintain as high a clock speed as possible
while not reaching overheat temperatures."

As for the bits under that, well that kind of contradicts the initial sentence.

Anyway, don't worry, I'll just wait for con.  He coded it, he knows what it's supposed to do.

[-ck]

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.

[simonk83]

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.

Right OK, gotcha.   That line in the readme might need to be reworded slightly as it had me barking at the wrong tree, but all good

[runeks]

Are there any plans to separate cgminer into a miner daemon, that can run all the time in the background, and the actual command line interface, which is how we interact with cgminer? This would be perfect for headless setups, where you just want the computer to chug along mining as much as possible, but you still want to be able to log into the machine and change intensity, for example, or just see how it's going.

Right now I connect to a dedicated miner machine via SSH with X11 forwarding. I then run cgminer in the terminal window that I have open on my main computer. Then thing is, if I want to restart my main computer or simply shut it down and not use it, I lose my ability to see how the mining on the dedicated computer is going.
The above solution would be a perfect fix for this. 'cgminerd' should simply have a configuration file specifying all the parameters and start up whenever the dedicated miner computer is started. When one wants to check the mining status, he simply starts 'cgminer' and this application connects to the cgminerd-daemon and presents the usual user-interface of cgminer. It doesn't do any mining itself, the cgminerd process takes care of this, all it does is present a user interface to enable the user to see how it's going and change parameters if he wishes.

I'm not sure if enabling the user interface application to run on a separate computer and connect to the daemon over the network would be harder to implement than only letting the user interface-app run on the same computer as the daemon is running on. If it is, I don't see a reason to spend time on it (although it would be cool), since one could just run the following command to obtain this feature:

Code:

ssh user@192.168.0.104 cgminer

which would log in via SSH as the user 'user', and run the user interface application on the remote computer (192.168.0.104), but display the results on the computer that the command is executed on.

So is the case simply that everyone recognizes that this would be an awesome feature, but it's just relatively difficult/time-consuming to implement? I assume we would have to build some interface/API between the daemon and user interface. Is there something out there we can re-use for this purpose, or do we have to start from the ground up?

[miscreanity]

Are there any plans to separate cgminer into a miner daemon, that can run all the time in the background, and the actual command line interface, which is how we interact with cgminer? This would be perfect for headless setups, where you just want the computer to chug along mining as much as possible, but you still want to be able to log into the machine and change intensity, for example, or just see how it's going.

Right now I connect to a dedicated miner machine via SSH with X11 forwarding. I then run cgminer in the terminal window that I have open on my main computer. Then thing is, if I want to restart my main computer or simply shut it down and not use it, I lose my ability to see how the mining on the dedicated computer is going.

Use screen. On your headless miner, run:

Code:

screen -dmS "SessionName" "cgminer -c config.json"

Then, after logging back into the mining system via SSH:

Code:

# to show running screen sessions
screen -ls

# to reattach to specific session
screen -r "SessionName"

To detach from a session, allowing it to continue running:
Ctrl+a, d

[runeks]

Well that seems to satisfy my needs. Thanks a lot!

[miscreanity]

Well that seems to satisfy my needs. Thanks a lot!

No problem, glad it helped.

[Shevek]

My congrats for the effort and the brilliant result. Just sent a tiny contribution.

Some comments and easy points to score:

* Please, include the last fresh version in the subject line of the thread

* In GPU menu, when I want to change parameters, (key "C") the program asks about GPU-id. The question is pertinent with at least 2 GPUs but with only one... much better go ahead to the only one that can be modified.

And now a not-so-easy point.

Fan control is a bit unstable. I'm mining in my own desk computer, so sometimes I must throttle down GPU (dynamic on). When miner works alone(I=10), at some point it is reached a stationary state, where fan power is stable. But this state is reached after a not so short period of instability, where fan speed increases and decreases randomly. When I work and mine together, the behavior of fan is very crazy.

So I suggest a PID-like control of fan speed to ensure quicker stability. If you don't know about this, I can give some ideas.

Cheers!

[-ck]

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.

[iopq]

But 75 is the target temperature, not 85.
Again, if you want a higher target, then set a higher target.

Yes, and 85 is the overheat temp!  I'm hardly reading it to mean what I want, it's quite clear...

"GPU control in auto gpu tries to maintain as high a clock speed as possible
while not reaching overheat temperatures."

As for the bits under that, well that kind of contradicts the initial sentence.

Anyway, don't worry, I'll just wait for con.  He coded it, he knows what it's supposed to do.

while NOT reaching overheat temperatures
it's not reaching 85 when it reaches 75, now does it

[-ck]

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.

[Luke-Jr]

NEW VERSION: 2.0.4

Now available for Gentoo through Portage (or any other ebuild package manager):

Code:

layman -a bitcoin && emerge cgminer

Please test and report results!

[gyverlb]

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.

[-ck]

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