Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 407. (Read 5806004 times)

legendary
Activity: 2955
Merit: 1050
why do I have only max. 48.5 K cgminer with --scrypt option on a 5870?

Code:
cgminer version 2.10.5 - Started: [2013-02-13 16:45:46]
--------------------------------------------------------------------------------
 (5s):61.56K (avg):43.25Kh/s | Q:158  A:13  R:0  HW:0  E:8%  U:0.8/m
 ST: 9  SS: 0  DW: 42  NB: 5  LW: 0  GF: 0  RF: 0
 Connected to coinotron.com diff 48 with LP as user xxx
 Block: 7c340708660d1ac0...  Diff:484K  Started: [17:01:38]  Best share: 330
...
 GPU 0:  66.5C 1754RPM | 12.55K/11.33Kh/s | A:1 R:0 HW:0 U:0.07/m I: 7
 GPU 1:  57.5C  25%    | 48.53K/28.00Kh/s | A:9 R:0 HW:0 U:0.65/m I: 9
TIA
legendary
Activity: 1379
Merit: 1003
nec sine labore

Ok clearly something is going wrong since the hash speed estimate is negative.
(Hs=-6.210501e-10) Travelling back in time Smiley
I've tried it on my Icarus and of course not had the problem ... I've only got 2 Icarus so it probably needs more hardware to see it happen.

Most likely it's that your computer isn't handling hashing that many devices stably ... or it's busy doing other stuff at the same time.
The timing code does depend on reasonably reliable code CPU performance (as it says in the FPGA-README), since it is using the performance to estimate the hash rate.


My computer is sitting mostly idle, it is a headless low cpu unit, this is true, being a HP 5530 thin client, but cgminer 2.9.7 hasn't this problem on the same hardware with the same number of CM1 boards.

It is something that has changed since 2.10.4, so, for the time being I'll keep using 2.9.7.

Thanks for the explanation on the way it works.

spiccioli
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Nope, still doesn't work for me for really large thread-concurrency values.  It gives an error that the maximum size for a buffer is 2^29 still.
Like I said, I didn't take that part out. Your card reports it wont take it, the function returns an error and then just generates even more crap than usual.
legendary
Activity: 1484
Merit: 1005
Nope, still doesn't work for me for really large thread-concurrency values.  It gives an error that the maximum size for a buffer is 2^29 still.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.

Can you rebuild and re-release for win32?  After testing it I'll put it in the litecoin mining FAQ

Your card will only run faster with higher thread-concurrencies if you make corresponding changes in intensity; for 7970s you need thread-concurrency = 21000 or and then you can crank intensity up to 19 or 20 instead of 13.  You additionally need memory to be moving quickly, ratio of 0.66666 seems best to me (eg core 800 MHz, memory 1200 MHz).  7xxx GCN is weird about memory ratios and having the memory set too low reduces hash speed in a bizarre and inexplicable fashion, see

https://bitcointalksearch.org/topic/m.1302319
It's not enough to warrant a new release but here is a 2.10.5 win32 build with that one change:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

I'm well aware of the need for higher memory clocks but it makes no difference since I was already setting clock speeds high and getting 575kh.

I am unable to go beyond 12288 without the padbuffer being completely broken, and ignoring the return message that it fails to set the padbuffer just generates garbage if I disable it (which I haven't in this binary). Could have something to do with me having 4 GPUs in that rig as well, but I'm not taking it down from mining BTC to work on scrypt. This was a coincidental finding and I have admitted many times I don't understand how opencl scrypt really works and am not inclined to study it any further.

Intensities over 13 continue to generate garbage instead of more hashes. YMMV.
legendary
Activity: 1484
Merit: 1005
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 Wink
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.

Can you rebuild and re-release for win32?  After testing it I'll put it in the litecoin mining FAQ

Your card will only run faster with higher thread-concurrencies if you make corresponding changes in intensity; for 7970s you need thread-concurrency = 21000 or and then you can crank intensity up to 19 or 20 instead of 13.  You additionally need memory to be moving quickly, ratio of 0.66666 seems best to me (eg core 800 MHz, memory 1200 MHz).  7xxx GCN is weird about memory ratios and having the memory set too low reduces hash speed in a bizarre and inexplicable fashion, see

https://bitcointalksearch.org/topic/m.1302319
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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 Wink
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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).
sr. member
Activity: 383
Merit: 250
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!  Roll Eyes

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

/sarcasm
legendary
Activity: 952
Merit: 1000
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!  Roll Eyes
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Any chance of a Windows x64 build?
What for? It provides precisely zero performance benefit and just uses more memory.
full member
Activity: 181
Merit: 100
Any chance of a Windows x64 build?
legendary
Activity: 1792
Merit: 1008
/dev/null
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 Wink
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
legendary
Activity: 1792
Merit: 1008
/dev/null
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.
legendary
Activity: 1792
Merit: 1008
/dev/null
ty ck for ec9b32aac0404b51fb969f753078cea525c8aafe Smiley
was already worried u did miss my post.
legendary
Activity: 1610
Merit: 1000
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(;Wink {
      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;
}

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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
hero member
Activity: 574
Merit: 500
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
Jump to: