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

[-ck]

For the record, when I went from 1.5.3 to 1.5.6 it would consistentsy lock up my GPU (and pretty much my computer) within an hour (sometimes in minutes) until I lowered my OC settings.  I am now getting a higher MHash/s and higher efficiency with lower OC settings.  This was true on a multi-day run with 1.5.6 (over the weekend, so at least three days) and appears to be holding true for 1.5.8 (installed yesterday) as well.  Giving up may not be to your advantage in the long run.

I'm actually very pleased to hear this because people are very quick to blame the software the provokes the problem rather than the problem itself. Thanks for reporting this.

[Remember remember the 5th of November]

Another thing. Since which version is pkg-config required? since 1.5.7 or earlier?

[-ck]

Another thing. Since which version is pkg-config required? since 1.5.7 or earlier?

Quite a while back. I just hadn't put that into the documentation till recently since the patch to require it came from Ycros who helped get it working on multiple platforms originally.

[Remember remember the 5th of November]

Another thing. Since which version is pkg-config required? since 1.5.7 or earlier?

Quite a while back. I just hadn't put that into the documentation till recently since the patch to require it came from Ycros who helped get it working on multiple platforms originally.

But...i compiled all the previous versions without the need of pkg-config, yet with version 1.5.8 i am getting all kinds of issues.

[Ghostofkobra]

Another thing. Since which version is pkg-config required? since 1.5.7 or earlier?

Quite a while back. I just hadn't put that into the documentation till recently since the patch to require it came from Ycros who helped get it working on multiple platforms originally.

Mr November,
You probably stumbled into the same problem as i did.
I am running a few boxes with an OLD Linux version (Red Hat 4.x).
On these machines v1.5.6 installs fine but v1.5.7-.8 doesnt find curl.
I am using a from source compiled curl 7.21.7 and installed with make install.
It was found by v1.5.6(or was it .2) but not 1.5.7.

When looking at the configure script the curl detect code has changed drastically.
So i just did an ugly hack and
            "copied ./curl-7.21.7/libcurl.pc to  /usr/lib64/pkgconfig/libcurl.pc"
            "And removed the URL line in libcurl.pc since its not supported by this version of pkg-config"

Then it all worked like a charm..
Just updated all machines to 1.5.8 and i think im seeing fewer rejected packets from my cpu miner threads.

/GoK

[Remember remember the 5th of November]

I have no problem with curl, pkg-config is the problem and its weird if the previous versions had no problems.

[PLaci1982]

a newb have problems with the miner...

https://bitcointalk.org/index.php?topic=39021.0

[d3m0n1q_733rz]

Hey everyone!  Just a little bit of an idea for those of you with hardware lock-up problems.  Most commonly, they're caused by overheating GPUs.  One thing that I do personally is remove the original thermal paste/pad from between the GPU and cooler and then use my own (most commonly Arctic Silver MX-2 or OCZ Freeze Extreme [I choose this one]) and then apply a thin layer on the GPU and a SMALL dot on each side of each thermal pad to increase thermal conductivity using a pair of clean tweezers to hold the pad so as not to get finger oils on them.
After that, I hop into Windows and play around with my fan settings to increase RPMs for higher loads sooner than later to keep things  during those short moments where the GPU drops in work load from time to time.
You just have to make sure that the cause of your lockups isn't lack of sufficient power to keep your cards running steady.  Because, once that fan hits 100%, the power usage generally reaches the same.  Can't have a good fire if there's a lack of oxygen; same applies for hashing rates and energy supplied.
Generally speaking, I would also make certain to use at least a Gold rated efficiency multi-rail GPU to keep power clean and efficiently used.

I hope this helps some of you; now let's stop blaming the program for lockups, shall we?

[iopq]

multi-rail power supplies are not better than single rail power supplies because internally it uses the same circuitry to save costs
so internally there's only one rail
this applies to 99% of all computer power supplies

[d3m0n1q_733rz]

multi-rail power supplies are not better than single rail power supplies because internally it uses the same circuitry to save costs
so internally there's only one rail
this applies to 99% of all computer power supplies

Internally, yes they do use the same circuitry initially; however, once it branches out, each rail is smoothed using capacitors and diodes to keep fluctuations mostly confined to that specific rail.  For example, I like to put my DVD burner on one rail by itself as it likes to cause fluctuations and its burning is affected by line noise caused by fans and other motors.  In this way, multi-rail systems are in fact more efficient as they decrease the line noise that would otherwise plague the entire system.
I find the problem is that most people don't think to use the rails effectively.

[The00Dustin]

Internally, yes they do use the same circuitry initially; however, once it branches out, each rail is smoothed using capacitors and diodes to keep fluctuations mostly confined to that specific rail.  For example, I like to put my DVD burner on one rail by itself as it likes to cause fluctuations and its burning is affected by line noise caused by fans and other motors.  In this way, multi-rail systems are in fact more efficient as they decrease the line noise that would otherwise plague the entire system.
I find the problem is that most people don't think to use the rails effectively.

This sounds great in theory, however, I find the problem to be that most PSU manufacturers don't make it obvious which plugs belong to which rail. 

[d3m0n1q_733rz]

Internally, yes they do use the same circuitry initially; however, once it branches out, each rail is smoothed using capacitors and diodes to keep fluctuations mostly confined to that specific rail.  For example, I like to put my DVD burner on one rail by itself as it likes to cause fluctuations and its burning is affected by line noise caused by fans and other motors.  In this way, multi-rail systems are in fact more efficient as they decrease the line noise that would otherwise plague the entire system.
I find the problem is that most people don't think to use the rails effectively.

This sounds great in theory, however, I find the problem to be that most PSU manufacturers don't make it obvious which plugs belong to which rail. 

True, I generally have to refer to the specs to figure out which one goes to what or peek inside.  But I believe that we've digressed from the actual topic at hand.  I only wrote this small piece to help those who were having lockups.

[miscreanity]

True, I generally have to refer to the specs to figure out which one goes to what or peek inside.  But I believe that we've digressed from the actual topic at hand.  I only wrote this small piece to help those who were having lockups.

Still a great topic for anyone interested. Thanks, both of you.

A solid primer: Anatomy of Switching Power Supplies

[iopq]

multi-rail power supplies are not better than single rail power supplies because internally it uses the same circuitry to save costs
so internally there's only one rail
this applies to 99% of all computer power supplies

Internally, yes they do use the same circuitry initially; however, once it branches out, each rail is smoothed using capacitors and diodes to keep fluctuations mostly confined to that specific rail.  For example, I like to put my DVD burner on one rail by itself as it likes to cause fluctuations and its burning is affected by line noise caused by fans and other motors.  In this way, multi-rail systems are in fact more efficient as they decrease the line noise that would otherwise plague the entire system.
I find the problem is that most people don't think to use the rails effectively.

how many rails do you have?! Usually one rail is for the CPU, one for everything else, and one for the GPU, or two for the GPUs if the PSU is "SLI-certified" or whatever

[m3ta]

@ck: Is anything like Phoenix's -s planned?

ie
 -s SOCKETNAME, --socketname=SOCKETNAME
                        full path to file for outputting current status.

That would be so delightfully cool... and useful.

No reply, so I guess it can't be done.
It's a pity, because the -s would allow CG to be (possibly) considered to be a part of BAMT. As it is now, it's "just" a standalone miner.

[-ck]

@ck: Is anything like Phoenix's -s planned?

ie
 -s SOCKETNAME, --socketname=SOCKETNAME
                        full path to file for outputting current status.

That would be so delightfully cool... and useful.

No reply, so I guess it can't be done.
It's a pity, because the -s would allow CG to be (possibly) considered to be a part of BAMT. As it is now, it's "just" a standalone miner.

What exactly do you mean by a socket? It looks to just be a filename on that summary. I assume this is not just redirecting stderr to your file of choice?
./cgminer -blah 2>/path/to/file
?

[gnar1ta$]

It's a pity, because the -s would allow CG to be (possibly) considered to be a part of BAMT. As it is now, it's "just" a standalone miner.

BAMT + CG ?? I like the sound of that ...

[smurfix]

What exactly do you mean by a socket? It looks to just be a filename on that summary. I assume this is not just redirecting stderr to your file of choice?
./cgminer -blah 2>/path/to/file
?

No it's not a file. It's a socket, just backed by a file instead of an IP address+port.
Something listens on the other end and does stuff with the data (like, forward to a master system).
Said other end can also send commands to you, since sockets are bidirectional; I haven't used BAMT yet, so no idea whether it actually does that or whether it uses the port just for reporting.

[-ck]

Updated GIT tree. Next release still pending.

      Make restarting of GPUs optional for systems that hang on any attempt to restart them.     Fix DEAD status by comparing it to last live time rather than last attempted restart time since that happens every minute.
      Move staged threads to hashes so we can sort them by time.
      Create a hash list of all the blocks created and search them to detect when a new block has definitely appeared, using that information to detect stale work and discard it.
      Update configure.ac for newer autoconf tools.
      Use the new hashes directly for counts instead of the fragile counters currently in use.
      Update to latest sse2 code from cpuminer-ng.
      Allow LP to reset block detect and block detect lp flags to know who really came first.
      Get start times just before mining begins to not have very slow rise in average.
      Add message about needing one server.
      We can queue all the necessary work without hitting frequent stales now with the time and string stale protection active all the time.     This prevents a pool being falsely labelled as not providing work fast enough.
      Implement SSE2 32 bit assembly algorithm as well.
      Fail gracefully if unable to open the opencl files.
      Make cgminer look in the install directory for the .cl files making make install work correctly.
      Allow a custom kernel path to be entered on the command line.

[The LT]

Thanks a lot Con for making the kernel file specifiable and the library path configurable!