No issues with 2.8.3, been running several days w and w/o stratum.. Perfect version so far.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 466. (Read 5805546 times)
October 17, 2012, 03:20:51 PM
No issues with 2.8.3, been running several days w and w/o stratum.. Perfect version so far.
October 17, 2012, 12:38:14 PM
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! 
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.
October 17, 2012, 06:04:00 AM
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.
October 17, 2012, 02:07:07 AM
Repeat of my post there in case anyone with MMQ's doesn't visit the BTCFPGA thread:
https://bitcointalksearch.org/topic/m.1277870
https://bitcointalksearch.org/topic/m.1277870
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)
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
(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
)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
October 17, 2012, 12:53:34 AM
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... 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.
October 17, 2012, 12:29:44 AM
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.
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.
October 16, 2012, 09:16:41 PM
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?
+ 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!
Small changes (bits) has a large affect on the results.
October 16, 2012, 09:00:46 PM
Is it possible to change voltage for 7970 yet?
Yep. You just gotta use Windows and MSI AB. 
October 16, 2012, 08:42:06 PM
Is it possible to change voltage for 7970 yet?
October 16, 2012, 03:28:54 PM
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?
+ 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!
October 16, 2012, 01:40:30 PM
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 ...
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?
October 16, 2012, 01:31:12 PM
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. October 16, 2012, 01:07:22 PM
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 ...
October 16, 2012, 12:23:40 PM
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?
October 16, 2012, 12:09:28 PM
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.
October 16, 2012, 10:57:35 AM
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.
October 16, 2012, 10:46:49 AM
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
October 16, 2012, 10:31:53 AM
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.
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.
October 16, 2012, 10:17:52 AM
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.
October 16, 2012, 10:15:18 AM
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.
Jump to: