Author

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

hero member
Activity: 682
Merit: 500
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.
sr. member
Activity: 252
Merit: 250
Inactive
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

Quote
./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
sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?

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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

Quote
./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.
full member
Activity: 234
Merit: 100
Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

Quote
./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
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Luke just go away already. I already told you I'm outta here, so dunno why you're still whining.
legendary
Activity: 2576
Merit: 1186
(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
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Darn. Guess I broke instead of fixed dynamic. I'll have to investigate again soon...
legendary
Activity: 4354
Merit: 3614
what is this "brake pedal" you speak of?
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.
hero member
Activity: 769
Merit: 500
Great work Con, keep it up Smiley. 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  Smiley

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
sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
May want to take a look at the windows binary.

Getting 1.5Mh/s on my 5870s with the new 2.4.4.   Undecided
Others are using this binary without any problems and I can't think of anything that would do this. I suggest you delete any .bin files you have and start again, or just extract it fresh and start again, doing the windows three finger salute (reboot) first.

Okay, it was late when I posted this, so I didn't mess with it last night, just shut it down and went back to 2.4.3.  Now it's a new day and I tried it again.  I noticed something immediately this morning, 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.

Have tried;
New clean copy, no .bin, no .conf
New copy with old .bin, old .conf
And all the variations of old and new

Running a Win7 x64 w/ 2.5 SDK and Cat 12.6

So, ckolivas, tell me what I can do to help you figure this out.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
sr. member
Activity: 349
Merit: 250
Con, will you be writing BFL support via their remote solution?
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Great work Con, keep it up Smiley. 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  Smiley

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.
hero member
Activity: 769
Merit: 500
Great work Con, keep it up Smiley. 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
legendary
Activity: 1288
Merit: 1227
Away on an extended break
May want to take a look at the windows binary.

Getting 1.5Mh/s on my 5870s with the new 2.4.4.   Undecided
All of my 58xx series is working perfectly. In fact, I got a marginal increase of 1~Mh/s
sr. member
Activity: 349
Merit: 250
May want to take a look at the windows binary.

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

I'm not seeing this on a quad 6990 on Windows.
Jump to: