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

Interesting failure state today.

I have some (2.8.3) miners behind stratum 1.1.1 proxy.. primary pool stratum was pointed at failed. (stratum crashed). cgminer stayed connected to proxy, which stayed up. proxy couldn't get work from primary pool, stayed idle, all miners went idle, cgminer never failed down to next pools in the chain.

It would be nice to be able to set some sort of threshold.. (And shoot me conman if you already do this and I just missed it)..in cgminer.  If I don't get any work from a pool in {threshold} minutes, in spite of being TCP/UDP/etc up, I should mark it dead.  (I swear cgminer already does this for getwork.. I see messages about "pool not providing work fast enough")

(FWIW, I'm going to post something over in Slush's proxy thread, because I think his proxy should have marked itself dead, but somehow cgminer should know a pool is "starving", shouldn't it?)

you must have free electricity or something...  1170!  The other guy was right, lower your clock for stability.  if you run at 950 you can lower the volt to 0.949 and cut your electricity usage in half and only go down about 70Mh

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.

isn't aggressiveness tied to intensity?  lower the intensity

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.

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.

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.

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.

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

The phone is on wifi in the video.

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

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?

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.   

Coolness

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.