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

[PatMan]

Kano,

Will you have time to weave your magic with this latest release for use on 11.04 before you leave? 

BFL eh? Sounds interesting....

[kano]

Kano,

Will you have time to weave your magic with this latest release for use on 11.04 before you leave? 

BFL eh? Sounds interesting....

Oh I didn't make an 11.04 2.10.5a ... ok will do soon.

[PatMan]

Kano,

Will you have time to weave your magic with this latest release for use on 11.04 before you leave? 

BFL eh? Sounds interesting....

Oh I didn't make an 11.04 2.10.5a ... ok will do soon.

Nice one kano, cheers.

[kano]

Ok I've put 2 versions in my cgminer-binaries github

2.10.5a 2.10.5 recompiled on 64 bit xubuntu 11.04 (as usual)
and
2.10.5c 2.10.5 recompiled on 64 bit xubuntu 11.04 + HotPlug as at 530e3b01
(this also includes all the new code I've written since 2.10.4 - most of it isn't in 2.10.5)


2.10.5a
An Xubuntu 11.04 x86_64 executable is in my github called cgminer-2.10.5a
https://github.com/kanoi/cgminer-binaries
(it also works on Fedora 16 and 17)

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.5a
chmod +x cgminer-2.10.5a
md5sum cgminer-2.10.5a
15f89acdd0e7982faefbeecd26715ea8  cgminer-2.10.4a

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

I ran it for a few minutes just to be sure I didn't mess up the compile

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make


2.10.5c

Anyone interested in testing it (or my current git https://github.com/kanoi/cgminer/tree/hotplug if you wish to compile it yourself) please do.
I do not expect problems with it - but I'm pretty much the only one I'm certain who has tested it all - though others have tested a lot of it.

I've run it on BFL, Icarus, MMQ and GPU.
I've also compiled and run it now on rpi 2012-12-16-wheezy-raspbian and testing to see how reliable/unreliable USB is with that version of linux.
I've had a hotplug error once so far on rpi.

See back here for all the pre-hotplug changes:
https://bitcointalk.org/index.php?topic=28402.msg1480806#msg1480806

My git contains the updated README files and the updated miner.php
https://github.com/kanoi/cgminer/tree/hotplug

Important re-paste from before:
Now some important information about the BFL USB driver.
On linux, if you wish to switch back to the 2.10.5a, 2.10.4a or earlier version, you'll need to unplug and re-plug in your FPGAs or reboot your rig.
On windows (as described in FPGA-README) you'll need to update your windows USB driver to use the new cgminer

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.5c
chmod +x cgminer-2.10.5c
md5sum cgminer-2.10.5c
584398277df9d2add3bbf3684f7168e9 cgminer-2.10.5c

Almost the same configure options as cvolivas uses
In case anyone was wondering:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make
The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has cores enabled, it will dump a much more useful debug core.

[PatMan]

Ok I've put 2 versions in my cgminer-binaries github

2.10.5a 2.10.5 recompiled on 64 bit xubuntu 11.04 (as usual)
and
2.10.5c 2.10.5 recompiled on 64 bit xubuntu 11.04 + HotPlug as at 530e3b01
(this also includes all the new code I've written since 2.10.4 - most of it isn't in 2.10.5)


2.10.5a
An Xubuntu 11.04 x86_64 executable is in my github called cgminer-2.10.5a
https://github.com/kanoi/cgminer-binaries
(it also works on Fedora 16 and 17)

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.5a
chmod +x cgminer-2.10.5a
md5sum cgminer-2.10.5a
15f89acdd0e7982faefbeecd26715ea8  cgminer-2.10.4a

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

I ran it for a few minutes just to be sure I didn't mess up the compile

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make


2.10.5c

Anyone interested in testing it (or my current git https://github.com/kanoi/cgminer/tree/hotplug if you wish to compile it yourself) please do.
I do not expect problems with it - but I'm pretty much the only one I'm certain who has tested it all - though others have tested a lot of it.

I've run it on BFL, Icarus, MMQ and GPU.
I've also compiled and run it now on rpi 2012-12-16-wheezy-raspbian and testing to see how reliable/unreliable USB is with that version of linux.
I've had a hotplug error once so far on rpi.

See back here for all the pre-hotplug changes:
https://bitcointalk.org/index.php?topic=28402.msg1480806#msg1480806

My git contains the updated README files and the updated miner.php
https://github.com/kanoi/cgminer/tree/hotplug

Important re-paste from before:
Now some important information about the BFL USB driver.
On linux, if you wish to switch back to the 2.10.5a, 2.10.4a or earlier version, you'll need to unplug and re-plug in your FPGAs or reboot your rig.
On windows (as described in FPGA-README) you'll need to update your windows USB driver to use the new cgminer

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.5c
chmod +x cgminer-2.10.5c
md5sum cgminer-2.10.5c
584398277df9d2add3bbf3684f7168e9 cgminer-2.10.5c

Almost the same configure options as cvolivas uses
In case anyone was wondering:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make
The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has cores enabled, it will dump a much more useful debug core.

Blimey - that was quick!!  Many thanks again Kano.

[coinotron]

Never seen anything like it, and I have no idea how it could happen?

Here's the parsing code:

Code:

job_id = json_array_string(val, 0);
 prev_hash = json_array_string(val, 1);
 coinbase1 = json_array_string(val, 2);
 coinbase2 = json_array_string(val, 3);
 bbversion = json_array_string(val, 5);
 nbit = json_array_string(val, 6);
 ntime = json_array_string(val, 7);
 clean = json_is_true(json_array_get(val, 8));

and here's the submit generation code:

Code:

 work->ntime = strdup(pool->swork.ntime);

  sprintf(s, "{\"params\": [\"%s\", \"%s\", \"%s\", \"%s\", \"%s\"], \"id\": %d, \"method\": \"mining.submit\"}",
   pool->rpc_user, work->job_id, work->nonce2, work->ntime, noncehex, sshare->id);

Pretty straight forward so your guess is as good as mine? Unless there's memory corruption going on in the miner because of scrypt's weird and wonderful use of memory, but you're describing a simple swapping which is not like memory corruption. Could you track the message the pool sent when the miner returns something odd to make sure it was sent out ok, because this is the first time this sort of bug has been reported and other scrypt pools have been supporting stratum for a while?

It is not only swapping values.  jobid, Extranonce2, ntime can be corrupted in many ways.( non hex characters, empty, even " chars ).
I didn't observe any swaps including nonce. This filed seems unaffected.

New version 2.10.5 improves things a little bit, but there is still a lot of binary mess in submitted works.
However there are miners who have almost 0% rejected shares and are using cgminer 2.10.4 or 2.10.5
Maybe problem is caused by too high cgminer's settings ?

[spiccioli]

Hi,

I have a problem with cgminer > 2.9.7 when using it with my CM1 boards (icarus emulation).

I start it as

Code:

cgminer -S /dev/1st-board -S /dev/2nd-board -S /dev/and_so_on --fix-protocol --failover-only --icarus-timing long -o http://rpc.hhtt.1209k.com:8337 -O 1Xyz..._128

so I'm running with difficulty 128.

With 2.10.4 and now 2.10.5 board hashing speeds are insane, I reach Pethashes and I get tons, I mean tons, of HW: errors

I stop it, restart 2.9.7 with the same parameters (I'm using a script, btw) and all works as it should.

Are there problems with --icarus-timing long or icarus boards ?

spiccioli

Do you only have CM1 boards or do you have other devices also?
Also, rather than 'tons' give a screen shot or an API output.
API stats/summary/devs output would be helpful (stats shows the icarus-timing stats)
I haven't used icarus-timing for a while, so I've no idea if I've caused any problems with it recently
I'll check it after I've has a chance to look at you screen dump and the API stats/summary/devs

Aside:
The Icarus driver is the last of the serial-USB drivers, that I'll get around to updating some time in the ... future ... to use direct USB
But I'm now a bit short on time due to going to visit BFL on the 17th for a week so it may be a while before I update the Icarus code.

Hi kano,

there are two BFL but they're managed by a different instance of cgminer.

anyway, here it is a screenshot after half a minute since restart with 2.10.5

Code:

cgminer version 2.10.5 - Started: [2013-02-08 12:36:49]
--------------------------------------------------------------------------------
 (5s):1.120E (avg):801.4Ph/s | Q:482  A:0  R:0  HW:99  E:0%  U:0.0/m
 ST: 0  SS: 0  DW: 1  NB: 1  LW: 2  GF: 0  RF: 0  WU: 96.9
 Connected to rpc.hhtt.1209k.com diff 128 with LP as user 1..._128
 Block: 00d9ec7e48042357...  Diff:3.27M  Started: [12:36:49]  Best share: 87
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA  0:                | 268.3M/172.2Mh/s | A:0 R:0 HW:7 U:0.00/m
 ICA  1:                | 299.8M/161.4Mh/s | A:0 R:0 HW:7 U:0.00/m
 ICA  2:                | 236.2M/210.2Mh/s | A:0 R:0 HW:1 U:0.00/m
 ICA  3:                | 251.4M/237.0Mh/s | A:0 R:0 HW:2 U:0.00/m
 ICA  4:                | 381.7M/253.0Mh/s | A:0 R:0 HW:1 U:0.00/m
 ICA  5:                | 996.4P/400.7Ph/s | A:0 R:0 HW:6 U:0.00/m
 ICA  6:                | 159.7M/155.6Mh/s | A:0 R:0 HW:8 U:0.00/m
 ICA  7:                | 250.0M/232.5Mh/s | A:0 R:0 HW:9 U:0.00/m
 ICA  8:                | 378.7M/321.8Mh/s | A:0 R:0 HW:3 U:0.00/m
 ICA  9:                | 195.2P/133.6Ph/s | A:0 R:0 HW:7 U:0.00/m
 ICA 10:                | 260.4M/156.2Mh/s | A:0 R:0 HW:7 U:0.00/m
 ICA 11:                | 711.7M/439.0Mh/s | A:0 R:0 HW:3 U:0.00/m
 ICA 12:                | 284.5M/182.0Mh/s | A:0 R:0 HW:6 U:0.00/m
 ICA 13:                | 1.684E/534.3Ph/s | A:0 R:0 HW:6 U:0.00/m
 ICA 14:                | 278.5M/241.1Mh/s | A:0 R:0 HW:1 U:0.00/m
 ICA 15:                | 273.2M/174.7Mh/s | A:0 R:0 HW:9 U:0.00/m
 ICA 16:                | 330.7M/253.1Mh/s | A:0 R:0 HW:3 U:0.00/m
 ICA 17:                | 890.1M/457.4Mh/s | A:0 R:0 HW:3 U:0.00/m
 ICA 18:                | 150.4M/170.3Mh/s | A:0 R:0 HW:6 U:0.00/m
 ICA 19:                | 554.0M/319.4Mh/s | A:0 R:0 HW:5 U:0.00/m
--------------------------------------------------------------------------------

 [2013-02-08 12:38:54] ICA11: invalid nonce - HW error
 [2013-02-08 12:38:55] ICA1: invalid nonce - HW error
 [2013-02-08 12:38:56] ICA15: invalid nonce - HW error
 [2013-02-08 12:38:57] Icarus 2 Re-estimate: Hs=7.223040e-10 W=6.352486e-01 read_count=36 fullnonce=3.738s
 [2013-02-08 12:38:58] ICA7: invalid nonce - HW error
 [2013-02-08 12:39:01] ICA19: invalid nonce - HW error
 [2013-02-08 12:39:02] ICA3: invalid nonce - HW error
 [2013-02-08 12:39:02] Icarus 3 Re-estimate: Hs=-6.210501e-10 W=2.930369e+00 read_count=1 fullnonce=0.263s
 [2013-02-08 12:39:02] ICA12: invalid nonce - HW error
 [2013-02-08 12:39:04] ICA13: invalid nonce - HW error
 [2013-02-08 12:39:04] ICA7: invalid nonce - HW error
 [2013-02-08 12:39:05] ICA16: invalid nonce - HW error
 [2013-02-08 12:39:06] ICA10: invalid nonce - HW error
 [2013-02-08 12:39:07] ICA15: invalid nonce - HW error
 [2013-02-08 12:39:10] ICA10: invalid nonce - HW error
 [2013-02-08 12:39:11] ICA8: invalid nonce - HW error

See ICA 5/9/13 for example.

Thanks.

spiccioli

[YipYip]

Look maybe I have got the wrong product or the wrong s/w

Should u use cgminer for LTC with 79790 ?

Does anybody have a standard settings taht should get above 450+ for a power color 7970 card 2048 SP etc

Thanks in advance

[-ck]

Look maybe I have got the wrong product or the wrong s/w

Should u use cgminer for LTC with 79790 ?

Does anybody have a standard settings taht should get above 450+ for a power color 7970 card 2048 SP etc

Thanks in advance

--gpu-engine 1070 --gpu-memclock 1365 --thread-concurrency 8192 -g 5
gives me about 575 khash on my 7970s

[loshia]

Kon,

I see you are making some speed optimizations to cgminer constantly. Here are two commonly used functions (utils.c) which are speeding things up. I am running them for a week with latest cgminer git on openwrt host and i386 just fine.

Adopted from:
http://www.autohotkey.com/board/topic/19483-machine-code-functions-bit-wizardry/page-8
Thanks to Laszlo
bool hex2bin(unsigned char *p, const char *hexstr, size_t len)
{
   bool ret = false;
  unsigned char b, c, d;
  for(; {
      c = *hexstr++; if (c == 0) break;
      b = c >> 6;
      *p = ((c & 15) + b + (b << 3)) << 4;
      d = *hexstr++; if (d == 0) break;
      b = d >> 6;
      *p++ |= (d & 15) + b + (b << 3);
      len--;
   }

   if (likely(len == 0 && *hexstr == 0))
      ret = true;
   return ret;
}


 Adopted from ToHex:
http://nefigtut.ru/wp-content/uploads/2011/08/bitcoin-4diff.txt
Thanks to davids
char *bin2hex(const unsigned char *p, size_t len)
{
   unsigned int i = (unsigned int) len;
   unsigned char *iptr = (unsigned char *) p;
   static char hexmap[16] = { '0', '1', '2', '3', '4', '5', '6', '7',
                               '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' };
   ssize_t slen;
   char *s;

   slen = len * 2 + 1;
   if (slen % 4)
      slen += 4 - (slen % 4);
   s = calloc(slen, 1);
   if (unlikely(!s))
      quit(1, "Failed to calloc in bin2hex");
     int mm = 0;
      while (i-->  0)
    {
        s[mm++] = hexmap[*iptr>>4];
        s[mm++] = hexmap[*iptr&15];
        iptr++;
     }
     //s is calloced already - filled with zeros no need to terminate char
     //s[mm]=0;
   return s;
}

[K1773R]

ty ck for ec9b32aac0404b51fb969f753078cea525c8aafe
was already worried u did miss my post.

[K1773R]

just found out the scrypt cgminer crash, if compiled with -O2 the optimations lets it segfault, with -g it works fine.
gonna send u the core + binary per PN.

[-ck]

just found out the scrypt cgminer crash, if compiled with -O2 the optimations lets it segfault, with -g it works fine.
gonna send u the core + binary per PN.

Can't debug something unless it's with -g as well. -g shouldn't change the risk of crashing, but going from no optimisations to -O2 might.

[K1773R]

just found out the scrypt cgminer crash, if compiled with -O2 the optimations lets it segfault, with -g it works fine.
gonna send u the core + binary per PN.

Can't debug something unless it's with -g as well. -g shouldn't change the risk of crashing, but going from no optimisations to -O2 might.

sry, forgot to add the -g

[HolyScott]

Any chance of a Windows x64 build?

[-ck]

Any chance of a Windows x64 build?

What for? It provides precisely zero performance benefit and just uses more memory.

[crazyates]

Any chance of a Windows x64 build?

What for? It provides precisely zero performance benefit and just uses more memory.

But...but...LJR makes one! 

[sharky112065]

Any chance of a Windows x64 build?

What for? It provides precisely zero performance benefit and just uses more memory.

But...but...LJR makes one! 

64 is a higher number than 32, so it must be better right?

/sarcasm

[-ck]

I understand the generic desire for 64 bit builds, but this is one application that does not in any way benefit from the 64 bit builds and it just adds yet another step to making releases, and there is no reason for it. A lot of the windows world is still 32 bit so 32bit binaries work everywhere. Hardly any of the linux world is 32 bit so 32bit binaries are the opposite there (and building it on linux is trivial anyway).

[-ck]

just found out the scrypt cgminer crash, if compiled with -O2 the optimations lets it segfault, with -g it works fine.
gonna send u the core + binary per PN.

Can't debug something unless it's with -g as well. -g shouldn't change the risk of crashing, but going from no optimisations to -O2 might.

sry, forgot to add the -g

Thanks to K1773R I was able to debug this crash. What's more interesting is this was also responsible for scrypt not being able to set thread concurrencies higher than 9999 on cgminer. So there is a fix for this bug in git now, and I have also confirmed I can now set thread concurrencies as high as 12288 on my 7970s... though it did not improve their hashrate at all. However at least it solves that mystery.