Bitcoin Forum
February 21, 2019, 03:07:27 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 431 ... 844 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5776779 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.)
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
October 17, 2012, 04:38:14 PM
 #7601

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

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.

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1550761648
Hero Member
*
Offline Offline

Posts: 1550761648

View Profile Personal Message (Offline)

Ignore
1550761648
Reply with quote  #2

1550761648
Report to moderator
1550761648
Hero Member
*
Offline Offline

Posts: 1550761648

View Profile Personal Message (Offline)

Ignore
1550761648
Reply with quote  #2

1550761648
Report to moderator
dlasher
Sr. Member
****
Offline Offline

Activity: 466
Merit: 250



View Profile WWW
October 17, 2012, 07:20:51 PM
 #7602


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

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 17, 2012, 08:17:42 PM
 #7603


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


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.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 17, 2012, 08:44:21 PM
 #7604

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

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

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 17, 2012, 10:50:20 PM
 #7605

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.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
kaerf
Hero Member
*****
Offline Offline

Activity: 630
Merit: 500


View Profile
October 18, 2012, 01:20:50 AM
 #7606

check it out. cgminer on android   Grin

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


kano
Legendary
*
Offline Offline

Activity: 2730
Merit: 1105


Linux since 1997 RedHat 4


View Profile
October 18, 2012, 01:59:19 AM
 #7607

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


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!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 18, 2012, 02:01:00 AM
 #7608

check it out. cgminer on android   Grin

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



Very cool indeed  Grin

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

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
Mobius
Hero Member
*****
Offline Offline

Activity: 985
Merit: 1000



View Profile
October 18, 2012, 02:14:55 AM
 #7609

check it out. cgminer on android   Grin

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




Coolness
TheHarbinger
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


Why is it so damn hot in here?


View Profile
October 18, 2012, 02:50:10 AM
 #7610

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

12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
BitMinerN8
Hero Member
*****
Offline Offline

Activity: 626
Merit: 500


Mining since May 2011.


View Profile
October 18, 2012, 04:13:34 AM
 #7611

check it out. cgminer on android   Grin

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.  Grin
Are you mining over 3G/4G or WiFi?
dietwice
Newbie
*
Offline Offline

Activity: 58
Merit: 0


View Profile
October 18, 2012, 04:21:08 AM
 #7612

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

Activity: 591
Merit: 500



View Profile WWW
October 18, 2012, 04:42:15 AM
 #7613

Very cool, now if you can get it to support a USB hub and 5 or 6 ASICs when they start shipping.  Grin
Are you mining over 3G/4G or WiFi?
The phone is on wifi in the video. Wink

BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
wind
Member
**
Offline Offline

Activity: 125
Merit: 10


View Profile
October 18, 2012, 11:31:40 AM
 #7614

again 2.8.4 doesn't compile on Windows with opencl enabled Smiley
Commenting this code in configure.ac solves the problem  Smiley
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
Sr. Member
****
Offline Offline

Activity: 285
Merit: 250



View Profile
October 18, 2012, 02:07:50 PM
 #7615

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

Activity: 628
Merit: 500



View Profile
October 18, 2012, 02:28:24 PM
 #7616

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  Grin and almost 440Mhs from 6970.

There is no place like 127.0.0.1
In blockchain we trust
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
October 18, 2012, 04:21:01 PM
 #7617

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

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.

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
amigaman
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250



View Profile
October 18, 2012, 06:37:45 PM
 #7618

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
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


View Profile
October 18, 2012, 06:39:56 PM
 #7619

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

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
Vbs
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500


View Profile
October 18, 2012, 07:22:23 PM
 #7620

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

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. Smiley
Pages: « 1 ... 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 431 ... 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!