Bitcoin Forum
December 14, 2018, 12:04:44 AM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
   Home   Help Search Login Register More  
Pages: « 1 ... 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 [440] 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 ... 846 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5766741 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2730
Merit: 1148


Ruu \o/


View Profile WWW
February 10, 2013, 03:32:33 AM
 #8781

Any chance of a Windows x64 build?
What for? It provides precisely zero performance benefit and just uses more memory.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1544745884
Hero Member
*
Offline Offline

Posts: 1544745884

View Profile Personal Message (Offline)

Ignore
1544745884
Reply with quote  #2

1544745884
Report to moderator
1544745884
Hero Member
*
Offline Offline

Posts: 1544745884

View Profile Personal Message (Offline)

Ignore
1544745884
Reply with quote  #2

1544745884
Report to moderator
1544745884
Hero Member
*
Offline Offline

Posts: 1544745884

View Profile Personal Message (Offline)

Ignore
1544745884
Reply with quote  #2

1544745884
Report to moderator
crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
February 10, 2013, 04:25:12 AM
 #8782

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

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
sharky112065
Sr. Member
****
Offline Offline

Activity: 382
Merit: 250



View Profile
February 10, 2013, 06:24:59 AM
 #8783

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

Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2730
Merit: 1148


Ruu \o/


View Profile WWW
February 10, 2013, 07:24:55 AM
 #8784

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

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2730
Merit: 1148


Ruu \o/


View Profile WWW
February 10, 2013, 09:38:39 AM
 #8785

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.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 2660
Merit: 1059


Linux since 1997 RedHat 4


View Profile
February 10, 2013, 12:50:00 PM
 #8786

...

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

How the code works is that it uses the hash answers to estimate a line of best fit (using least squares) to determine a reasonable estimate of the hashing speed.
Bad hash values can skew the line badly and cause invalid results if the number of sample points is small (which it is early on)
Oddly enough you probably will find it is still getting a reasonable U: value for the ones with the weird MH/s values.
If it is using read_count=1 (the minimum) it just means it is aborting work really early and thus doing about 100x the work generation work to get the same results.
Of course that is not at all desirable and will reduce the performance of that device, but it will still hash away anyway.

There's a simple fix (well it should fix it) that will give you very close to maximum hashing performance but the MH/s shown on the screen will most likely be incorrect.
The fix is to simply use --icarus-timing Hns:Timeout with values that you know are below the fastest card, but close to the limit (which is what the timing code estimates)
The second value in Icarus timing is how long (in 1/10ths of a second) to let the cards hash for before interrupting it with new work.
The first one is an estimate of how long it takes to do a single hash, so it can estimate how many hashes it did when it aborts any work, to determine the MH/s value.
Even Timeout estimates under by 4 or 5 times will still get you close to the best U: value.
If the value is close to the time it takes to complete a nonce range then it will maximise it's performance.
If it is a little below that, it still will be very close to maximum performance anyway.
If you are certain that none of your devices hash faster than 500Mh/s you can manually calculate values to use.

So assuming 500Mh/s is the fastest, it means it will complete a nonce range in 8.59 seconds.
We can take a guess of: an average performance of all the cards of around 250MH/s ? So that means each hash takes on average 4ns
So using --icarus-timing 4.0=84 should be OK based on those estimates.
The value 84 should always be OK - no need to adjust it at all unless you really are hashing at faster than 500MH/s on any board; and the slower boards, that number is OK also - even down to 100Mh/s it really doesn't matter too much.
The value 4.0ns will mean that the MH/s hash rate shown will get nudged towards 250MH/s every time it fails to find a nonce before 8.4s (or an LP happens) Thus for any cards doing 250MH/s it will show that correctly, for any others it will nudge them towards 250MH/s every so often, so will read low for the cards that hash above 250MH/s and high for the cards that hash below 250MH/s - however it will NOT affect the U: rate significantly.
Of course U: can take a few days to start to converge on the expected value ...

So without a LOT more information about the hashing speed and other details of your boards, using --icarus-timing 4.0=84 should be close to maximising your shares anyway.
You can of course set a different pair of values for each card if you want as such:
--icarus-timing 4.0=84,3.6=84,2.6=84,3=84
A normal Icarus board is 380Mh/s which is: --icarus-timing 2.6316=112 (the default settings inside the driver)
If you have more cards than you specify, it will use the last for each of the extra cards.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1000



View Profile
February 10, 2013, 11:55:14 PM
 #8787

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://bitcointalk.org/index.php?topic=117221.msg1302319#msg1302319

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2730
Merit: 1148


Ruu \o/


View Profile WWW
February 11, 2013, 01:55:05 AM
 #8788

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://bitcointalk.org/index.php?topic=117221.msg1302319#msg1302319
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.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1000



View Profile
February 11, 2013, 03:36:10 AM
 #8789

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.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2730
Merit: 1148


Ruu \o/


View Profile WWW
February 11, 2013, 03:39:30 AM
 #8790

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.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
spiccioli
Legendary
*
Offline Offline

Activity: 1376
Merit: 1000

nec sine labore


View Profile
February 11, 2013, 08:54:27 PM
 #8791


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
ewibit
Legendary
*
Offline Offline

Activity: 2349
Merit: 1000


"Highest ROI crypto infrastructure"


View Profile
February 13, 2013, 07:48:42 PM
 #8792

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


           ▄████████▄           ▄███████▄
          ████████████▄       ▄███████████
         ██████████████████████████████████
         ██████████████████████████████████
         ██████████████████████████████████                                              █████
          ████████████▀       ▀███████████                                               █████
            ▀██████▀            ▀██████▀                                                     
   ▄▄▄▄▄▄              ▄▄▄▄▄▄             █████████      ███████████    ████▒     █████  █████     ▄█████████▄     ███████████
 ██████████          ██████████          ███████████▒    ████████████    ████     ████   █████    █████████████    ████████████
█████████████       ████████████        ████     ████    ████    ▒████   █████   ████    █████   ▒████     ████▒   ████▒  ░░████
█████████████      ██████████████      ██████████████▒   ████     ████    ████   ████    █████   ████      ▒████   ████▒    ████
█████████████      ██████████████      █████▒▒▒▒▒▒▒▒▒    ████     ████     ████ ████     █████   ████▒     ▒████   ████▒    ████
█████████████       ████████████        ████▒            ████     ████      ███████      █████    ████     ████    ████▒    ████
 ▀█████████▀         ▀████████▀          ███████████     ████     ████      ▒█████       █████     ███████████     ████▒    ████
                                           ▀██████▒      ████     ████       ▒███        █████       ▀█████▀       ████▒    ████
           ▄████████▄          ▄████████▄
          ████████████▄      ▄████████████
         ██████████████████████████████████
         ██████████████████████████████████
          ████████████████████████████████
           ██████████▀        ▀██████████ 
            ▀██████▀            ▀██████▀ 
    WORLD'S MOST PROFITABLE STANDARD
  OF SELF-EXPANDING CRYPTO INFRASTRUCTURE
FACEBOOK 】【 TWITTER
        ANN THREAD
TELEGRAM MEDIUM
 
  Join our ICO: 
Dec. 1-31 │ Whitepaper 
wndrbr3d
Hero Member
*****
Offline Offline

Activity: 924
Merit: 500


The Premier Digital Asset Management Ecosystem


View Profile
February 13, 2013, 09:23:57 PM
 #8793

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

Although your post lacks info, I'm also having performance issues with a 5870 on the latest build of CGMiner doing Scrypt, so perhaps our symptoms are related.

I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date. The command line I'm using is:

Code:
./cgminer --scrypt -o http://pool:9332 -u username -p password --worksize 256 --shaders 1600 --intensity 11 -g 1

I'm currently only geting about 150Khash/sec on this card and unable to push past intensity 11 without getting GPU errors such as:
                 
Code:
[2013-02-13 08:44:46] GPU 1 found something?                   
 [2013-02-13 08:44:46] OCL NONCE 3247859 found in slot 0                   
 [2013-02-13 08:44:46] Scrypt error, review settings                   
 [2013-02-13 08:44:47] GPU 1 found something?                   
 [2013-02-13 08:44:47] OCL NONCE 3608809 found in slot 0                   
 [2013-02-13 08:44:47] Scrypt error, review settings                   
 [2013-02-13 08:44:48] GPU 1 found something?                   
 [2013-02-13 08:44:48] OCL NONCE 3788290 found in slot 0                   
 [2013-02-13 08:44:48] Scrypt error, review settings                   
 [2013-02-13 08:44:48] GPU 1 found something?           

Using the same card with CGMiner in Windows I'm able to get 300Khash/sec no problem with a higher intensity (19) and no hardware errors.

Curious if anyone else is having this issue! Thanks in advance! Smiley



▄▄           ▄▄▄▄▄▄             ▄▄▄▄▄▄           ▄▄         ▄▄        ▄▄             ▄▄▄▄▄▄            ▄▄                  ▄             ▄▄▄▄▄▄▄ 
██        ▄██▀▀▀▀▀▀██        ▄██▀▀▀▀▀▀██▄        ███▄       ██        ██          ▄██▀▀▀▀▀▀██▄         ██                 ███            ██▀▀▀▀██▄
██       ██▀                ██▀        ▀██       █████▄     ██        ██         ██▀        ▀██        ██                ██ ██           ██     ██
██      ▐█▌                ▐█▌          ▐█▌      ██ ▀███▄   ██        ██        ▐█▌          ▐█▌       ██               ██   ██          ██▄▄▄▄█▀
██      ▐█▌                ▐█▌          ▐█▌      ██   ▀███▄ ██        ██        ▐█▌          ▐█▌       ██              ██     ██         ██▀▀▀▀██▄
██       ██▄                ██▄        ▄██       ██     ▀█████        ██         ██▄      ▄▄  █        ██             ██       ██        ██     ██
██        ▀██▄▄▄▄▄▄██        ▀██▄▄▄▄▄▄██▀        ██       ▀███        ██          ▀██▄▄▄▄▄ ██          ██▄▄▄▄▄▄      ██         ██       ██▄▄▄▄██▀
▀▀           ▀▀▀▀▀▀             ▀▀▀▀▀▀           ▀▀         ▀▀        ▀▀             ▀▀▀▀▀  ▀▀         ▀▀▀▀▀▀▀▀     ▀▀           ▀▀      ▀▀▀▀▀▀▀ 
           ▄▄███▄▄
     ▄▄███████████▄▄
 ▄▄███████████████████▄▄
███████████▌ ▐███████████
██▌ ▐███████ ███████▌ ▐██
███ ████▀▀██ ██▀▀████ ███
███ ██▀▄████ ████▄▀██ ███
███ ██ █████ █████ ██ ███
███ ██ █████ █████ ██ ███
███ ██ █████ █████ ██ ███
 ▀▀ ██ █████ █████ ██ ▀▀
     ▀ █████ █████ ▀
         ▀▀█ █▀▀
The Premier   ───────────────────
Digital Asset Management Ecosystem
────────   Powered by the ICNQ Token


▾  Medium
▾  Twitter
▾  LinkedIn
▾  Subscribe


.I C N Q   T O K E N.

The Token for Digital Asset Management
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2730
Merit: 1148


Ruu \o/


View Profile WWW
February 13, 2013, 10:14:41 PM
 #8794

I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date.
13.1 is fucked.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
wndrbr3d
Hero Member
*****
Offline Offline

Activity: 924
Merit: 500


The Premier Digital Asset Management Ecosystem


View Profile
February 13, 2013, 11:19:04 PM
 #8795

I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date.
13.1 is fucked.

Would it be possible to update the first post with the optimal driver/sdk config for CGMiner? Not knowing this, I just defaulted to latest Wink



▄▄           ▄▄▄▄▄▄             ▄▄▄▄▄▄           ▄▄         ▄▄        ▄▄             ▄▄▄▄▄▄            ▄▄                  ▄             ▄▄▄▄▄▄▄ 
██        ▄██▀▀▀▀▀▀██        ▄██▀▀▀▀▀▀██▄        ███▄       ██        ██          ▄██▀▀▀▀▀▀██▄         ██                 ███            ██▀▀▀▀██▄
██       ██▀                ██▀        ▀██       █████▄     ██        ██         ██▀        ▀██        ██                ██ ██           ██     ██
██      ▐█▌                ▐█▌          ▐█▌      ██ ▀███▄   ██        ██        ▐█▌          ▐█▌       ██               ██   ██          ██▄▄▄▄█▀
██      ▐█▌                ▐█▌          ▐█▌      ██   ▀███▄ ██        ██        ▐█▌          ▐█▌       ██              ██     ██         ██▀▀▀▀██▄
██       ██▄                ██▄        ▄██       ██     ▀█████        ██         ██▄      ▄▄  █        ██             ██       ██        ██     ██
██        ▀██▄▄▄▄▄▄██        ▀██▄▄▄▄▄▄██▀        ██       ▀███        ██          ▀██▄▄▄▄▄ ██          ██▄▄▄▄▄▄      ██         ██       ██▄▄▄▄██▀
▀▀           ▀▀▀▀▀▀             ▀▀▀▀▀▀           ▀▀         ▀▀        ▀▀             ▀▀▀▀▀  ▀▀         ▀▀▀▀▀▀▀▀     ▀▀           ▀▀      ▀▀▀▀▀▀▀ 
           ▄▄███▄▄
     ▄▄███████████▄▄
 ▄▄███████████████████▄▄
███████████▌ ▐███████████
██▌ ▐███████ ███████▌ ▐██
███ ████▀▀██ ██▀▀████ ███
███ ██▀▄████ ████▄▀██ ███
███ ██ █████ █████ ██ ███
███ ██ █████ █████ ██ ███
███ ██ █████ █████ ██ ███
 ▀▀ ██ █████ █████ ██ ▀▀
     ▀ █████ █████ ▀
         ▀▀█ █▀▀
The Premier   ───────────────────
Digital Asset Management Ecosystem
────────   Powered by the ICNQ Token


▾  Medium
▾  Twitter
▾  LinkedIn
▾  Subscribe


.I C N Q   T O K E N.

The Token for Digital Asset Management
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2730
Merit: 1148


Ruu \o/


View Profile WWW
February 13, 2013, 11:22:31 PM
 #8796

I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date.
13.1 is fucked.

Would it be possible to update the first post with the optimal driver/sdk config for CGMiner? Not knowing this, I just defaulted to latest Wink
It keeps changing as AMD skillfully keeps releasing broken shit... plus GPUs are going the way of the dodos shortly for BTC, so our attention to GPU issues is dropping off to almost zero. Try driver 12.8

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
February 13, 2013, 11:39:19 PM
 #8797

I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date.
13.1 is fucked.
Would it be possible to update the first post with the optimal driver/sdk config for CGMiner? Not knowing this, I just defaulted to latest Wink
It keeps changing as AMD skillfully keeps releasing broken shit... plus GPUs are going the way of the dodos shortly for BTC, so our attention to GPU issues is dropping off to almost zero. Try driver 12.8
Is it the driver that keeps mucking things up, or the ocl runtime that gets updated every month?

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
February 15, 2013, 08:26:04 AM
 #8798

Kon,

There is a potential memleak introduced with latest commit:
Add timestamps to stratum_share structs as they're generated and copy
https://github.com/ckolivas/cgminer/commit/1bf1f4a2174c28a3ae358c6a8b9544e93f35bfac

work->sessionid = strdup(pool->sessionid);

However work->sessionid has been never freed.

Probably the right place to free it is:

void clean_work(struct work *work) {
  if(work->sessionid)
      free(work->sessionid);
....

}

More over it might be a memleak here also even though i am not quite sure about it

https://github.com/ckolivas/cgminer/commit/c851f3959894379b213cd81ecbf8317b2ad4f313

pool->sessionid = json_array_string(res_val, 3);

if json_array_string returns a copy pool->sessionid shall be freed also somewhere right?


PS: probably this is not an issue as long as  json_array_string - > json_array_get returns  Borrowed reference and there is no need to be freed

Thank you Kon! it has been fixed:
https://github.com/ckolivas/cgminer/commit/16c7c983ae9e5ce03a2adc2c573a0c62bfdfefde


 

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
Askit2
Hero Member
*****
Offline Offline

Activity: 986
Merit: 500


DIV - Your "Virtual Life" Secured and Decentralize


View Profile
February 19, 2013, 09:38:53 AM
 #8799

I noticed with 2.10.4 and in 2.10.5 that when the stratum pool disconnects CGMiner keeps working on that pool's work. At least it appears that is what it does. I get a disconnect and eventually a number of shares discarded last time I noticed it was 17. Of course this seems like too many to me with 1 BFL single currently running on Eclipse 1 at a WU of 12.

The reasons I think it keeps working on the disconnected pool for 2 reason. Both may be faulty and I don't want to alarm anyone. Firstly the discarded shares are usually 60-90 seconds after the disconnect. Expiry would account for that much but not why I had 90 seconds backlog at disconnect. If the pool hadn't taken 90 seconds worth of work it was already sick or dying. Secondly although the BFL single keeps hashing I see no mention of swiching pools (it could be a cosmetic issue). This is substantiated by bad luck notwithstanding 0 shares being delivered to 3 backup pools (eclipse 2 diff1, Eclipse 3 diff1 and a local bitpenny Diff8). I am sure that in 60 seconds I wouldn't expect to see a share everytime for difficulty 8 bitpenny. Aside from a work unit being used from getwork while switching to a stratum server on a change I would expect 1 work unit to bitpenny, then (in 60 seconds) ~11 to eclipse 2 (the next pool in order). I also have never noticed the pool at the top Connected to (blah blah blah) change when this happens. Again that could be cosmetic.

Running windows 7, 1 BFL single, and stratum to Eclipse (three different servers) and a backup bitpenny using getwork.

Also I am pretty sure even factoring in discards as rejects my reject rate is lower using stratum. Thank You for the stratum support.

          ▄▄
        ▄█▀▀█▄
      ▄█▀ ▄▄ ▀█▄
      ▀ ▄████▄ ▀
   ▄▀ ▄ ▀████▀ ▄ ▀▄
 ▄▀ ▄███▄ ▀▀ ▄███▄ ▀▄
█  ███████  ███████  █
 ▀▄ ▀███▀ ▄▄ ▀███▀ ▄▀

   ▀▄ ▀ ▄████▄ ▀ ▄▀
      ▄ ▀████▀ ▄
      ▀█▄ ▀▀ ▄█▀
        ▀█▄▄█▀
          ▀▀
███████████████████████████████████████████████████████████████████
██████▀▀▀▀▀▀▀▀▀▀▀██████████▀▀▀▀▀████▀▀▀▀▀█████▀▀▀▀█████▀▀▀▀▀███████
██████            ▀████████     ████     █████    █████     ███████
██████     ▄▄▄▄▄    ▀██████     █████    ████      ████    ████████
██████     ██████▄    █████     █████    ▀██▀  ▄▄  ▀██▀    ████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████     █   ██   █     █████████
██████     █████▀    ██████     ███████       ████       ██████████
██████     ▀▀▀▀▀    ▄██████     ████████     ██████     ███████████
██████            ▄████████     ████████     ██████     ███████████
██████▄▄▄▄▄▄▄▄▄▄▄██████████▄▄▄▄▄█████████▄▄▄▄██████▄▄▄▄████████████
███████████████████████████████████████████████████████████████████
.DIWtoken.com.
▄██████████████████▄
███       ▀███████
███       █████████
███       █████████
███       █████████
███              ██
███   ▄▄▄▄▄▄▄▄   ███
███   ▄▄▄▄▄▄▄▄   ███
███              ███
███▄▄▄▄▄▄▄▄▄▄▄▄▄▄███
██████████████████▀

▄██████████████████▄
███████████▀ ███████
█████████▀   ███████
███████▀     ██▀ ███
███ ▀▀       █▄▄████
███          █▀▀▀▀██
███ ▄▄       ███████
██████▄     █▄ ▀███
█████████▄   ███▄███
███████████▄ ███████
▀██████████████████▀

▄██████████████████▄
████████████████████
███████████████▀▀ ██
█████████▀▀     ███
████▀▀     ▄█▀   ███
███▄    ▄██      ███
█████████▀      ▄██
█████████▄     ████
█████████████▄ ▄████
████████████████████
▀██████████████████▀
......SECURITY DECENTRALIZED...
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2730
Merit: 1148


Ruu \o/


View Profile WWW
February 19, 2013, 09:43:26 AM
 #8800

You're welcome.

The issue is some disconnects are impossible to detect, apart from noticing the pool has gone silent for an extended time. During that sort of outage, cgminer continues mining until it times out, not getting a response. The timeout needs to be long enough to be sure the pool is no longer sending info, and not too long to waste ages mining. So yes, it keeps mining. Anyway hopefully this should be better since the next version will include support for the new mining.resume function. This is already built into the git version, but only rEligius currently supports it. Hopefully other pools will follow suit.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 ... 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 [440] 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 ... 846 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!