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

[-ck]

The ncurses crash that you fixed in 1.5.0 is back again. This is a really annoying crash and there is no way I can update curses on Ubuntu 10.04 LTS, I was hoping to switch over from Diabolo today :-/

Give a try to libcurl4-gnutls-dev...

sudo apt-get install libcurl4-gnutls-dev

The bug is in ncurses, not curl. Easy mixup, and they're both libraries used by cgminer...

[1713555512]

1713555512

[1713555512]

1713555512

[1713555512]

1713555512

[tenzor]

I have weird reject rate right after pool found the block. In normal reject rate is about 2% and after block founded on current pool, rate increases up to 5-10% and slowly down back to normal.
I use poclbm at other machines and there reject rate remains the same.

Also on poclbm reject rate about 0.5-0.7% in contrast 2% on cgminer.

Latest git cgminer, latest git poclbm

That could also simply be coincidence.  Are you seeing this frequently or just the one time?

This is the second time. Internet connection is stable and same for all machines including poclbm.

[Sukrim]

Hm, I always get a "Memory access error", maybe I did something wrong on compiling/missing dependencies?

I used the PKGBUILD from a few pages before and just changed the version number and the MD5.

What can I post to help you debug this?

[d3m0n1q_733rz]

Hm, I always get a "Memory access error", maybe I did something wrong on compiling/missing dependencies?

I used the PKGBUILD from a few pages before and just changed the version number and the MD5.

What can I post to help you debug this?

Try using the sse2_64 algorithm instead.  The sse4_64 was made for the newer Intel core2 and i# processors.  It's possible that it just looked at the movntdqa instruction and didn't know what to do.

[Sukrim]

Unfortunately that wasn't it... trying the other algorithms now too.

Edit:
Nope, c and 4way also don't work.

[plantucha]

I can confirm. CPU mining doesn't work
1.5.&up i have to go back to 1.4 and it works

with 1.5 only   4% was acepted  96% rejected

- CPU: AMD Phenom X6
- GPU: 4x HD 6790 oced to 900 MHz (Mem 300 MHz)
- ubuntu 64 bit natty
- Catalyst 11.6 with SDK 2.4

Have you tried forcing other CPU algorithms with the "-a" option? Perhaps it is particular to a algorithm running on your CPU architecture? You might need to look at the debug output for some of the rejects to get an idea why they are failing. Also, what pool are you connecting to?

-- RD

Yes I tried
sse4_64 - doesn't work ( AMD CPU doesnt support it)
sse2_64 - ~17Mh/s
4way     - ~21Mh/s
everything else is so small I will not even talk about it.

But as I said, same string works with older version, so it will be code related.

I'm trying to come up with ways to make it AMD compatible.  There is C code for SSE4, but it compiles the same as SSE2 due to the intrinsics being the same and using the same functions.  There would need to be a structural change in how it's implemented in order to take full advantage of the newer SSE instructions and I don't know much about programming in C.
The ASM code uses movntdqa which can be replaced with MOVNTSD in theory.  I don't have an AMD processor to play around with it, but you're free to try.

last git log, but it is same in any 1.5up version

Code:

[2011-07-29 08:32:19] Popping work from get queue to get work
[2011-07-29 08:32:19] Successfully divided work
[2011-07-29 08:32:19] Pushing divided work to get queue head
[2011-07-298 / 1.719] Popping work to work thread
[2011-07-2.1 / 1.819] Popping work to work thread
           6 / 1.8
           7
[2011-07-293 / 2.019] JSON protocol request:
               1.9< HTTP/1.1 200 ok
< Content-Type: application/json
< Connection: keep-alive
[2011-07-29 08:32:19] Discarded cloned work
[2011-07-29 08:32:19] Queueing getwork request to work thread
[2011-07-29 08:32:19] Popping work from get queue to get work
[2011-07-29 08:32:19] Successfully divided work
[2011-07-29 08:32:19] Pushing divided work to get queue head
[2011-07-29 08:32:19] Popping work to work thread
[2011-07-29 08:32:19] Popping work to work thread
      "midstate": "0ff8e6b8afda0bb8cef88f8eff297ff6bd5b98bfc456d5e0b178b9e34bee2de5",
      "data": "00000001b2b92d457e2b78eea04ce3610ac9f07575e368def4cc8156000008100000000095d00c5f783b6729c8b55c0d4223ec43671bbf6055a81a51f7db124a8554a3624e32a
84e1a09ec0400000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
      "hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"
   },
   "error": null
}
[2011-07-29 08:32:19] Pushing work to requesting thread< HTTP/1.1 200 ok
< Content-Type: application/json
< Connection: keep-alive
< X-Long-Polling: /LP
< X-Roll-NTime: Y
< Date: Fri, 29 Jul 2011 12:31:54 GMT
< Content-Length: 591
< 
* Connection #0 to host mtred.com left intact
[2011-07-29 08:32:19] JSON protocol response:
{
   "id": 0,
   "result": {
      "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000",
      "midstate": "c76491bd49e962f112793907c80a8e1933bb94b780b5f8c8f6a7debb870b5bf9",
      "data": "00000001b2b92d457e2b78eea04ce3610ac9f07575e368def4cc8156000008100000000007eb0f367c39eaddf1b49dbf8c46e887e8383ce15edc64d67ad352f138d7e8224e32a
84e1a09ec0400000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
      "hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"
   },
   "error": null
}
[2011-07-29 08:32:19] Pushing work to requesting thread
[2011-07-29 08:32:19] Pushing work to getwork queue
[2011-07-29 08:32:19] Popping work to stage thread
[2011-07-29 08:32:19] Pushing work to getwork queue
[2011-07-29 08:32:19] Popping work to stage threadQuit

using -a 4way
with 1.4 are no such a  "error": null calls   
and rejection is 0%

[-ck]

I'm not sure what you're telling me. That error: null field is coming from your pool, not from cgminer.

[RudeDude]

As for CPU mining in 1.5.x+, I find the rate of accepted shares is the same crap rate as previous versions, as far as CPU mining goes. It's no worse than it ever was, but the efficiency is higher (efficiency being accepted shares / requests, NOT the reject rate).

I can confirm 1.5.2 does not drop hashing speed anymore (Linux, Ubuntu 10.04, CPU mining only). I ran one all night and the speed is still as expected. My accept/rejects are reasonable unlike what others have reported. Here it is:

Code:

 cgminer version 1.5.2 - Started: [2011-07-28 23:09:41]
--------------------------------------------------------------------------------
 [(5s):6.8  (avg):6.8 Mh/s] [Q:1335  A:48  R:4  HW:0  E:4%  U:0.08/m]
 TQ: 2  ST: 2  LS: 0  SS: 0  DW: 1331  NB: 88  LW: 1517  LO: 0  RF: 0  I: 0
 Connected to http://api.bitcoin.cz:8332 as user _________._____
 Block: 0000082a6635d024f3914d9b6cb27760...  Started: [09:00:19]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 CPU 0: [3.4 / 3.4 Mh/s] [Q:761  A:19  R:1  HW:0  E:2%  U:0.03/m]
 CPU 1: [3.4 / 3.4 Mh/s] [Q:758  A:29  R:3  HW:0  E:4%  U:0.05/m]
--------------------------------------------------------------------------------

[plantucha]

I'm not sure what you're telling me. That error: null field is coming from your pool, not from cgminer.

then why is it not coming from pool if I'm using 1.4?

[-ck]

Here's what my work looks like:

{
   "id": 0,
   "result": {
      "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000",
      "midstate": "aca85347af9a2c933be96bdd8a0e9a2b11da0977108243537ea4daa16fb4dd2a",
      "data": "000000012c0fad8f9157ef574727e1e86cb27760f3914d9b6635d0240000082a000000002ffcdde 6edf23bac3d969036e734e26572061b9b3bd4551b19ccd05a7f928ea54e32b2bc1a09ec04000000 0000
0000800000000000000000000000000000000000000000000000000000000000000000000000000 000000080020000",
      "hash1": "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000"
   },
   "error": null
}

That's just what work looks like from the pool. I think you just haven't spotted it in 1.4.

If you're having a problem, it's something else.

[kano]

For 1.5.2 my stats have gone up the first run by 2%

Thanks ckolivas

My last two runs (that I stopped myself of course) were:

1.5.1: 6hrs 6min 51sec Av: 696.7 Mh/s

1.5.2: 16hrs 4min 23sec Av: 710.9 Mh/s

My current one is at 2.5 hours and Av: 708.2 Mh/s but slowly rising
(the screen is connected to one of the 6950's and when it's un-blanked it drops 50Mh/s and it was un-blanked for a while when I started this run)

[xarly1]

Now its the best minner, really stable and powerfull.

thx bro 

[burp]

I see some regression since 1.4.1. For 1.4.1 I ran cgminer for multiple days without any problems. With 1.5.2 after a few hours one gpu is always marked as DEAD, and there is no problem because I can just restart cgminer without any problems.

EDIT: I see your latest commit 947a74bfa3fb1fe731b479b806a84ee6bc82ce0a might be associated with this, I will try.

[iopq]

I'm going to have to request modular kernels so I can test out the freshest changes by just doing -k newkernel or something

[-ck]

I see some regression since 1.4.1. For 1.4.1 I ran cgminer for multiple days without any problems. With 1.5.2 after a few hours one gpu is always marked as DEAD, and there is no problem because I can just restart cgminer without any problems.

EDIT: I see your latest commit 947a74bfa3fb1fe731b479b806a84ee6bc82ce0a might be associated with this, I will try.

Not sure that one's correct yet sorry. Before did you ever get any thread restarts that you can remember?

[burp]

I see some regression since 1.4.1. For 1.4.1 I ran cgminer for multiple days without any problems. With 1.5.2 after a few hours one gpu is always marked as DEAD, and there is no problem because I can just restart cgminer without any problems.

EDIT: I see your latest commit 947a74bfa3fb1fe731b479b806a84ee6bc82ce0a might be associated with this, I will try.

Not sure that one's correct yet sorry. Before did you ever get any thread restarts that you can remember?

Not sure about it. I think I should enable logging to a file and see when the error occurs, and if I see any thread restarts on 1.4.

[KarlSpaat]

Hi there,

my cgminer crashes, if my primary pool goes offline. Is there a problem with the pool switch algorithm? In the Pool Menu i see all 3 pools as active, and i can switch manually to all of them.

[ancow]

I'm going to have to request modular kernels so I can test out the freshest changes by just doing -k newkernel or something

You do realise that you can specify kernels with the -k switch?

[iopq]

I'm going to have to request modular kernels so I can test out the freshest changes by just doing -k newkernel or something

You do realise that you can specify kernels with the -k switch?

oh shi-

I didn't realize this because kernels didn't have their own folders
let me test this out

 I can't specify arbitrary kernel names if I have different versions, I can only use -k poclbm and -k phatk

[burp]

Code:

[2011-07-29 22:19:38] Thread 1 idle for more than 60 seconds, GPU 0 declared SICK!
[2011-07-29 22:19:38] Attempting to restart thread
[2011-07-29 22:19:38] Thread 1 restarted

Restarting the thread didn't seem to work, because it kept SICK and gpu load was still 0%. Trying to "restart" the GPU via the curses interface resulted in a segfault. I seem to have problems running cgminer with gdb attached, even just with text interface (-T). (Still with 947a74bfa3fb1fe731b479b806a84ee6bc82ce0a, trying latest now.)