Bitcoin Forum
December 03, 2016, 03:57:28 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 [664] 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4815263 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.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 03, 2013, 09:17:58 PM

upgraded from 3.6.2 to 3.6.6 two days ago, and have twice run into a new issue.

(5) different machines running 3.6.6 at (3) different physical locations, different carriers.

each miner set up for (6) pool entries, (3) btcguild, (2) eligius, (1) deepbit, set to "failover" mode.

I've now had (2) of them completely stall, no new work.


At that point ALL work in/out of cgminer stops..I get idle miner notifications from btcguild, but it doesn't fail down to eligius or deepbit.

For now I'm going back to 3.6.2, but wanted you to know I'd seen something new. I'm sorry I don't have better logs.
No I have not had this reported. There are some issues with pools that use round robin DNS and stratum and possibly you have run into that. There is nothing really different in 3.6.6 versus 3.6.2 if I recall correctly that might have made this come up so if you may well have the same issue with 3.6.2. I've made some changes to the upcoming code that hopefully will help this but a new release is not due out just yet while I keep bashing my head against the AMU wall.
On further investigation, I've found how this can happen, and have committed a fix for this into git so it should go into the next version. The actual issue goes back quite a way so backtracking versions will not avoid it.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480780648
Hero Member
*
Offline Offline

Posts: 1480780648

View Profile Personal Message (Offline)

Ignore
1480780648
Reply with quote  #2

1480780648
Report to moderator
1480780648
Hero Member
*
Offline Offline

Posts: 1480780648

View Profile Personal Message (Offline)

Ignore
1480780648
Reply with quote  #2

1480780648
Report to moderator
Xian01
Legendary
*
Offline Offline

Activity: 1302


󮀓1刎


View Profile
November 03, 2013, 09:34:00 PM

Actually LOL builds on GTFO so it shouldn't be any worse (better in fact).

 (I appreciate your naming conventions more than you know. re: LOL, WTF, GTFO... Very funny)
aigeezer
Legendary
*
Offline Offline

Activity: 1278


Cryptanalyst castrated by his government, 1952


View Profile
November 03, 2013, 10:01:12 PM


Running "gtfo" now. Random LEDs are coming on for a longish while (10+ seconds?). Just had four on at once but no failures yet.

I know I'm tempting fate with this update, but I've been running "gtfo" (great name!) for 2 hours now and no zombies or other strange behaviour noted. I'll leave it and check again after a few more hours.

Me too, 6.3 hours and counting, "gtfo" is the best candidate yet, it seems. We may not get to find out what "lol" is about, lol.
Actually LOL builds on GTFO so it shouldn't be any worse (better in fact).

However this one undoes one change that I really didn't want to do. Can you please see if this makes things worse again?
http://ck.kolivas.org/apps/cgminer/temp/cgminer-ftw.exe

OK, I'm reluctantly stopping the gtfo test after 10 hours error-free to give ftw a try - such an optimistic name deserves a chance too.    Smiley

Edit: 15 minutes in to the ftw test AMU 5 has gone to zero hash rate and its LED is staying on. I'll try the lol test now.
jmc1517
Jr. Member
*
Offline Offline

Activity: 56


View Profile
November 03, 2013, 11:05:56 PM

OK, so I'm stopping "gtfo" after just over 7 hours running with just the one previously-reported zombie in my last "Edit."
Logfile (without --debug) here, if you need it:
 https://dl.dropboxusercontent.com/u/44240170/logfile-gtfo.txt

Starting cgminer-ftw and leaving to run overnight....

Ah. NOT!!!  Two AMU LEDS on solid, then one has gone out, but the other is reported as zombie.
Think I'll go back to "gtfo" for the night...

Logfile for "ftw" here:
 https://dl.dropboxusercontent.com/u/44240170/logfile-ftw.txt

Tomorrow then... :/

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 04, 2013, 12:12:09 AM

OK, so I'm stopping "gtfo" after just over 7 hours running with just the one previously-reported zombie in my last "Edit."
Logfile (without --debug) here, if you need it:
 https://dl.dropboxusercontent.com/u/44240170/logfile-gtfo.txt

Starting cgminer-ftw and leaving to run overnight....

Ah. NOT!!!  Two AMU LEDS on solid, then one has gone out, but the other is reported as zombie.
Think I'll go back to "gtfo" for the night...

Logfile for "ftw" here:
 https://dl.dropboxusercontent.com/u/44240170/logfile-ftw.txt

Tomorrow then... :/


Yep that confirms my suspicions then, thanks. Looks like LOL it is.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
jmc1517
Jr. Member
*
Offline Offline

Activity: 56


View Profile
November 04, 2013, 12:18:36 AM

OK, so I'm stopping "gtfo" after just over 7 hours running with just the one previously-reported zombie in my last "Edit."
Logfile (without --debug) here, if you need it:
 https://dl.dropboxusercontent.com/u/44240170/logfile-gtfo.txt

Starting cgminer-ftw and leaving to run overnight....

Ah. NOT!!!  Two AMU LEDS on solid, then one has gone out, but the other is reported as zombie.
Think I'll go back to "gtfo" for the night...

Logfile for "ftw" here:
 https://dl.dropboxusercontent.com/u/44240170/logfile-ftw.txt

Tomorrow then... :/


Yep that confirms my suspicions then, thanks. Looks like LOL it is.
Got another zombie with the new run of "gtfo" when I checked at 00:17 (insomnia....).  logfile:
 https://dl.dropboxusercontent.com/u/44240170/logfile-gtfo2.txt

Back to 3.5.1 for the night and I'll try "lol" tomorrow when I can keep an eye on it :/


-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 04, 2013, 01:33:14 AM

OK, so I'm stopping "gtfo" after just over 7 hours running with just the one previously-reported zombie in my last "Edit."
Logfile (without --debug) here, if you need it:
 https://dl.dropboxusercontent.com/u/44240170/logfile-gtfo.txt

Starting cgminer-ftw and leaving to run overnight....

Ah. NOT!!!  Two AMU LEDS on solid, then one has gone out, but the other is reported as zombie.
Think I'll go back to "gtfo" for the night...

Logfile for "ftw" here:
 https://dl.dropboxusercontent.com/u/44240170/logfile-ftw.txt

Tomorrow then... :/


Yep that confirms my suspicions then, thanks. Looks like LOL it is.
Got another zombie with the new run of "gtfo" when I checked at 00:17 (insomnia....).  logfile:
 https://dl.dropboxusercontent.com/u/44240170/logfile-gtfo2.txt

Back to 3.5.1 for the night and I'll try "lol" tomorrow when I can keep an eye on it :/



Next step after LOL has to be:

http://ck.kolivas.org/apps/cgminer/temp/cgminer-rofl.exe

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
aigeezer
Legendary
*
Offline Offline

Activity: 1278


Cryptanalyst castrated by his government, 1952


View Profile
November 04, 2013, 02:37:27 AM

Four hours into the lol test and looking good - no issues. I'll keep it going unattended for another 11 hours or so now if possible.

Edit: the lol test ran 14 hours, mainly unattended. Somewhere along the way AMU6 went zombie but it was the only problem flagged. I see 3.7.0 is out so I'll go straight to it next. I'm very impressed at the amount of work you put into keeping cgminer current, ckolivas - that changelog is amazing for a "spare time" project. Thank you!

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 04, 2013, 05:56:06 AM

Skip that and go straight to

http://ck.kolivas.org/apps/cgminer/temp/cgminer-lmfao.exe

I'm getting itchy here with too much accumulated for a new release, so consider lmfao as the release candidate.

EDIT: Never mind,  v3.7.0 is out which is basically the same as lmfao. Just try that one.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
November 04, 2013, 07:52:02 AM

I started operating a larger number of bitburner Furys over the weekend (48 boards x 16 chips) and am constantly running into some hang condition with latest cgminer (git master). After some hours of operation mining stops and cgminer obviously is blocked in an infinite loop.

The related output is:
Code:
[2013-11-03 02:39:15] Accepted 3f0e2f2a Diff 1.04K/1024 BBF 2 pool 0
 [2013-11-03 02:39:16] Network diff set to 391M
 [2013-11-03 02:39:16] New block detected on network before longpoll
 [2013-11-03 02:39:16] Stratum from pool 0 requested work restart
 [2013-11-03 02:39:17] BBF3: Idled 1 miners
 [2013-11-03 02:39:17] BBF1: Idled 1 miners
 [2013-11-03 02:39:18] BBF2: Idled 1 miners
 [2013-11-03 02:39:18] BBF4: Idled 1 miners
 [2013-11-03 02:39:18] BBF0: Idled 1 miners
 [2013-11-03 02:39:19] BBF5: Idled 1 miners
 [2013-11-03 02:39:26] Waiting for work to be available from pools.

And there it remains until I quit and restart cgminer, where mining starts immediately again.

From the source code I see the hang occurs in the first while-loop in hash_pop(), but I don't quite understand why this happens. Any suggestions how to track down the problem? Thanks.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 04, 2013, 08:00:25 AM

I started operating a larger number of bitburner Furys over the weekend (48 boards x 16 chips) and am constantly running into some hang condition with latest cgminer (git master). After some hours of operation mining stops and cgminer obviously is blocked in an infinite loop.

The related output is:
Code:
[2013-11-03 02:39:26] Waiting for work to be available from pools.

And there it remains until I quit and restart cgminer, where mining starts immediately again.

From the source code I see the hang occurs in the first while-loop in hash_pop(), but I don't quite understand why this happens. Any suggestions how to track down the problem? Thanks.
What does "git describe" show? There was a bugfix recently for this very issue.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
November 04, 2013, 08:32:27 AM

What does "git describe" show? There was a bugfix recently for this very issue.

Just checking over past 2 hours with fresh build of
Code:
v1.0-5442-g7645686

Will report back if problem still occurs. Thanks for feedback.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 04, 2013, 09:03:07 AM

New version: 3.7.0, 4th November, 2013

New drivers, lots of code updates, new features, lots of bugfixes, major upgrade. The new drivers are NOT built into the binaries since KnC hardware only runs on beaglebone boards and Hashfast hardware isn't in the wild yet. Binaries now include klondike support on windows as well.


Human readable changelog:

- Driver for KnC miner ASIC hardware.
- Driver for Hashfast ASIC hardware.
- Fix for blue fury to work as well as red fury.
- Busloads of little tweaks to make AMU much more reliable on windows - they may go zombie if you have unreliable communications but should hotplug themselves again soon after. Thanks greatly to the generous testing time dedicated so far by aigeezer and jmc1517. No doubt they will still be more reliable on linux, but hopefully we should be close to getting them reliably hashing in a sustained fashion on windows.
- Major rewrites of all the "diff" code in preparation for endless changes in diff and hashrates. It should now seamlessly support any diff levels (even microdiffs for development) for network, pool and share diff, while being lower overhead than before. Diff will now be rounded to nearest integer instead of down as well (63.99 will be 64, not 63).
- Fix for scrypt showing a block solve with every share.
- Faster flushing of work across all devices on block change should lead to lower rejects than ever on devices that can abort work quickly.
- Numerous usb communication improvements should lead to less software induced artificial hardware errors.
- Lower CPU usage from multiple areas.
- Current block now only shows the first 8 characters after the paired zeroes end.
- Accepted share will trim off all paired zeroes.
- Display the amount of work items worked on per pool now in the API and summary on exit for when load balance with quotas is in use to allow comparison.
- Account for discarded work when calculating quotas to try and keep them as close to set values as possible.
- Know which pools are on the new block during a block change and decide accordingly whether to update work depending on the pool failover strategy.
- Changed the verbose message to share is above target instead of below since it was incorrect.
- Fix for the corrupted console output after shutting down cgminer if we've done one or more restarts.
- Fix for the rare scenario where it would stall completely and no work would be grabbed or done.
- Klondike driver updates.
- Numerous low level features for upcoming drivers.
- Lots of low level code updates and bugfixes.


Full changelog:

- Use WRITEIOERR macro check for all usb writes.
- Always use a usb read buffer instead of having to explicitly enable it.
- Force unlocking of the console lock on restart to avoid corrupting the console
state when we finally quit.
- Never wait indefinitely for a pthread conditional in the hash_pop loop in case
the work scheduler misses the last wakeup.
- Make hash_pop signal the work scheduler each time it waits on the conditional
that it should look for more work.
- Discriminate between libusb transfer errors and regular libusb errors and make
sure to capture them all.
- Always read a full sized transfer for bulk reads.
- Deprecate preferred packet size functions in usbutils since they're unhelpful.
- Copy known transferred amount back to buffer for usb reads instead of
requested length.
- Treat timeout errors on usb writes as IO errors.
- Ignore iManufacturer from bitfury devices to support bluefury as well as
redfury.
- Add more debugging info for when usb details don't match.
- Look for timeout overruns in usb read/write.
- Use an int for usb_read/write to identify overruns.
- Use the callback timeout as a safety mechanism only on windows.
- Instead of using complicated sleeps to emulate characters per second on usb
writes, submit only as many characters as can be transferred per usb poll of
1ms, and use timeouts in bulk transfers, cancelling transfers only as a
failsafe.
- Remove discarded work from quota used.
- Display works completed in summary and API data.
- Store how many work items are worked on per pool.
- Make each pool store its on reference for what the most current block is and
fine tune management of block change in shared pool failover strategies using
the information.
- Rationalise use of current_hash to a single hex string the length of the
previous block and display only the first non zero hex chars of the block in the
status window.
- Update uthash to latest.
- show_hash doesn't know the size of the string so hard code the max size.
- Remove as many initial zeroes as exist on share display, abstracting out a
hash show function to use across different submission mechanisms.
- Add missing endian swap functions for 64bits.
- Sanity check for absurd target setting and divide by zero.
- Abstract out conversion of a 256 bit endian number to a double, correcting
errors and use it for determining any magnitude share diff.
- Avoid the extra generation of a byte flipped hash2 in struct work and directly
use the LE work hash.
- Add a sanity check to avoid divide by zero crashes in set_target
- Calculate diff from target accurately for all 256 bits.
- Set a true 256bit binary target based on any diff value in set_target()
- Provide a copy_work_noffset function for copying a work struct but changing
its ntime.
- Make calls to flush queue and flush work asynchronous wrt to the main work
loops.
- Share is also above target for submit noffset nonce.
- Use round for displaying current pool diff.
- Use round for stratum share diff display instead of floor.
- Use round instead of floor for displayed pool difficulty.
- Allow arbitrary diffs to be tested against nonces via a test_nonce_diff
function.
- Abstract out the rebuilding of hash2 in work.
- Share is above, not below target, when it doesn't meet it.
- Add the ability to add uint8 and uint16 entities to api data.
- Use a non blocking connect with a 1 second select timeout when initiating
stratum to allow us to iterate over all IPs returned by getaddrinfo in round
robin DNS pools.
- Minor style changes to output.
- Revert two different hash_sequence(_head)'s to one variable, use
HF_SEQUENCE_DISTANCE in both places
- Remove duplicate HF_SEQUENCE_DISTANCE() macro, and duplicate hash_sequence
from info structure
- Change SEQUENCE_DISTANCE() macro to HF_SEQUENCE_DISTANCE()
- Structure changes for OP_NONCE, add big endian header
- klondike - initialise stat_lock
- klondike - better to unlock locks than to lock them twice Smiley
- Add copyright notice to knc driver.
- Trivial style changes to knc driver.
- Improve performance of work generation by optimizing hex2bin and bin2hex
- klondike - change options to clock and temptarget only
- klondike - fix another uninit dev warning
- klondike - downgrade 'late update' but add an idle detect - and correct error
levels
- klondike - fix isc uninit warning
- Use a mutex to protect data in the knc structure, to prevent loading more work
during a flush, and unlock and return to main between calls to get_queued_work.
- Use the existing device_data for knc state data.
- Only count successful nonces as hashrate in the knc driver.
- Fix trivial warnings in knc driver.
- Add KNC to api
- klondike - drop the device for hotplug if it's unresponsive
- usbutils - usb_nodev() allow a driver to drop a device
- klondike - single 'shutdown' and ensure it happens
- klondike remove SCNu8 - unsupported on windows
- Correctly calculate sleep_estimate in usbutils that may have been preventing
usecps from working.
- Use a sanity check on timeout on windows.
- Better HW error count; disable permanently those cores which fail often
- KnC driver: knc-spi-fpga ASIC driver
- Fixup jansson & libusb include paths when using separate build directory
- 'llround' is more suitable here than 'roundl'
- Silence warning if MAX/MIN is already defined
- Remove prebuild ccan/opt dependencies
- Reinstate block solve testing.
- Dramatically simplify the calculation of blockdiff.
- Simplify the set_target function, allowing it to work properly for fractional
diffs.
- Merge hashfast driver
- Merge KnC driver

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
OgNasty
Donator
Legendary
*
Offline Offline

Activity: 2016


Powered by NastyFans


View Profile WWW
November 04, 2013, 09:12:59 AM

Blue Fury USB miners now hashing away!  Grin

BITSLER                 ▄███
               ▄████▀
             ▄████▀
           ▄████▀  ▄██▄
         ▄████▀    ▀████▄
       ▄████▀        ▀████▄
     ▄████▀            ▀████▄
   ▄████▀                ▀████▄
 ▄████▀ ▄████▄      ▄████▄ ▀████▄
█████   ██████      ██████   █████
 ▀████▄ ▀████▀      ▀████▀ ▄████▀
   ▀████▄                ▄████▀
     ▀████▄            ▄████▀
       ▀████▄        ▄████▀
         ▀████▄    ▄████▀
           ▀████▄▄████▀
             ▀██████▀
               ▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄            
▄▄▄▄▀▀▀▀    ▄▄█▄▄ ▀▀▄         
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄      
█  ▀▄▄  ▀█▀▀ ▄      ▀████   ▀▀▄   
█ █▄  ▀▄   ▀████       ▀▀ ▄██▄ ▀▀▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█  ▀▀       ▀▄▄ ▀████      ▄▄▄▀▀▀  █
█            ▄ ▀▄    ▄▄▄▀▀▀   ▄▄  █
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█ ▄▄   ███   ▀██  █           ▀▀  █ 
█ ███  ▀██       █        ▄▄      █ 
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  
▀▄            █        ▀▀      █  
▀▀▄   ███▄  █   ▄▄          █   
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀    
▀▀▄   █   ▀▀▄▄▄▀▀▀         
▄▄▄▄▄▄▄▄▄▄▄█▄▄▀▀▀▀              
              ▄▄▄██████▄▄▄
          ▄▄████████████████▄▄
        ▄██████▀▀▀▀▀▀▀▀▀▀██████▄
▄     ▄█████▀             ▀█████▄
██▄▄ █████▀                ▀█████
 ████████            ▄██      █████
  ████████▄         ███▀       ████▄
  █████████▀▀     ▄███▀        █████
   █▀▀▀          █████         █████
     ▄▄▄         ████          █████
   █████          ▀▀           ████▀
    █████                     █████
     █████▄                 ▄█████
      ▀█████▄             ▄█████▀
        ▀██████▄▄▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████████▀▀
              ▀▀▀██████▀▀▀
            ▄▄▄███████▄▄▄
         ▄█▀▀▀ ▄▄▄▄▄▄▄ ▀▀▀█▄
       █▀▀ ▄█████████████▄ ▀▀█
     █▀▀ ███████████████████ ▀▀█
    █▀ ███████████████████████ ▀█
   █▀ ███████████████▀▀ ███████ ▀█
 ▄█▀ ██████████████▀      ▀█████ ▀█▄
███ ███████████▀▀            ▀▀██ ███
███ ███████▀▀                     ███
███ ▀▀▀▀                          ███
▀██▄                             ▄██▀
  ▀█▄                            ▀▀
    █▄       █▄▄▄▄▄▄▄▄▄█
     █▄      ▀█████████▀
      ▀█▄      ▀▀▀▀▀▀▀
        ▀▀█▄▄  ▄▄▄
            ▀▀█████
[]
DutchyGn
Jr. Member
*
Offline Offline

Activity: 42


View Profile
November 04, 2013, 09:28:35 AM

Any chance Technobit's HEX16A miner will be supported in the next versions?
derjanb
Newbie
*
Offline Offline

Activity: 24


View Profile
November 04, 2013, 09:33:52 AM

It seems that the share diff calculation is somehow broken? Usually the diff is the higher the more zero bits are at the beginning of the share, right?

Quote
[2013-11-04 08:07:35] Accepted 36fbfe43 Diff 1.19K/2 AMU 2 pool 0
 [2013-11-04 08:42:49] Accepted 31ca6a09 Diff 1.32K/7 AMU 1 pool 1
 [2013-11-04 09:03:48] Accepted 050ce41f Diff 13K/2 AMU 1 pool 0
 [2013-11-04 09:05:12] Accepted 17ad04b5 Diff 2.77K/2 AMU 1 pool 0
 [2013-11-04 09:11:50] Accepted 7aef6014 Diff 533/2 AMU 0 pool 0

I'm using the git version 8b38d7fec8 (still 3.6.6) but there are only README and configure changes to 3.7.0.

Do you want to get rid of all your bitcoins? This is the official trash address: 13vbLvM1Gb3fY5z15Mq1v1eCEjAxL8cPPs Smiley
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 04, 2013, 09:35:45 AM

It seems that the share diff calculation is somehow broken? Usually the diff is the higher the more zero bits are at the beginning of the share, right?

Quote
[2013-11-04 08:07:35] Accepted 36fbfe43 Diff 1.19K/2 AMU 2 pool 0
 [2013-11-04 08:42:49] Accepted 31ca6a09 Diff 1.32K/7 AMU 1 pool 1
 [2013-11-04 09:03:48] Accepted 050ce41f Diff 13K/2 AMU 1 pool 0
 [2013-11-04 09:05:12] Accepted 17ad04b5 Diff 2.77K/2 AMU 1 pool 0
 [2013-11-04 09:11:50] Accepted 7aef6014 Diff 533/2 AMU 0 pool 0

I'm using the git version 8b38d7fec8 (still 3.6.6) but there are only README and configure changes to 3.7.0.
- Accepted share will trim off all paired zeroes.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
derjanb
Newbie
*
Offline Offline

Activity: 24


View Profile
November 04, 2013, 09:41:52 AM

- Accepted share will trim off all paired zeroes.

Phew! It seems I've over-read that. Smiley Thanks for all your hard work and your quick reply.

Do you want to get rid of all your bitcoins? This is the official trash address: 13vbLvM1Gb3fY5z15Mq1v1eCEjAxL8cPPs Smiley
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
November 04, 2013, 09:54:43 AM

ckolivas

it is normal for 3.6.6-1?
in other versions there is no such
This is not a solo. So on any script coins. Not only at me.
3.6.4 works fine
 

Yeah I probably screwed that up for $scryptcoins when I fixed it for bitcoin.

I thought I'd confirm this, as more and more scrypt miners are getting confused.
Commits 3f6b9d67 and 36c6da8 introduce an inconsistency between share difficulty and network difficulty when cgminer is in scrypt mode. This causes many shares to be considered as blocks, even when they are not.
This doesn't seem to cause any real issue, but if you're getting annoyed by all those fake "Found block" messages, just use the stable version (tag v3.6.6).
If you could try latest git, I'd like to confirm that I've fixed the issue before releasing a new version.
Did you commit the fix? I cannot find it in the commit history.
I have tried the latest master (tag v3.7.0) from the git repo, and the bug is still there.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 04, 2013, 09:56:38 AM

Did you commit the fix? I cannot find it in the commit history.
I have tried the latest master (tag v3.7.0) from the git repo, and the bug is still there.
Well, no one confirmed whether I had fixed it or not, so I had to run blind. Therefore the bug is still there.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 [664] 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 ... 830 »
  Print  
 
Jump to:  

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!