Bitcoin Forum
April 27, 2024, 07:04:16 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 609 610 611 612 613 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 ... 843 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5805212 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. (3 posts by 1+ user deleted.)
jmc1517
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
November 03, 2013, 05:31:32 PM
Last edit: November 03, 2013, 08:42:04 PM by jmc1517
 #13161


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.

Edit: First zombie after about 5 hours, although it occurred at exactly the same time as I decided to sit down at the
       PC and upload some photos to Flickr. I suppose it could be coincidence, but I wonder if it might have caused
       a slight delay on the broadband which could have caused a momentary disturbance?  I re-plugged the zombie
       AMU 24 and it came back as AMU 34.  I'm continuing to upload photos and all is apparently ok again.  Strange.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714201456
Hero Member
*
Offline Offline

Posts: 1714201456

View Profile Personal Message (Offline)

Ignore
1714201456
Reply with quote  #2

1714201456
Report to moderator
1714201456
Hero Member
*
Offline Offline

Posts: 1714201456

View Profile Personal Message (Offline)

Ignore
1714201456
Reply with quote  #2

1714201456
Report to moderator
1714201456
Hero Member
*
Offline Offline

Posts: 1714201456

View Profile Personal Message (Offline)

Ignore
1714201456
Reply with quote  #2

1714201456
Report to moderator
aigeezer
Legendary
*
Offline Offline

Activity: 1450
Merit: 1013


Cryptanalyst castrated by his government, 1952


View Profile
November 03, 2013, 06:31:08 PM
 #13162


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

Activity: 1540
Merit: 1001



View Profile
November 03, 2013, 08:01:28 PM
 #13163

Looks like my little erupters are supercharged!  Woohoo!!  I'm rocking!

Code:
 cgminer version 3.6.6 - Started: [2013-11-03 10:44:15]
--------------------------------------------------------------------------------
 (5s):11.14G (avg):22.93Ph/s | A:41306  R:681  HW:458  WU:166.6/m
 ST: 2  SS: 0  NB: 37  LW: 84634  GF: 1  RF: 0
 Connected to ggggg diff 81 with stratum as user xxxxxxxxxxx
 Block: 000217b3743e8a5b...  Diff:391M  Started: [14:54:36]  Best share: 1.24M
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 AMU  0:                 | 335.7M/1.206Ph/s | A:1161 R:  0 HW:16 WU:  4.8/m
 AMU  1:                 | 335.5M/336.4Mh/s | A: 929 R:  0 HW:14 WU:  4.3/m
 AMU  2:                 | 335.4M/335.8Mh/s | A:1613 R: 91 HW:11 WU:  4.7/m
 AMU  3:                 | 335.3M/1.206Ph/s | A: 972 R:  0 HW:12 WU:  4.7/m
 AMU  4:                 | 335.6M/1.206Ph/s | A:1434 R:  0 HW:10 WU:  4.6/m
 AMU  5:                 | 335.6M/1.206Ph/s | A: 701 R:  0 HW:16 WU:  4.5/m
 AMU  6:                 | 335.5M/1.206Ph/s | A:1183 R:  0 HW:13 WU:  4.5/m
 AMU  7:                 | 335.5M/336.1Mh/s | A:1757 R:  0 HW:21 WU:  4.8/m
 AMU  8:                 | 335.3M/336.1Mh/s | A:1150 R: 89 HW: 9 WU:  4.7/m
 AMU  9:                 | 335.6M/335.8Mh/s | A: 967 R:  0 HW:10 WU:  4.8/m
 AMU 10:                 | 335.3M/1.206Ph/s | A:1316 R:111 HW: 7 WU:  4.7/m
 AMU 11:                 | 335.3M/1.206Ph/s | A:1185 R:  0 HW:12 WU:  4.8/m
 AMU 12:                 | 335.6M/1.206Ph/s | A:1002 R:  0 HW:12 WU:  4.6/m
 AMU 13:                 | 335.5M/336.1Mh/s | A:1396 R:  0 HW:15 WU:  4.5/m
 AMU 14:                 | 335.4M/335.9Mh/s | A:1942 R:  0 HW:12 WU:  4.9/m
 AMU 15:                 | 335.7M/335.9Mh/s | A:1090 R:  0 HW:14 WU:  4.7/m
 AMU 16:                 | 335.6M/336.2Mh/s | A:1128 R:  0 HW:22 WU:  4.7/m
 AMU 17:                 | 337.5M/1.206Ph/s | A: 627 R:  0 HW: 8 WU:  4.6/m
 AMU 18:                 | 335.2M/336.0Mh/s | A: 838 R:  0 HW: 9 WU:  4.8/m
 AMU 19:                 | 335.7M/1.206Ph/s | A:1529 R:  0 HW:14 WU:  4.6/m
 AMU 20:                 | 335.5M/336.1Mh/s | A:1160 R:  0 HW: 8 WU:  4.7/m
 AMU 21:                 | 335.6M/1.206Ph/s | A: 979 R:  0 HW: 6 WU:  4.6/m
 AMU 22:                 | 335.5M/1.206Ph/s | A: 987 R:  0 HW:10 WU:  4.6/m
 AMU 23:                 | 335.4M/1.206Ph/s | A: 862 R:  0 HW: 7 WU:  4.7/m
 AMU 24:                 | 335.2M/336.0Mh/s | A:1533 R: 69 HW:22 WU:  4.6/m
 AMU 25:                 | 335.1M/1.206Ph/s | A:1575 R:  0 HW:23 WU:  4.6/m
 AMU 26:                 | 335.4M/336.4Mh/s | A: 938 R:  0 HW:15 WU:  4.6/m
 AMU 27:                 | 335.4M/1.206Ph/s | A: 983 R:237 HW: 8 WU:  4.7/m
 AMU 28:                 | 335.7M/336.2Mh/s | A: 970 R:  0 HW:14 WU:  4.7/m
 AMU 29:                 | 335.5M/336.8Mh/s | A:1144 R: 84 HW:10 WU:  4.4/m
 AMU 30:                 | 335.5M/1.206Ph/s | A:1245 R:  0 HW:14 WU:  4.4/m
 AMU 31:                 | 335.3M/1.206Ph/s | A: 759 R:  0 HW:17 WU:  4.3/m
 AMU 32:                 | 335.7M/336.2Mh/s | A:1530 R:  0 HW:14 WU:  4.5/m
 AMU 33:                 | 335.0M/1.206Ph/s | A: 708 R:  0 HW:11 WU:  4.5/m
 AMU 34:                 | 335.4M/336.4Mh/s | A:1000 R:  0 HW:14 WU:  4.4/m
 AMU 35:                 | 335.7M/1.206Ph/s | A:1013 R:  0 HW: 8 WU:  4.8/m
--------------------------------------------------------------------------------

I'll be happy to sell my 1.2Ph/s erupters for 10 BTC each.  Any buyers?

ps. Past results are not guarantees of future returns.

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
-ck (OP)
Legendary
*
Offline Offline

Activity: 4088
Merit: 1631


Ruu \o/


View Profile WWW
November 03, 2013, 08:33:32 PM
 #13164

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
-ck (OP)
Legendary
*
Offline Offline

Activity: 4088
Merit: 1631


Ruu \o/


View Profile WWW
November 03, 2013, 09:13:39 PM
 #13165


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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
-ck (OP)
Legendary
*
Offline Offline

Activity: 4088
Merit: 1631


Ruu \o/


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

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Xian01
Legendary
*
Offline Offline

Activity: 1652
Merit: 1067


Christian Antkow


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

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: 1450
Merit: 1013


Cryptanalyst castrated by his government, 1952


View Profile
November 03, 2013, 10:01:12 PM
Last edit: November 03, 2013, 10:20:36 PM by aigeezer
 #13168


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

Activity: 56
Merit: 0


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

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 (OP)
Legendary
*
Offline Offline

Activity: 4088
Merit: 1631


Ruu \o/


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

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
jmc1517
Newbie
*
Offline Offline

Activity: 56
Merit: 0


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

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 (OP)
Legendary
*
Offline Offline

Activity: 4088
Merit: 1631


Ruu \o/


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

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
aigeezer
Legendary
*
Offline Offline

Activity: 1450
Merit: 1013


Cryptanalyst castrated by his government, 1952


View Profile
November 04, 2013, 02:37:27 AM
Last edit: November 04, 2013, 12:44:49 PM by aigeezer
 #13173

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 (OP)
Legendary
*
Offline Offline

Activity: 4088
Merit: 1631


Ruu \o/


View Profile WWW
November 04, 2013, 05:56:06 AM
Last edit: November 04, 2013, 09:03:49 AM by ckolivas
 #13174

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



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

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 (OP)
Legendary
*
Offline Offline

Activity: 4088
Merit: 1631


Ruu \o/


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

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



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

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 (OP)
Legendary
*
Offline Offline

Activity: 4088
Merit: 1631


Ruu \o/


View Profile WWW
November 04, 2013, 09:03:07 AM
Last edit: November 04, 2013, 09:14:44 AM by ckolivas
 #13178

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
OgNasty
Donator
Legendary
*
Offline Offline

Activity: 4718
Merit: 4226


Leading Crypto Sports Betting & Casino Platform


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

Blue Fury USB miners now hashing away!  Grin

..Stake.com..   ▄████████████████████████████████████▄
   ██ ▄▄▄▄▄▄▄▄▄▄            ▄▄▄▄▄▄▄▄▄▄ ██  ▄████▄
   ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██  ██████
   ██ ██████████ ██      ██ ██████████ ██   ▀██▀
   ██ ██      ██ ██████  ██ ██      ██ ██    ██
   ██ ██████  ██ █████  ███ ██████  ██ ████▄ ██
   ██ █████  ███ ████  ████ █████  ███ ████████
   ██ ████  ████ ██████████ ████  ████ ████▀
   ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██
   ██            ▀▀▀▀▀▀▀▀▀▀            ██ 
   ▀█████████▀ ▄████████████▄ ▀█████████▀
  ▄▄▄▄▄▄▄▄▄▄▄▄███  ██  ██  ███▄▄▄▄▄▄▄▄▄▄▄▄
 ██████████████████████████████████████████
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄
█  ▄▀▄             █▀▀█▀▄▄
█  █▀█             █  ▐  ▐▌
█       ▄██▄       █  ▌  █
█     ▄██████▄     █  ▌ ▐▌
█    ██████████    █ ▐  █
█   ▐██████████▌   █ ▐ ▐▌
█    ▀▀██████▀▀    █ ▌ █
█     ▄▄▄██▄▄▄     █ ▌▐▌
█                  █▐ █
█                  █▐▐▌
█                  █▐█
▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█
▄▄█████████▄▄
▄██▀▀▀▀█████▀▀▀▀██▄
▄█▀       ▐█▌       ▀█▄
██         ▐█▌         ██
████▄     ▄█████▄     ▄████
████████▄███████████▄████████
███▀    █████████████    ▀███
██       ███████████       ██
▀█▄       █████████       ▄█▀
▀█▄    ▄██▀▀▀▀▀▀▀██▄  ▄▄▄█▀
▀███████         ███████▀
▀█████▄       ▄█████▀
▀▀▀███▄▄▄███▀▀▀
..PLAY NOW..
DutchyGn
Newbie
*
Offline Offline

Activity: 42
Merit: 0


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

Any chance Technobit's HEX16A miner will be supported in the next versions?
Pages: « 1 ... 609 610 611 612 613 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 ... 843 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!