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

Very cool indeed 

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

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

check it out. cgminer on android   

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

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

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

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.

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

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.

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.

Repeat of my post there in case anyone with MMQ's doesn't visit the BTCFPGA thread:
https://bitcointalksearch.org/topic/m.1277870

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

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.

This is effectively part of the requirement of a secure hash algorithm.
Small changes (bits) has a large affect on the results.

Yep. You just gotta use Windows and MSI AB.  

Is it possible to change voltage for 7970 yet?

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!

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?

I am maintaining the Ztex driver in BFGMiner.

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

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