Bitcoin Forum
February 18, 2019, 09:22:04 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 330 331 332 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 ... 844 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5776405 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. (2 posts by 2 users deleted.)
rav3n_pl
Legendary
*
Offline Offline

Activity: 1360
Merit: 1000


Don`t panic! Organize!


View Profile WWW
October 16, 2012, 12:58:28 PM
 #7581

Maybe "cure" will be compile "GPU-only" and "FPGA-only" versions? And run 2 programs?

Thats what i try to accomplish not to have: I would love to have my miners in one single program.
Tried that for GPU+CPU but looks like CPU alone is 3x faster than combo Smiley

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
Some stuff on https://github.com/Rav3nPL/
Your Bitcoin transactions
The Ultimate Bitcoin mixer
made truly anonymous.
with an advanced technology.
Mix coins
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Nachtwind
Hero Member
*****
Offline Offline

Activity: 700
Merit: 505



View Profile
October 16, 2012, 01:07:57 PM
 #7582

Alas the ztex code is in complete bitrot. The only code maintainer for it (nelisky) has long since disappeared and made no attempt to come back and maintain or bugfix it. So you're screwed.

meh...
But ok, at least i know where i am standing. Thanks.
ralree
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


Manateeeeeeees


View Profile
October 16, 2012, 02:15:18 PM
 #7583

Yes but that would make my 2.722 Gh only appear as 2.7GH which is not accurate enough. Significant digits is the key.

HA!  OK, OK fine.  I guess that's somewhat reasonable.

1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
ralree
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


Manateeeeeeees


View Profile
October 16, 2012, 02:17:52 PM
 #7584

Yes but that would make my 2.722 Gh only appear as 2.7GH which is not accurate enough. Significant digits is the key.
I've created a (unnecessarily complex) workaround and committed it to git so it's always padded on the right by zeroes. I agree it looks better.

Thank you very much for this.  You are awesome.

1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
October 16, 2012, 02:31:53 PM
 #7585

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?

But if it is not, could there be some law behind it which could maybe used to make somehow better digging algorihtm? Currently just guessing, but maybe..

first; hash function is designed so that changing one bit in the input would change as many bits on the output as possible. However, all of the outputbits cannot (ans should not) be changed.

Could it be so that certain parts of the input makes it more possibly that the upper bits of the output is zero when nonce is changed? For example the block hash compined with certain timestamp (or part of it) could cause more hashes with zeroes on the up?

If so, the algorihtm could be changed so that if good hashes are not found, the miner should try to somehow change the input (in addition to nonce). If 'quite good' hashes has been found, it should keep the block as stable as possible, maybe not accept new transactions or try not to change the timestamp or change it as little as possible?

Just guessing, but maybe worth trying? Maybe this theory (or hypothesis or guessing..) could be checked by some statistic from simulated block headers? Certain bits in the simulated headers could be found to generate more hashes with zeroes up?

hmm. maybe this should be on the pool sw, not mining software.

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
rav3n_pl
Legendary
*
Offline Offline

Activity: 1360
Merit: 1000


Don`t panic! Organize!


View Profile WWW
October 16, 2012, 02:46:49 PM
 #7586

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?
(...)
Double SHA256 excludes this IMO, one bit on input makes output totally different, and for 2 totally different inputs it is almost impossible get similar outputs...
Some match formula like that would be "easy" SHA256 break/collision maker.
So far noone found collision in this algo Smiley

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
Some stuff on https://github.com/Rav3nPL/
slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1022



View Profile WWW
October 16, 2012, 02:57:35 PM
 #7587

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?

You answered it by youself. It is just your imagination.

eleuthria
Legendary
*
Offline Offline

Activity: 1750
Merit: 1002



View Profile
October 16, 2012, 04:09:28 PM
 #7588

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?

You answered it by youself. It is just your imagination.

It's actually just your brain's natural pattern recognition.  When looking at huge sets of data, you will subconsciously try to pick out groups that stick out from the rest.  Statistically speaking, large sets of random numbers will have lots of groups close together, and lots of large gaps.  If you average it all out, you'll have very consistent "randomness".  It's just that the human brain is efficient at trying to find patterns/meaning in things that can be grouped together.

RIP BTC Guild, April 2011 - June 2015
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
October 16, 2012, 04:23:40 PM
 #7589

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?

You answered it by youself. It is just your imagination.

Yes, that's the most likely explanation :-) But worth mentioning, anyway (I think?). Suppose this pops up every now and then?

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
kano
Legendary
*
Offline Offline

Activity: 2730
Merit: 1103


Linux since 1997 RedHat 4


View Profile
October 16, 2012, 05:07:22 PM
 #7590

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?
...
No the statistical expectation is on average one 1diff share per 2^32 hashes.

To see this, try mining on an Icarus device.
The Icarus device aborts after it finds a share - thus usually doesn't complete the full 2^32 hashes
Yet ... they still get expected performance.

However ... if you mine with a BFL Single then you will certainly see groups of shares.
Sometimes as many as 5 or 6 (and of course possible to find more)
The BFL design is such that it returns 'all' shares found in the nonce range after it completes the nonce range (and not before)
So it is 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 ...

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!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1012



View Profile
October 16, 2012, 05:31:12 PM
 #7591

Alas the ztex code is in complete bitrot. The only code maintainer for it (nelisky) has long since disappeared and made no attempt to come back and maintain or bugfix it. So you're screwed.
I am maintaining the Ztex driver in BFGMiner.

Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
October 16, 2012, 05:40:30 PM
Last edit: October 16, 2012, 05:56:55 PM by Nite69
 #7592

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
Vbs
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500


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

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
Merit: 250


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

Is it possible to change voltage for 7970 yet?

crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



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

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: 2730
Merit: 1103


Linux since 1997 RedHat 4


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

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 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!
SiegeBreaker
Newbie
*
Offline Offline

Activity: 26
Merit: 0


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

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: 2786
Merit: 1154


Ruu \o/


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

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

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: 2730
Merit: 1103


Linux since 1997 RedHat 4


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

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 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!
chewie
Member
**
Offline Offline

Activity: 75
Merit: 10


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

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.
Pages: « 1 ... 330 331 332 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 ... 844 »
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
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!