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

[Diapolo]

Great work Con, keep it up . I always enjoy reading the changelog to see what progress you've made with that release.

A question, is there a way to achieve the following:

- set a fixed (low) fan speed, which is taken as upper limit
- set an engine range, which is taken into account, while maintaining the maximum fan speed and temperature
- set a maximum temperature and when this is reached the engine clock is lowered until we are in a safe sector

I tried width "--gpu-fan 30 --gpu-engine 600-1100 --temp-overheat 75" and "--gpu-fan 30 --auto-gpu --temp-overheat 75", but that does not seem to do the job.

The first one stays at 30% fan, 1100 MHz and does nothing, when reaching 75 °C.
The secon one stays at 30% fan, 925 MHz and does nothing, when reaching 75°C.

Dia

Thanks 

You need to differentiate target temp from overheat from cutoff temps. cgminer has a graded response depending on which of the 3 it is reaching, and you have to remember there is the hysteresis (3 default). So if you use the first of your numbers, and get rid of the overheat value, but enable autogpu, then it will start throttling the engine speed when it gets to about 78 degrees. ie you probably want:
--gpu-fan 30 --gpu-engine 600-1100 --auto-gpu
and that will keep the fan at static 30%, start the engine at 1100 and then if the temperature gets to 78 will start decreasing the engine speed. If 78 is too high, you can set the --temp-target to something besides 75.

Great, this does the job. Although 30% is rather low for a 7970 ^^, but when working I want to keep the fan as quiet as possible.
Btw. I can't set --temp-hysteresis to 0, which I would say should disable it entirely.

Dia

[1713557919]

1713557919

[vapourminer]

the intensity was set to "-10".  It will switch to any static (-10 through 14) intensity if I enter it with the GPU settings, or in the .conf file, but as soon as it is set back to dynamic (d) it pegs right back to -10 and stays there.

same here.

dynamic sits a -10. took a while though (started around 5), not sure exactly but within 1/2 hour of firing up 2.4.4 it was a -10 and wont budge. set intensity to a number, then back to "d", and its back to -10

clean install (I always just create a new folder and install to it). 6870, win7 64 bit, 11.11 driver, 2.5 sdk. this rig is my daily driver, maybe some program I ran triggered it.

I did notice a "pool 0 not providing work fast enough" in the command window but am unsure if that had anything to do with it.

EDIT: set intensity to 7 for a while (an hour maybe?) and then to dynamic. nows its sitting at 4.
EDIT 2: back to -10 in ten minutes. didnt run much of anything, and nothing in the command windows but accepted shares.

just setting to 7 for now.

[-ck]

Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...

[-ck]

I finally got sick of the poor BFL performance argument and bickering between luke and kano so I wrote my own solution generically even though I have no hardware of my own. It's now in the git master tree and Kano has tested it.

[Luke-Jr]

(Reposted from here)

Looks like Con's solution to his perceived problem of "BFL actually supports CGMiner pretty well, via the original developer of FPGA support and BFL driver - but that's not via me" is to get rid of me so they're left forced to give him stuff or not be supported. In effect, Con has decided that CGMiner will become/live on (how long?) as a de facto hostile fork of BFGMiner (which has continuity of maintenance). I'm disappointed Con has chosen to severe cooperation between CGMiner and BFGMiner, but I hope to continue pulling as many improvements from CGMiner as possible (Con hinted earlier tonight that he wasn't planning to accept the device API updates needed for better Mini Rig functionality - including p2pool compatibility - so there's an increased risk some changes might become impractical)

P.S. I won't speak for BFL, but they asked me to do the Mini Rig improvements for BFGMiner originally (I was doing the CGMiner backport mainly because it was possible). Hopefully this will finally be ready this week (waiting on BFL for some last things), and I expect to release a version of BFGMiner using it ASAP.

[-ck]

Luke just go away already. I already told you I'm outta here, so dunno why you're still whining.

[Bitbird]

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

[-ck]

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

Wrong version of ubuntu.

[TheHarbinger]

(Reposted from here)

Stuff

Seriously man.  You have your own thread, and your own split version of cgminer.  Put your ego in check and just stay the fuck out of this thread.

[kano]

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

That's why I recently added xubuntu 11.04 builds of the binary in my git download for anyone who still uses ubu 11.04 or similar and doesn't want to build from source:
https://github.com/kanoi/cgminer/downloads

[-ck]

Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...

I've committed a change to the git tree which should fix it. Can anyone who has the problem and builds from git confirm please?

[nedbert9]

Con, will you be writing BFL support via their remote solution?

I haven't decided yet because this is not a sign of BFL supporting the community, the developer or the clients. Of course taking a stand when BFL are guaranteed of sales monopoly and cornering the market will just make me look like I'm taking a stance when no one gives a shit, but then, I'm not sure what I get out of doing the hard work for them.

Sad, isn't it.  Com'on competition.

[ChanceCoats123]

Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...

I've committed a change to the git tree which should fix it. Can anyone who has the problem and builds from git confirm please?

Will you be pushing a fixed windows binary out? I just ran into the same -10 issue with dynamic set.

[mokahless]

May want to take a look at the windows binary.

Getting 1.5Mh/s on my 5870s with the new 2.4.4.   

I haven't checked my intensity level but I have the same thing on my 6770m (a 5000 series card technically with add-in 6000-series features).
My 6950 and 6450 are enjoying an additional 10 and 4 MH/s... Interesting ratio...

[TheHarbinger]

Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...

I've committed a change to the git tree which should fix it. Can anyone who has the problem and builds from git confirm please?

Negative, not fixed.  Fresh pull from git and built on a Win7 x64 system.  Same behavior.

Edit:  Did a new pull and tried it again.  This time it works, I must have borked something up the first time.  Going to let it run a bit and see how it does.

[ThiagoCMC]

YAY! 3.5 more MHash from my PowerColor 5870!!   

[bulanula]

YAY! 3.5 more MHash from my PowerColor 5870!!   

How ? What settings ? Kernel ?

Did you change anything ? Total MH/s ?

[TheHarbinger]

Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...

I've committed a change to the git tree which should fix it. Can anyone who has the problem and builds from git confirm please?

Negative, not fixed.  Fresh pull from git and built on a Win7 x64 system.  Same behavior.

Edit:  Did a new pull and tried it again.  This time it works, I must have borked something up the first time.  Going to let it run a bit and see how it does.

Edit #2:  Has been running now for 3 hours.  Seems to be stable.  Will update again in the morning (12 hours).  But so far it looks like a good candidate for a binary.

[-ck]

Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...

I've committed a change to the git tree which should fix it. Can anyone who has the problem and builds from git confirm please?

Negative, not fixed.  Fresh pull from git and built on a Win7 x64 system.  Same behavior.

Edit:  Did a new pull and tried it again.  This time it works, I must have borked something up the first time.  Going to let it run a bit and see how it does.

Edit #2:  Has been running now for 3 hours.  Seems to be stable.  Will update again in the morning (12 hours).  But so far it looks like a good candidate for a binary.

Great, thanks a lot!

[wildemagic]

Stable here too on 4 x icarus with 2.4.4.

Still cant decide between 2.4.4 and 2.4.3.

Any advantages between the two versions? anything changed for icarus?

I use a proxy pool so I cant really tell if stales are better or worse since the pool swings between high rejects and low depending on where the hashes are going.

kind regards