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

[d3m0n1q_733rz]

CPU Mining doesn't work properly. No accepted shares through CPU. Only GPU works as expected.
After 2 hours run time i can see the following:

Code:

cgminer version 1.5.1 - Started: [2011-07-28 13:37:27]
--------------------------------------------------------------------------------
 [(5s):117.4  (avg):111.8 Mh/s] [Q:1152  A:144  R:34  HW:0  E:12%  U:1.19/m]
 TQ: 1  ST: 5  LS: 0  SS: 0  DW: 455  NB: 14  LW: 1017  LO: 2  RF: 0  I: 4
 Connected to http://mining.eligius.st:8337 as user XYZ
 Block 000151fdeb39b3e1a21b797f87bdd355  started: [2011-07-28 15:32:34]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: [102.8 / 102.0 Mh/s] [Q:678  A:144  R:11  HW:0  E:21%  U:1.19/m]
 CPU 0: [2.5 / 2.5 Mh/s] [Q:259  A:0  R:6  HW:0  E:0%  U:0.00/m]
 CPU 1: [2.5 / 2.5 Mh/s] [Q:258  A:0  R:7  HW:0  E:0%  U:0.00/m]
 CPU 2: [2.3 / 2.4 Mh/s] [Q:260  A:0  R:7  HW:0  E:0%  U:0.00/m]
 CPU 3: [2.5 / 2.4 Mh/s] [Q:257  A:0  R:3  HW:0  E:0%  U:0.00/m]
--------------------------------------------------------------------------------

- CPU: Athlon II 605e (4x 2,3 GHz)
- GPU: HD 5670 oced to 900 MHz (Mem 300 MHz)
- Gentoo 64 bit stable
- Catalyst 11.6 with SDK 2.4
- latest cgminer GIT version

It could be that blocks are being found before you receive the next one.  It appears that your CPU hashing a rather slow which is understandable for a 2.3 Ghz processor.  But pay close attention to your accepted to rejected ratio on your GPU; with that high of a rejection rate, either something is happening with your network that is causing it not to send at the right time.  If this happens, the work will go stale and be rejected.
There's a number of reasons why the work could have been rejected but I don't think that the miner itself is one of them.

[1713871217]

1713871217

[1713871217]

1713871217

[1713871217]

1713871217

[1713871217]

1713871217

[plantucha]

CPU Mining doesn't work properly. No accepted shares through CPU. Only GPU works as expected.
After 2 hours run time i can see the following:

Code:

cgminer version 1.5.1 - Started: [2011-07-28 13:37:27]
--------------------------------------------------------------------------------
 [(5s):117.4  (avg):111.8 Mh/s] [Q:1152  A:144  R:34  HW:0  E:12%  U:1.19/m]
 TQ: 1  ST: 5  LS: 0  SS: 0  DW: 455  NB: 14  LW: 1017  LO: 2  RF: 0  I: 4
 Connected to http://mining.eligius.st:8337 as user XYZ
 Block 000151fdeb39b3e1a21b797f87bdd355  started: [2011-07-28 15:32:34]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: [102.8 / 102.0 Mh/s] [Q:678  A:144  R:11  HW:0  E:21%  U:1.19/m]
 CPU 0: [2.5 / 2.5 Mh/s] [Q:259  A:0  R:6  HW:0  E:0%  U:0.00/m]
 CPU 1: [2.5 / 2.5 Mh/s] [Q:258  A:0  R:7  HW:0  E:0%  U:0.00/m]
 CPU 2: [2.3 / 2.4 Mh/s] [Q:260  A:0  R:7  HW:0  E:0%  U:0.00/m]
 CPU 3: [2.5 / 2.4 Mh/s] [Q:257  A:0  R:3  HW:0  E:0%  U:0.00/m]
--------------------------------------------------------------------------------

- CPU: Athlon II 605e (4x 2,3 GHz)
- GPU: HD 5670 oced to 900 MHz (Mem 300 MHz)
- Gentoo 64 bit stable
- Catalyst 11.6 with SDK 2.4
- latest cgminer GIT version

It could be that blocks are being found before you receive the next one.  It appears that your CPU hashing a rather slow which is understandable for a 2.3 Ghz processor.  But pay close attention to your accepted to rejected ratio on your GPU; with that high of a rejection rate, either something is happening with your network that is causing it not to send at the right time.  If this happens, the work will go stale and be rejected.
There's a number of reasons why the work could have been rejected but I don't think that the miner itself is one of them.

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

[RudeDude]

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

[sirky]

CGMINER works perfectly on two of my boxes, but on a third (a 32 bit Win7 box) it is getting the OpenCL 0 byte binary issue. I have tried running the program like 15 times in a row and also rebooting.

I am about to try booting to linux instead and running it there and reporting back, but I am just letting you know.

Edit: Actually I won't get to it tonight, but I will try to get this done in the morning!

[-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 :-/

I fixed as much as I could at my end. There will still be a curses bug that I have no control over and only goes away by upgrading curses.
See:
http://davidben.net/blog/2010/05/03/barnowl-ncurses-and-terminal-resizing/
for the story of how the guy found the bug and fixed it.

So the only solution for any remaining resizing bugs is to upgrade ncurses or not use the curses interface by using -T mode. On ubuntu you could add the repository for a newer release and just select ncurses from that, or you could install it yourself. Either way the bug is not going to go away entirely since it's in ncurses itself.

[d3m0n1q_733rz]

Wouldn't suppose you could fix those intrinsics and such on your spare time?  *poke poke*   
There would be a very modest improvement to hashing speed if we could get that SSE4 code to actually compile beyond SSE2.  We may need to adjust the alignment from 8 to 16 in one portion so as to let it take advantage of the optimizations which can only take place at a 16 byte boundary.
But yeah, check it out.  If we allow for the optimization to occur, and even include the intrinsics for an AMD processor, it could be as easy as specifying the CPU in the CFLAGS or using native that causes it to compile for Intel or AMD.  And, with the binary you create, simply using -mtune= whatever would allow for all processors of and under the specified type.  Unfortunately, I've had no luck with trying to modify the code to enable these and they keep compiling for SSE2 only.
Even the horizontal math functions of SSE3 could make for a modest improvement on small rotations.  But I'm going to keep trying to figure out what's causing the hiccup on compiling.

[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.

[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.

Also I noticed after couple hours is CPU mining hashing going slowly down
For example
on start after 2 minutes  is ~21Mh/s
after 8 hours ~13Mh/s

if I stop miner and start miner, it is again ~21Mh/s.
With all versions versions Cgminer.

Predecessor (CPUminer) is holding starting values same all the time. (unfortunately freezing every couple hours)

[d3m0n1q_733rz]

Status update on SSE4 miner.  I'm playing around with changing _mm_set_esi32 to _mm_insert_esi32 for the offset and using _mm_castsi128_ps to pull each value out.  I still hate C.

I wouldn't mind some help.  I'm also looking at replacing some memcpy functions with void _mm_stream_pi if possible.  There are quite a few movd functions which I know could be replaced with movntd to increase efficiency of the code.  I'm also hoping to prefetch some of the values to be copied into the registers to decrease hiccups and fluctuations in hashing speed.

[d3m0n1q_733rz]

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.

[-ck]

Also I noticed after couple hours is CPU mining hashing going slowly down
For example
on start after 2 minutes  is ~21Mh/s
after 8 hours ~13Mh/s

if I stop miner and start miner, it is again ~21Mh/s.
With all versions versions Cgminer.

That bug was fixed in 1.5.2

[Lightspeed]

* Lightspeed wants a feature

if I make the command prompt window like 120 high can we increase the number of displayed output lines so it fills the whole screen?

I'll donate again if you do it

[d3m0n1q_733rz]

Hehe, I've been trying to make changes to speed up the code so I could have something to donate.  I have a 4-core CPU capable of SSE4.1 but two ATI HD2600 graphics cards not capable of anything.  If I could get this code even slightly faster, I would have more than 1 or so bitcoins a month.

[ancow]

* Lightspeed wants a feature

if I make the command prompt window like 120 high can we increase the number of displayed output lines so it fills the whole screen?

I'll donate again if you do it

At least on Linux and Mac, ncurses already takes advantage of the available console height, so this is either a Windows compilation issue or some problem with the way Windows does the resizing. Did you resize using the window controls or the settings?

[-ck]

The code already checks the window size every 2.5 seconds on average and then resizes. Windows curses problem?

[-ck]

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).

[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

[Lightspeed]

im mining on ozcoin and get 0 rejects with cg miner 1.3+, if my connection wigs out really badly then i get stales but thats my 3gs fault not software

[d3m0n1q_733rz]

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?

[PLaci1982]

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