Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 770. (Read 5805728 times)

I installed 2.0.4 last night and checking it this morning my efficiency is at 16%.  The previous versions had 80+%.

I haven't changed any of my settings.
Sam

Pretty sure all those bugs were fixed with 2.0.0.

2.0.4 seems much better.

Most important thing : it protects the GPU far more efficiently than 2.0.3, the GPU temp doesn't go more than 1 or 1.5°C above target.
The fan speed setting still overshoots the ideal speed when going above the target but doesn't undershoot it as much. It seems that the oscillation's amplitude lowers itself with time and finally stabilizes itself (according to logs the 5970 which had the most problems with 2.0.3 is now happily at 46% for more than 30 minutes without any re-tuning by cgminer after an initial period of 20 minutes of oscillations).

I'm happy to see you here Luke! did you test cgminer against eligius? In earlier versions cgminer reported a lot of rejections with your pool.

OK, thanks. I still didn't taste this new version; I guess your damp is a kind of differential control. Anyway, what I have in mind is something like this.

Fi: actual fan value
Ti: actual temp.
Tc: target temp

Pi = Ti - Tc
Di = Ti - T(i-1)
F(i+1) =  Fi + aPi + bDi

where a,b are constants that should be elected after some tryings.  See, that integral control is implicit in the dependence of old value.


I don't think so... I've monitored the fan speed and It shows often near values.

Works for me now.

I've removed my --gpu-fan tunings to see if the new fan speed setting algorithm is working for me : I had huge variations of fan speed and gpu temp that made my OC'd GPU unstable. With 2.0.3 the GPU temps could reach 10°C above target.

Oops, my bad.

Redownload please 

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.

Now available for Gentoo through Portage (or any other ebuild package manager):
Please test and report results!

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.

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

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.

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!

No problem, glad it helped.

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

Use screen. On your headless miner, run:


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


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

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:
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?

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

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.

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.