OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[Nite69]

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.

[dlasher]

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

[-ck]

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

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.

[-ck]

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.

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

[-ck]

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.

[kaerf]

check it out. cgminer on android   

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

[kano]

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

[-ck]

check it out. cgminer on android   

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

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.

[Mobius]

check it out. cgminer on android  

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

Coolness

[TheHarbinger]

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.   

[BitMinerN8]

check it out. cgminer on android   

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

Very cool, now if you can get it to support a USB hub and 5 or 6 ASICs when they start shipping. 
Are you mining over 3G/4G or WiFi?

[dietwice]

2.8.4 on Win7 x64 still crashes on network failures.

Being on Wi-Fi it survived switching to another network just by switching to backup pool and then reconnecting to the main one (Slush).
But on switching network back it crashed.

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   cgminer.exe
  Application Version:   0.0.0.0
  Application Timestamp:   507f309d
  Fault Module Name:   StackHash_0a9e
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   00000000
  Exception Code:   c0000005
  Exception Offset:   6f43203a
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:   1058
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

[Krak]

Very cool, now if you can get it to support a USB hub and 5 or 6 ASICs when they start shipping.  
Are you mining over 3G/4G or WiFi?

The phone is on wifi in the video.

[wind]

again 2.8.4 doesn't compile on Windows with opencl enabled
Commenting this code in configure.ac solves the problem 

Code:

if test "x$AMDAPPSDKROOT" != x; then
	OPENCL_FLAGS="-I$AMDAPPSDKROOT/include $OPENCL_FLAGS"
	OPENCL_LIBS="-L$AMDAPPSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
fi

[Karasur]

it seems that 2.8.4 uses gpu more aggressive...
Some of my radeon 7970 (1170/1050/65C) work well with 2.7.7 but with 2.8.4 are sick after 2-3 min btc mining.

[BlackPrapor]

it seems that 2.8.4 uses gpu more aggressive...
Some of my radeon 7970 (1170/1050/65C) work well with 2.7.7 but with 2.8.4 are sick after 2-3 min btc mining.

dunno about getting sick, but my 6950 now able to run with I=12, whereas in 2.7.x and all previous versions anything above 9 was causing cgminer to use 100% of CPU. So, now I'm able to squeeze 400Mhs from 6950 with AMD APP 2.4 and catalyst 12.8 drivers, running at 965Mhz  and almost 440Mhs from 6970.

[Nite69]

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.

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

That's what I practically told. But if one input bit allways changes *all* the output bits, then the function is not a hash, but it is binary "NOT". And that means they (inputs with 1bit difference) would practically have almost all in common with the results. So optimally (as your link also noted), about half of the output bits are changed when one input bit changes.
But this conversation is quite stupid. We all agree, but are still arguing. And quite much off-topic.

[amigaman]

it seems that 2.8.4 uses gpu more aggressive...
Some of my radeon 7970 (1170/1050/65C) work well with 2.7.7 but with 2.8.4 are sick after 2-3 min btc mining.

I have the same probs, ckolivas told me it's from stratum use.
You will have to use non-stratum pools (or disable stratum with the option, see help) or reduce engine clock.

[jjiimm_64]

it seems that 2.8.4 uses gpu more aggressive...
Some of my radeon 7970 (1170/1050/65C) work well with 2.7.7 but with 2.8.4 are sick after 2-3 min btc mining.

I have the same probs, ckolivas told me it's from stratum use.
You will have to use non-stratum pools (or disable stratum with the option, see help) or reduce engine clock.

isn't aggressiveness tied to intensity?  lower the intensity

[Vbs]

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.

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

That's what I practically told. But if one input bit allways changes *all* the output bits, then the function is not a hash, but it is binary "NOT". And that means they (inputs with 1bit difference) would practically have almost all in common with the results. So optimally (as your link also noted), about half of the output bits are changed when one input bit changes.
But this conversation is quite stupid. We all agree, but are still arguing. And quite much off-topic.

Of course, if you use a binary system for representing something, at the bit-level there can only be 0's or 1's. So, even if the bits don't seem to change much at a low level between the hashes of 2 different data, the hashes themselves are quite different because they can only be interpreted at the word level, and they are built to minimize the correlation with original data.

Think of a hash like a "random" function. Although not all bits change between runs of random trials, at a higher level the numbers are still random, and follow no predictable pattern.