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

[Departure]

Rebooted Windows 7 X64 still got the same error before cgminer crashes..

Code:

C:\Users\xxxxx\Desktop\cgm>cgminer -o http://mineco.in:3000 -u xxxxx -p
 xxxxx -I 8 -D
[2011-07-21 08:22:27] X-Roll-Ntime found
[2011-07-21 08:22:2[2011-07-21 08:22:27] Successfully retreived and deciphered w
ork from pool 0 http://mineco.in:3000
7] Long-polling activated for http://mineco.in:3000/LP
[2011-07-21 08:22:27] Pool 0 http://mineco.in:3000 active
[2011-07-21 08:22:27] Init GPU thread 0
[2011-07-21 08:22:27] List of devices:
[2011-07-21 08:22:27]   0       Cayman
[2011-07-21 08:22:27]   1       Cayman
[2011-07-21 08:22:27]   2       Cayman
[2011-07-21 08:22:27]   3       Cayman
[2011-07-21 08:22:27]   4       Cayman
[2011-07-21 08:22:27]   5       Cayman
[2011-07-21 08:22:27] Selected 0: Cayman
[2011-07-21 08:22:27] Preferred vector width reported 4
[2011-07-21 08:22:27] Max work group size reported 256
[2011-07-21 08:22:27] No binary found, generating from source

[2011-07-21 08:22:27] Patched source to suit 2 vectors
[2011-07-21 08:22:27] cl_amd_media_ops found, patched source with BITALIGN

[2011-07-21 08:22:27] cl_amd_media_ops found, patched source with BFI_INT

[2011-07-21 08:22:28] binary size 0 : 0

C:\Users\xxxxx\Desktop\cgm>

[1714497454]

1714497454

[1714497454]

1714497454

[-ck]

Darn. You do have the 2.4 SDK installed don't you?

[ancow]

One thing I've been meaning to ask: why is the -n option available when cgminer isn't compiled with GPU mining support? Is the output actually useful (i.e. it shows the amount of devices that could be used for GPU mining), or will it just simply always print out "0 GPU devices detected"?

[-ck]

One thing I've been meaning to ask: why is the -n option available when cgminer isn't compiled with GPU mining support? Is the output actually useful (i.e. it shows the amount of devices that could be used for GPU mining), or will it just simply always print out "0 GPU devices detected"?

Oversight.

[error]

The 1.3.1 release solved my issue with blank lines between the log entries. Thanks!

[-ck]

The 1.3.1 release solved my issue with blank lines between the log entries. Thanks!

You're welcome! The issue was that windows opens a standard dos shell in 80 columns and the default text was slightly wider than 80 so I made it more concise.

[error]

The 1.3.1 release solved my issue with blank lines between the log entries. Thanks!

You're welcome! The issue was that windows opens a standard dos shell in 80 columns and the default text was slightly wider than 80 so I made it more concise.

I use Linux.

[-ck]

So your shell was also 80 columns

[error]

So your shell was also 80 columns

I use Konsole.

OK, I'll quit now

[kripz]

I hope it's ok to mine namecoin, all rejected at such low difficulty>

Code:

Started at [2011-07-19 15:08:35]
Runtime: 45 hrs : 34 mins : 53 secs
Average hashrate: 11.1 Megahash/s
Queued work requests: 833
Share submissions: 404
Accepted shares: 0
Rejected shares: 404
Reject ratio: 100.0
Hardware errors: 0
Efficiency (accepted / queued): 0%
Utility (accepted shares / min): 0.00/min

Discarded work due to new blocks: 3
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 3
Work items generated locally: 3
Submitting work remotely delay occasions: 0
New blocks detected on network: 109

Summary of per device statistics:

 GPU 0: [11.1 Mh/s] [Q:831  A:0  R:404  HW:0  E:0%  U:0.00/m]

Code:

Started at [2011-07-19 10:21:04]
Runtime: 50 hrs : 24 mins : 18 secs
Average hashrate: 966.7 Megahash/s
Queued work requests: 44267
Share submissions: 40934
Accepted shares: 39912
Rejected shares: 1022
Reject ratio: 2.5
Hardware errors: 0
Efficiency (accepted / queued): 90%
Utility (accepted shares / min): 13.20/min

Discarded work due to new blocks: 229
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 78
Work items generated locally: 702
Submitting work remotely delay occasions: 5
New blocks detected on network: 691

Summary of per device statistics:

 GPU 0: [322.2 Mh/s] [Q:15014  A:13152  R:355  HW:0  E:88%  U:4.35/m]
 GPU 1: [322.2 Mh/s] [Q:14998  A:13410  R:304  HW:0  E:89%  U:4.43/m]
 GPU 2: [322.3 Mh/s] [Q:15030  A:13350  R:363  HW:0  E:89%  U:4.41/m]

Started at [2011-07-19 10:19:08]
Runtime: 50 hrs : 24 mins : 40 secs
Average hashrate: 179.9 Megahash/s
Queued work requests: 8527
Share submissions: 7514
Accepted shares: 7218
Rejected shares: 296
Reject ratio: 3.9
Hardware errors: 0
Efficiency (accepted / queued): 85%
Utility (accepted shares / min): 2.39/min

Discarded work due to new blocks: 12
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 34
Work items generated locally: 94
Submitting work remotely delay occasions: 1
New blocks detected on network: 543

Summary of per device statistics:

 GPU 0: [179.9 Mh/s] [Q:8912  A:7218  R:296  HW:0  E:81%  U:2.39/m]

Time to upgrade!

Still have to compile with -O1 or no optimizations otherwise i get seg faults on exit.

[Departure]

Darn. You do have the 2.4 SDK installed don't you?

I have just the drivers installed which comes with all the needed SDK stuff, never needed to actually install the whole SDK package with any other miner. But yeah I can try and install the SDK also and see what happends..

//Edit

Installed and tested with SDK 2.4 still the same error.

Windows 7 x64 (Themes Disabled)
SDK 2.4
Drivers 11.7
3 x 6990 gfx cards.

[Tasty Champa]

what gpus are you using ?

these are mine:

SLI Nvidia 9800gtx+ / SLI GTS250

Code:

del /F /Q *.bin
cgminer.exe -o http://server:port -u username -p pass -w 64 -t 0 -I 4

XFire 6970 / XFIRE 6950

Code:

del /F /Q *.bin
cgminer.exe -o http://server:port -u username -p pass -I 9 -t 0

My curiosity urges me to ask why you are removing the previous bin files?
I'm using just one 5770, but I removed the 256 worksize as it made my system not as responsive.
I think I am also going to remove the -g 10 as per ckolivas's advice, thanks ckolivas!

[xcooling]

del /F /Q *.bin

Prevents errors: binary size 0 : 0
Prevent issues on upgrading to a newer version, upgrade drivers, switch graphics card or chnage the sdk.

[heli0s]

The 1.3.1 release solved my issue with blank lines between the log entries. Thanks!

You're welcome! The issue was that windows opens a standard dos shell in 80 columns and the default text was slightly wider than 80 so I made it more concise.

Unfortunately it didn't fix it for me.

Code:

[2011-07-21 07:38:46] Accepted 3e2ec113 GPU 0 thread 0 pool 0

[2011-07-21 07:39:00] New block detected on network before longpoll, waiting on
fresh work
[2011-07-21 07:39:10] Accepted 70ab214e GPU 0 thread 0 pool 0

[2011-07-21 07:39:16] Accepted 3ab13683 GPU 0 thread 1 pool 0

[2011-07-21 07:39:19] Accepted 4e2712a7 GPU 0 thread 0 pool 0

[2011-07-21 07:39:20] Accepted 57e1f7b3 GPU 0 thread 0 pool 0

[2011-07-21 07:39:23] Accepted 45e05dd0 GPU 0 thread 1 pool 0

[EskimoBob]

Just a heads up for a few people.

Cgminer does not appear to support target rewrites. I have checked the code and the target is derived from midstate and "data" from the getwork. Thus when the pools send you diff 1 work, cgminer ignores that and mines with full difficulty and since the gpu miner code does not check if the hash meets the difficulty, it sends a result anyway. This is why some people have reported they get less shares with cgminer.

For proof, go into findnonce.c and in the precalc function add

Code:

printf("nbits %d", blk->nbits); 

somewhere, compile and run, it will print the nbits of the current target.

I'd categorize this as a serious flaw. Miners still submitted work, but far less than usual. In the long run, people earned waay less than they should have.

P.S
Conman is aware of this, however is reluctant to fix it. The excuse was "It sends shares, doesn't it?"

Is this bug confirmed, fixed or still unconfirmed?

[ancow]

Since there seem to be a growing number of bugs with cgminer, how about setting up some kind of bug tracker for it? If I'm not mistaken, github has that functionality.

Anyway, to illustrate, these are the open bugs I've run across that I can remember:

1) Long polling is broken for deepbit in several ways.
a) After a while, "longpoll failed, sleeping for 30s" messages keep appearing, then the thread dies. I'm not exactly sure why that is.
b) The LP thread isn't restarted after it dies. This is a problem since deepbit turns off long polling from time to time, so the amount of LP failures will increase, resulting in a thread shutdown eventually, despite the fact that it is turned back on again.
c) With the recent versions I never get "proper" long polling messages, only "New block detected on network before longpoll, waiting on fresh work"

2) With recent modifications, cgminer doesn't compile on OSX anymore:

3) I'm not sure why, but with swepool.net I'm getting a huge amount of stales (>10%). With deepbit I'm getting ~14% stales, but I'm attributing that to the LP failures.

4) After a rejected share, cgminer should get new work just to be on the safe side. There's no real downside to this and it would probably cut the amount of rejects I get in half.


A bug tracker would not only avoid duplicate reports (or at least provide an easy way of managing them), it would allow the reporters to see any progress being made on those bugs, and thus (hopefully) create less noise.

[The00Dustin]

If you installed the NVIDIA drivers from RPM Fusion (including xorg-x11-drv-nvidia-devel package) and the CUDA toolkit from NVIDIA in the default /usr/local/cuda, then this should get you going:

Code:

CFLAGS=-I/usr/local/cuda/include LDFLAGS=-L/usr/lib64/nvidia ./configure
make clean
make

OK, so I checked and I had installed the nvidia drivers as you described (including the cuda toolkit location).  As such, I tried this:
CFLAGS=-I/usr/local/cuda/include LDFLAGS=-L/usr/lib64/nvidia ./configure --program-suffix=\-nvidia

For the record, I uninstalled my previous build first, the -nvidia was just in case I ended up finding it only working for nvidia and wanted to try to run an nvidia one and an ATI one side by side.  When I tried to run cgminer-nvidia, I still get this:
[2011-07-21 09:26:33] Error: Getting Device IDs (num)

I then proceeded to uninstall again, remove the jansson-devel libraries just in case, configure without the program suffix just in case, compile and install again, see the same error when running cgminer, so I edited /etc/ld.so.conf.d/local.conf to remove these two lines:
/opt/ati-stream-sdk-v2.1-lnx64/lib/x86_64/
/opt/ati-stream-sdk-v2.1-lnx64/lib/x86/

I then ran ldoconfig.  I still had to use CFLAGS=-I/usr/local/cuda/include LDFLAGS=-L/usr/lib64/nvidia in order to have gpu mining support enabled even though /etc/ld.so.conf.d/local.conf still had these lines:
/usr/local/cuda/lib64/
/usr/local/cuda/lib/

After all that (some of it perhaps grasping at straws), I STILL get the same error.  Any other thoughts?

[BOARBEAR]

I thought this miner would be faster than ufasoft miner for CPU(SSE4).
However, it is much slower on windows.

[-ck]

I thought this miner would be faster than ufasoft miner for CPU(SSE4).
However, it is much slower on windows.

There is no windows build with the sse2 and sse4 support. Someone needs to build a 64 bit version to get those.

[Ali]

Great work, ckolivas.

Just being unclear about the mining-speed hinders me from switching all my miners to cgminer. I'm on Windows 7 (x86) with a 6950

phoenix shows 245.5 Mh/s with these settings:

Code:

phoenix -u http://user:pass@nl.btcguild.com:8332/ -k phatk DEVICE=0 VECTORS AGGRESSION=11 BFI_INT WORKSIZE=128 FASTLOOP=false

With cgminer the avg value is like 244.0 Mh/s (the momentary value show next to GPU 0 is like 252.5 Mh/s).with:

Code:

cgminer --algo c -o http://nl.btcguild.com:8332 -u user -p pass -I 8 -l 2

Which of the values shown are comparable?

I don't really want to run long-term tests to compare the number of shares produced by each one of them.