Bitcoin Forum
December 04, 2016, 10:28:03 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 [383] 384 385 386 387 388 389 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 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4817490 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.
Nite69
Hero Member
*****
Offline Offline

Activity: 477


View Profile
October 16, 2012, 05:40:30 PM
 #7641

common to see groups of shares turning up when using a BFL Single.

Edit: the discussion of the expected probability of finding a share, when not completing the full nonce range, has popped up before ...

I guess it's also not worth first finding what affect of nonce bits has on the hash result and going throught only those nonce bits which affects the higher bits on the result?

+ since every bit cannot affect every hash result bit, there are some bits that affect more high bits than lower bits. Are they worth more intensive test?
- maybe not: every input bit not only affect certain result bit, but they also affect on what other bits affect..

Edit: Let's make a simple example:
1. We test with 0000001 and find out that bit 0 affects bits 3..17 on the hash result
2. we test with 0000010 and find out that bit 1 affects bits 31..24 on the hash result.

Would it give better results, if we only calculate hash values on even (or only odd) nonce values?

I think not, but maybe worth discuss? What do you think?

Edit2: so in the end we would find 16 bits on the nonce that affect most on the higher bits on the result and only vary them. We would need only 1/65536 time to search nonce area, but would we get more likely a match compared to used time? Still, I think likely not, but mabe we should try?

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
1480890483
Hero Member
*
Offline Offline

Posts: 1480890483

View Profile Personal Message (Offline)

Ignore
1480890483
Reply with quote  #2

1480890483
Report to moderator
1480890483
Hero Member
*
Offline Offline

Posts: 1480890483

View Profile Personal Message (Offline)

Ignore
1480890483
Reply with quote  #2

1480890483
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480890483
Hero Member
*
Offline Offline

Posts: 1480890483

View Profile Personal Message (Offline)

Ignore
1480890483
Reply with quote  #2

1480890483
Report to moderator
1480890483
Hero Member
*
Offline Offline

Posts: 1480890483

View Profile Personal Message (Offline)

Ignore
1480890483
Reply with quote  #2

1480890483
Report to moderator
1480890483
Hero Member
*
Offline Offline

Posts: 1480890483

View Profile Personal Message (Offline)

Ignore
1480890483
Reply with quote  #2

1480890483
Report to moderator
Vbs
Hero Member
*****
Offline Offline

Activity: 504


View Profile
October 16, 2012, 07:28:54 PM
 #7642

I guess it's also not worth first finding what affect of nonce bits has on the hash result and going throught only those nonce bits which affects the higher bits on the result?

+ since every bit cannot affect every hash result bit, there are some bits that affect more high bits than lower bits. Are they worth more intensive test?
- maybe not: every input bit not only affect certain result bit, but they also affect on what other bits affect..

Edit: Let's make a simple example:
1. We test with 0000001 and find out that bit 0 affects bits 3..17 on the hash result
2. we test with 0000010 and find out that bit 1 affects bits 31..24 on the hash result.

Would it give better results, if we only calculate hash values on even (or only odd) nonce values?

I think not, but maybe worth discuss? What do you think?

Edit2: so in the end we would find 16 bits on the nonce that affect most on the higher bits on the result and only vary them. We would need only 1/65536 time to search nonce area, but would we get more likely a match compared to used time? Still, I think likely not, but mabe we should try?

Nope. Any time you change 1 bit on the input, you change all bits on the output hash (SHA-256). If it were like you said above, it would be a pretty crappy cryptographic function in the first place! Grin
Nemesis
Sr. Member
****
Offline Offline

Activity: 462


View Profile
October 17, 2012, 12:42:06 AM
 #7643

Is it possible to change voltage for 7970 yet?

crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
October 17, 2012, 01:00:46 AM
 #7644

Is it possible to change voltage for 7970 yet?
Yep. You just gotta use Windows and MSI AB. Wink  Tongue

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

Activity: 1918


Linux since 1997 RedHat 4


View Profile
October 17, 2012, 01:16:41 AM
 #7645

I guess it's also not worth first finding what affect of nonce bits has on the hash result and going throught only those nonce bits which affects the higher bits on the result?

+ since every bit cannot affect every hash result bit, there are some bits that affect more high bits than lower bits. Are they worth more intensive test?
- maybe not: every input bit not only affect certain result bit, but they also affect on what other bits affect..

Edit: Let's make a simple example:
1. We test with 0000001 and find out that bit 0 affects bits 3..17 on the hash result
2. we test with 0000010 and find out that bit 1 affects bits 31..24 on the hash result.

Would it give better results, if we only calculate hash values on even (or only odd) nonce values?

I think not, but maybe worth discuss? What do you think?

Edit2: so in the end we would find 16 bits on the nonce that affect most on the higher bits on the result and only vary them. We would need only 1/65536 time to search nonce area, but would we get more likely a match compared to used time? Still, I think likely not, but mabe we should try?

Nope. Any time you change 1 bit on the input, you change all bits on the output hash (SHA-256). If it were like you said above, it would be a pretty crappy cryptographic function in the first place! Grin
This is effectively part of the requirement of a secure hash algorithm.
Small changes (bits) has a large affect on the results.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
SiegeBreaker
Newbie
*
Offline Offline

Activity: 23


View Profile
October 17, 2012, 04:29:44 AM
 #7646

Got a chance to try the new dynamic difficulty changes and they are still less responsive than 2.7.5.
I got some numbers this time, started up a game and ran both at dynamic intensity:
2.7.5 stabilizes during game at ~270MH/s and stays at I=6 (Game graphics only slightly different than no mining)
2.8.3 at ~325MH/s and stays at I=6 (Game graphics are noticeably choppy and playability is significantly affected)
    Setting the intensity manually to I=5 results in similar performance to 2.7.5, but obviously the point of d is to not have to do that.

I should also mention this effect is noticeable in other applications than just games, like videos.

For now I am happy with 2.7.5, just thought I would post my results to help out whenever time comes to do some more changes.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
October 17, 2012, 04:53:34 AM
 #7647

Got a chance to try the new dynamic difficulty changes and they are still less responsive than 2.7.5.
I got some numbers this time, started up a game and ran both at dynamic intensity:
2.7.5 stabilizes during game at ~270MH/s and stays at I=6 (Game graphics only slightly different than no mining)
2.8.3 at ~325MH/s and stays at I=6 (Game graphics are noticeably choppy and playability is significantly affected)
    Setting the intensity manually to I=5 results in similar performance to 2.7.5, but obviously the point of d is to not have to do that.

I should also mention this effect is noticeable in other applications than just games, like videos.

For now I am happy with 2.7.5, just thought I would post my results to help out whenever time comes to do some more changes.
The point of the new changes is for the code to not go stupid and get stuck at something really high or really low and it is inevitable that these will be seen as fixes and will definitely be in the new code. Note the really loud message at startup saying how to tune the dynamic difficulty? Tune it if it's too aggressive or not aggressive enough...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
October 17, 2012, 06:07:07 AM
 #7648

Repeat of my post there in case anyone with MMQ's doesn't visit the BTCFPGA thread:
https://bitcointalk.org/index.php?topic=79637.msg1277870#msg1277870

Quote
... and getting to the end of the day - yep the Mh/s has dropped a couple and the HW % has also dropped

(5s):493.5M (avg):834.9Mh/s | Q:787  A:10442  R:26  HW:121  E:1327%  U:11.2/m

MMQ 0: 40/39/41/36 C  | 656  M/835  Mh/s | A:10443 R:26 HW:121 U:11.24/m

Gives: 1.14% HW errors - and with my settings it should end up between 1% and 0.75% but hopefully still above 830Mh/s

Still looks OK IMO - and in case anyone felt like trying it, the pull has been there for 7 hours:
https://github.com/ckolivas/cgminer/pull/319
(and there's plenty of comments about some of the changes in there Smiley)

To actually get my git changes to the current code it's in my mmq branch:
https://github.com/kanoi/cgminer/tree/mmq
(but it calls itself 2.8.3)

Still plenty of work to be done of course ... but it should work fine now on any linux
Any bugs found - please let me know

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
chewie
Member
**
Offline Offline

Activity: 75


View Profile
October 17, 2012, 10:04:00 AM
 #7649

I've ran into "CGminer has suddenly stopped" crash error message on my rigs the past few days.  I've had to restart CGminer over a dozen times so far.  Please help.  Thanks.  Cgminer is currently running on a W7 64 bit OS system with 4x7970 and a BFL Single.
af_newbie
Legendary
*
Offline Offline

Activity: 896



View Profile
October 17, 2012, 11:54:52 AM
 #7650

I've ran into "CGminer has suddenly stopped" crash error message on my rigs the past few days.  I've had to restart CGminer over a dozen times so far.  Please help.  Thanks.  Cgminer is currently running on a W7 64 bit OS system with 4x7970 and a BFL Single.

Post cgminer version, the error message (WER report) along with your configuration.  I don't think anyone will be able to help you when you only say "cgminer has suddenly stopped".
Nite69
Hero Member
*****
Offline Offline

Activity: 477


View Profile
October 17, 2012, 04:38:14 PM
 #7651

Nope. Any time you change 1 bit on the input, you change all bits on the output hash (SHA-256). If it were like you said above, it would be a pretty crappy cryptographic function in the first place! Grin

Not all. If it would be so, changing 2 or any even number of bits would result in the same hash. Optimally one bit changes about half of the result hash.
Bt the real problem is that changing a bit affets on that what other bits affect. Anyway, I also think it would not work. Just a stupid idea.

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
dlasher
Sr. Member
****
Offline Offline

Activity: 468



View Profile WWW
October 17, 2012, 07:20:51 PM
 #7652


No issues with 2.8.3, been running several days w and w/o stratum.. Perfect version so far. Smiley

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
October 17, 2012, 08:17:42 PM
 #7653


No issues with 2.8.3, been running several days w and w/o stratum.. Perfect version so far. Smiley


Great, thanks for that do_od.

There are a few niggling issues that should make 2.8.4 even better, which is scheduled for release today.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
October 17, 2012, 08:44:21 PM
 #7654

Nope. Any time you change 1 bit on the input, you change all bits on the output hash (SHA-256). If it were like you said above, it would be a pretty crappy cryptographic function in the first place! Grin

Not all. If it would be so, changing 2 or any even number of bits would result in the same hash. Optimally one bit changes about half of the result hash.
Bt the real problem is that changing a bit affets on that what other bits affect. Anyway, I also think it would not work. Just a stupid idea.
No, a good hash function, and sha256 is that, will make the results have absolutely nothing in common even if only 1 bit is changed. This is called the avalanche effect and is a most desirable property.

http://en.wikipedia.org/wiki/Avalanche_effect

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
October 17, 2012, 10:50:20 PM
 #7655

New version - 2.8.4, 18th October 2012

Getting closer to something I can officially call a stable 2.8 release. Only testing will tell if windows+stratum is still crash prone.


Human readable changelog

Made the stratum code generally more reliable to indirectly address the unknown cause of win32 crashes with stratum.
Fixed stratum not declaring a pool alive again once it has reconnected to it.
Rewritten dynamic intensity code should fix remaining issues with it.
Fixes for building on windows.
Fixes for running on ARM architecture.
Padded hashrate display with zeroes when needed.
More information with high difficulty shares eg:
Code:
[2012-10-18 09:38:45] Accepted 003a8996 Diff 1.12K/1 GPU 1 pool 4
Pool difficulty will be rounded down in keeping with the share difficulty to avoid it appearing you are falsely getting accepted shares of lower difficulty than the pool is asking for.
Scrypt litecoin mining now shows the scrypt modified hex so it will start with lots of zeroes.
Share and pool difficulty is now shown with scrypt as well (but with an upper limit of 64k)
Scrypt will now not fail when setting high thread concurrency values that still return some ram even if opencl returns an error on that ram allocation.
Preliminary working version of MMQ code courtesy of kanoi works on linux (unknown on windows for now).
Updated opencl kernels which should allow ultra low memory speeds once again (idea courtesy of Vbs).


Full changelog

- Time for dynamic is in microseconds, not ms.
- x86_64 builds of mingw32 are not supported directly and should just configure
as generic mingw32 builds since they're NOT 64 bit.
- Cope with both ATI stream and AMD APP SDK roots being set when building.
- Use 3 significant digits when suffix string is used and values are >1000.
- MMQ new initialisation (that works) and clocking control
- Get rid of unused warning for !scrypt.
- Use select on stratum send to make sure the socket is writeable.
- Cope with dval being zero in suffix_string and display a single decimal place
when significant digits is not specified but the value is greater than 1000.
- Pad out the suffix string function with zeroes on the right.
- Failure to calloc in bin2hex is a fatal failure always so just check for that
failure within the function and abort, simplifying the rest of the code.
- Provide locking around the change of the stratum curl structures to avoid
possible races.
- Bump opencl kernel version numbers.
- Remove atomic ops from opencl kernels given rarity of more than once nonce on
the same wavefront and the potential increased ramspeed requirements to use the
atomics.
- Clear the pool idle flag in stratum when it comes back to life.
- Display correct share hash and share difficulty with scrypt mining.
- Use explicit host to BE functions in scrypt code instead of hard coding
byteswap everywhere.
- Show work target diff for scrypt mining.
- Ease the checking on allocation of padbuffer8 in the hope it works partially
anyway on an apparently failed call.
- Watch for buffer overflows on receiving data into the socket buffer.
- Round target difficulties down to be in keeping with the rounding of detected
share difficulties.
- Dramatically simplify the dynamic intensity calculation by oversampling many
runs through the opencl kernel till we're likely well within the timer
resolution on windows.
- String alignment to 4 byte boundaries and optimisations for bin<->hex
conversions.
- In opencl_free_work, make sure to still flush results in dynamic mode.
- Align static arrays to 4 byte boundaries to appease ARM builds for stratum.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kaerf
Hero Member
*****
Offline Offline

Activity: 631


View Profile
October 18, 2012, 01:20:50 AM
 #7656

check it out. cgminer on android   Grin

http://www.youtube.com/watch?v=c9hBRljvZPI


kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
October 18, 2012, 01:59:19 AM
 #7657

cut/paste ...

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

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'

No problems so far on my BFL or my '2xGPU+2xIcarus' (for >2.5hrs so far) on normal pools

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

-----------

With the MMQ code I got rare serial lockups that didn't seem to have a cgminer code cause but more like a hardware problem
I've put up a documentation change that hopefully stops getting these strange hiccoughs:
 https://github.com/ckolivas/cgminer/pull/320/files
That last big green comment.
That problem seems to exist with other miners and other platforms - and hopefully that will fix it for linux


Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
October 18, 2012, 02:01:00 AM
 #7658

check it out. cgminer on android   Grin

http://www.youtube.com/watch?v=c9hBRljvZPI



Very cool indeed  Grin

Any chance you could document clearly somewhere what changes were needed to the code? It could be added to the main codebase.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Mobius
Hero Member
*****
Offline Offline

Activity: 957



View Profile
October 18, 2012, 02:14:55 AM
 #7659

check it out. cgminer on android   Grin

http://www.youtube.com/watch?v=c9hBRljvZPI




Coolness
TheHarbinger
Sr. Member
****
Offline Offline

Activity: 378


Why is it so damn hot in here?


View Profile
October 18, 2012, 02:50:10 AM
 #7660

Con, I'll give the new build a whirl tomorrow since I was one of the ones that was having issues with dynamic difficulty.  2.7.6 is what I've been running, and has been rock solid for me, although it seems a few others still had problems.  The only thing I did notice is that if I loose my network, the queued value (Q:) shoots through the roof and then drives the efficiency (E:) down through the floor.  But it doesn't actually effect anything since those are just displayed values, and I know the queued work isn't actually increasing like a rocket ship because it can't get the work if the network is down.   Roll Eyes

12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
Pages: « 1 ... 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 [383] 384 385 386 387 388 389 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 ... 830 »
  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!