Bitcoin Forum
June 20, 2018, 06:09:12 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5756333 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.
stridergt
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
November 25, 2013, 10:07:21 PM
 #13621

I am using minepeon (cgminer3.6.4) with a Jalapeno and observing that DAcc (Difficulty Accepted) is 60-85% when mining with the eligius pool and 100-105% when mining with BTCguild. (both pools had min difficulty set to auto, but even when I changed BTCguild to 8+GH/s, the difference in percentage roughly stayed the same)
Can someone elaborate a bit on the Dacc calculation and the difference I am observing between the two pools, does it affect my share contribution accordingly???
I checked github, but I was a bit lost. I also asked at the minepeon forum but the dev just parsed the DAcc value and could not elaborate on the calculation method.

Thank you in advance
1529474952
Hero Member
*
Offline Offline

Posts: 1529474952

View Profile Personal Message (Offline)

Ignore
1529474952
Reply with quote  #2

1529474952
Report to moderator
1529474952
Hero Member
*
Offline Offline

Posts: 1529474952

View Profile Personal Message (Offline)

Ignore
1529474952
Reply with quote  #2

1529474952
Report to moderator
1529474952
Hero Member
*
Offline Offline

Posts: 1529474952

View Profile Personal Message (Offline)

Ignore
1529474952
Reply with quote  #2

1529474952
Report to moderator
The World's Betting Exchange

Bet with play money. Win real Bitcoin. 5BTC Prize Fund for World Cup 2018.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jmc1517
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
November 25, 2013, 10:26:57 PM
 #13622


Thanks for that. Here is your next test please

http://ck.kolivas.org/apps/cgminer/temp/cgminer-rst.exe
And to follow:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-fff.exe

[/quote]

OK, Started the next test of cgminer-rst at 16:46.  First zombie (AMU11) at 21:07 after about 5 hours.  Test stopped at 21:31.  Note that the previous run of 3.5.1 ran for about 16 hours, again with no apparent flaws. Final status included at the start of the "rst" logfile for reference.  I am not logging runs of 3.5.1 but can do if it would reveal anything useful for comparison.

Logfile (without --debug) here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-rst.txt

Next started cgminer-fff at 21:35. First zombie appeared at 22:10. Test stopped at 22:13.

Logfile (without --debug) here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-fff.txt

Back to 3.5.1 again...
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1092


Ruu \o/


View Profile WWW
November 25, 2013, 10:36:40 PM
 #13623

Next started cgminer-fff at 21:35. First zombie appeared at 22:10. Test stopped at 22:13.

Logfile (without --debug) here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-fff.txt

Can you try fff again and this time when it gets into the loop of errors, enable debug in the display menu and continue logging for a bit please?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
CustomDesigned
Jr. Member
*
Offline Offline

Activity: 35
Merit: 0


View Profile
November 26, 2013, 12:58:00 AM
 #13624


This code is provided entirely free of charge by the programmer in his spare
time so donations would be greatly appreciated. Please consider donating to the
address below.

Con Kolivas <kernel@kolivas.org>
15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ

---

Primary developer/maintainer for cgminer: https://bitcointalk.org/index.php?topic=28402.0  148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq
Why are there two bitcoin addresses?  Which one do I send a (small) donation to?  When I get "over the size limit", do I always need to pay the transaction fee, or does waiting a while also work?  UPDATE: waiting a while works.  I sent to the 15qS... address - hope that is correct.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1092


Ruu \o/


View Profile WWW
November 26, 2013, 01:04:22 AM
 #13625


This code is provided entirely free of charge by the programmer in his spare
time so donations would be greatly appreciated. Please consider donating to the
address below.

Con Kolivas <kernel@kolivas.org>
15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ

---

Primary developer/maintainer for cgminer: https://bitcointalk.org/index.php?topic=28402.0  148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq
Why are there two bitcoin addresses?  Which one do I send a (small) donation to?  When I get "over the size limit", do I always need to pay the transaction fee, or does waiting a while also work?

I like to keep track of whether donations are from the source code or from the forum, thanks! Whether you should send a transaction fee or not is determined entirely by bitcoind. If you choose not to, it can take ages to go through or potentially may never do so.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
jmc1517
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
November 26, 2013, 03:51:31 PM
 #13626

Next started cgminer-fff at 21:35. First zombie appeared at 22:10. Test stopped at 22:13.

Logfile (without --debug) here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-fff.txt

Can you try fff again and this time when it gets into the loop of errors, enable debug in the display menu and continue logging for a bit please?

OK, done.  Aside: The previous overnight run of 3.5.1 went for 14 hours, no faults.

Started cgminer-fff again.  After about 3 hours I got several LEDs full on for a few seconds. Two of them went out and resumed mining but the 3rd appeared in the display as a zombie.  I was sitting next to the PC at the time, so turned on debug straight away.  I left it running for a further 5 minutes then stopped it.

Logfile here, but I suspect it's not going to help:
  https://dl.dropboxusercontent.com/u/44240170/logfile-fff2.txt

And...... Back to 3.5.1 again :/
CustomDesigned
Jr. Member
*
Offline Offline

Activity: 35
Merit: 0


View Profile
November 26, 2013, 05:01:15 PM
 #13627


Logfile here, but I suspect it's not going to help:
  https://dl.dropboxusercontent.com/u/44240170/logfile-fff2.txt

And...... Back to 3.5.1 again :/


This from 3.8.3 may give a clue:
 [2013-11-26 11:54:02] SEM: Icarus USB open failed '/tmp/cgminer-usb-1-58' err (24) Too many open files

It revives the zombies until it runs out of file descriptors on unix.  Maybe some similar resource exhaustion is happening on Windows?

Summary of runtime statistics:

 [2013-11-26 11:54:14] Started at [2013-11-23 11:22:25]
 [2013-11-26 11:54:14] Pool: http://api.polmine.pl:8347
 [2013-11-26 11:54:14] Runtime: 72 hrs : 31 mins : 49 secs
 [2013-11-26 11:54:14] Average hashrate: 1298.2 Megahash/s
 [2013-11-26 11:54:14] Solved blocks: 0
 [2013-11-26 11:54:14] Best share difficulty: 204K
 [2013-11-26 11:54:14] Share submissions: 47169
 [2013-11-26 11:54:14] Accepted shares: 46323
 [2013-11-26 11:54:14] Rejected shares: 846
 [2013-11-26 11:54:14] Accepted difficulty shares: 76307
 [2013-11-26 11:54:14] Rejected difficulty shares: 919
 [2013-11-26 11:54:14] Reject ratio: 1.8%
 [2013-11-26 11:54:14] Hardware errors: 837
 [2013-11-26 11:54:14] Utility (accepted shares / min): 10.64/min               
 [2013-11-26 11:54:14] Work Utility (diff1 shares solved / min): 13.76/min

 [2013-11-26 11:54:14] Stale submissions discarded due to new blocks: 0         
 [2013-11-26 11:54:14] Unable to get work from server occasions: 0               
 [2013-11-26 11:54:14] Work items generated locally: 130566
 [2013-11-26 11:54:14] Submitting work remotely delay occasions: 0               
 [2013-11-26 11:54:14] New blocks detected on network: 508
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1092


Ruu \o/


View Profile WWW
November 26, 2013, 08:01:16 PM
 #13628

his from 3.8.3 may give a clue:
 [2013-11-26 11:54:02] SEM: Icarus USB open failed '/tmp/cgminer-usb-1-58' err (24) Too many open files

It revives the zombies until it runs out of file descriptors on unix.  Maybe some similar resource exhaustion is happening on Windows?

Interesting thought. It's easy enough to raise the number of file descriptors allowed in unix, but the default on windows should be much higher. Either way we should be removing the semaphores when the devices get zombied so that's at least one fix worth adding, thanks.

EDIT: Checked the code and the semaphores are being removed so that's not it.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
stridergt
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
November 26, 2013, 10:08:42 PM
 #13629

I am using minepeon (cgminer3.6.4) with a Jalapeno and observing that DAcc (Difficulty Accepted) is 60-85% when mining with the eligius pool and 100-105% when mining with BTCguild. (both pools had min difficulty set to auto, but even when I changed BTCguild to 8+GH/s, the difference in percentage roughly stayed the same)
Can someone elaborate a bit on the Dacc calculation and the difference I am observing between the two pools, does it affect my share contribution accordingly???
I checked github, but I was a bit lost. I also asked at the minepeon forum but the dev just parsed the DAcc value and could not elaborate on the calculation method.

Thank you in advance

Have I asked in the wrong thread? :-)
Please advise if so...
kano
Legendary
*
Online Online

Activity: 2492
Merit: 1042


Linux since 1997 RedHat 4


View Profile
November 27, 2013, 12:23:32 AM
 #13630

I am using minepeon (cgminer3.6.4) with a Jalapeno and observing that DAcc (Difficulty Accepted) is 60-85% when mining with the eligius pool and 100-105% when mining with BTCguild. (both pools had min difficulty set to auto, but even when I changed BTCguild to 8+GH/s, the difference in percentage roughly stayed the same)
Can someone elaborate a bit on the Dacc calculation and the difference I am observing between the two pools, does it affect my share contribution accordingly???
I checked github, but I was a bit lost. I also asked at the minepeon forum but the dev just parsed the DAcc value and could not elaborate on the calculation method.

Thank you in advance

Have I asked in the wrong thread? :-)
Please advise if so...
DA is the value in 1diff of all shares accepted.
If you submit 10 50diff shares and all are accepted then DA would be 500

I've no idea what you mean those % numbers are.

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: 2562
Merit: 1092


Ruu \o/


View Profile WWW
November 27, 2013, 12:12:53 PM
 #13631

Can you try fff again and this time when it gets into the loop of errors, enable debug in the display menu and continue logging for a bit please?

OK, done.  Aside: The previous overnight run of 3.5.1 went for 14 hours, no faults.

Started cgminer-fff again.  After about 3 hours I got several LEDs full on for a few seconds. Two of them went out and resumed mining but the 3rd appeared in the display as a zombie.  I was sitting next to the PC at the time, so turned on debug straight away.  I left it running for a further 5 minutes then stopped it.

Logfile here, but I suspect it's not going to help:
  https://dl.dropboxusercontent.com/u/44240170/logfile-fff2.txt

And...... Back to 3.5.1 again :/

Thanks very much for that. Believe it or not I am (very slowly) making progress.

Here's the next test please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-ffs.exe

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

Activity: 1904
Merit: 1001



View Profile
November 27, 2013, 02:09:00 PM
 #13632

are vga still supported?

and why i can't copy past anymore with cgminer?
os2sam
Legendary
*
Offline Offline

Activity: 2464
Merit: 1001


Think for yourself


View Profile
November 27, 2013, 03:06:56 PM
 #13633

are vga still supported?

New release: Version 3.8.1, 10th November 2013

GPU mining in any form is gone. Long live GPU mining (see previous post). New hardware support in this release and massive change with removal of GPU mining, but only bugfixes to the remainder of the code so to existing users this should be a safe upgrade, in keeping with even number releases sounding more stable.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Amph
Legendary
*
Offline Offline

Activity: 1904
Merit: 1001



View Profile
November 27, 2013, 04:07:37 PM
 #13634

yeah, i searched for it after my post
jmc1517
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
November 27, 2013, 06:59:34 PM
 #13635


Thanks very much for that. Believe it or not I am (very slowly) making progress.

Here's the next test please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-ffs.exe

OK, tested!  Aside [again] The previous run of 3.5.1 lasted 25 hours without problems, although I do remember seeing a few AMU LEDs come on yesterday for a couple of seconds and I noticed some messages which were something like the following (completely from memory, as no logging enabled, can't remember the exact mS timings):
  [2013-11-xx xx:xx:xx] TIMEOUT AMUx something took xxx mS, was xxx mS
  [2013-11-xx xx:xx:xx] TIMEOUT AMUy something took xxx mS, was xxx mS
The above disturbances didn't cause any problems, so it may just be normal network problems, but I haven't noticed them before, so perhaps it's important, perhaps not.

Anyway, the test of cgminer-ffs ran for almost 2 hours, then a zombie appeared.  I turned on debug from the display and let run for a further 5 minutes, then stopped it.

Logfile is here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-ffs.txt

And.... back to 3.5.1 for the evening!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1092


Ruu \o/


View Profile WWW
November 27, 2013, 08:45:17 PM
 #13636

OK, tested!  Aside [again] The previous run of 3.5.1 lasted 25 hours without problems, although I do remember seeing a few AMU LEDs come on yesterday for a couple of seconds and I noticed some messages which were something like the following (completely from memory, as no logging enabled, can't remember the exact mS timings):
  [2013-11-xx xx:xx:xx] TIMEOUT AMUx something took xxx mS, was xxx mS
  [2013-11-xx xx:xx:xx] TIMEOUT AMUy something took xxx mS, was xxx mS
The above disturbances didn't cause any problems, so it may just be normal network problems, but I haven't noticed them before, so perhaps it's important, perhaps not.

Anyway, the test of cgminer-ffs ran for almost 2 hours, then a zombie appeared.  I turned on debug from the display and let run for a further 5 minutes, then stopped it.

Logfile is here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-ffs.txt

Thanks for that. No you were getting the timer overruns previously as well. I saw them on your successful logging when you put it up so even when it's "fine" it's not entirely fine, it's just that it sort of recovers.

Next!
http://ck.kolivas.org/apps/cgminer/temp/cgminer-w00t.exe

EDIT: And one greater than 9000:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-9001.exe

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
ChipGeek
Full Member
***
Offline Offline

Activity: 198
Merit: 100


View Profile
November 28, 2013, 03:28:46 AM
 #13637

MrTeal and I have developed mining hardware called Chili using BFL chips and it uses the BLF driver.  The driver interface / protocol defines a command (ZTX) that allows cgminer to request three voltages from the hardware.  The 3 values are typically  3.3V, 1.0V, and 12V.  cgminer displays the 3.3V value on the screen but in my opinion this is the least interesting voltage value.  I would prefer it to show the (nominal) 1.0V value as this directly impacts hashing speed and power.  On other BFL hardware, this value is fixed at the factory, but on a Chili, it is configurable by software allowing automatic overclocking.  Thus the interest in displaying this value.

Please consider this reply a formal request to change the displayed value from the 3.3V value to the 1.0V value.  If you have enough screen real estate, it should show 3 digits to the right of the decimal point.  Ex: 1.057V  Thank you.

BTW - We have added a new field to the ZCX command to distinguish our hardware apart from BFL hardware:
Code:
"MANUFACTURER: MrTeal and ChipGeek\n"

Tip jar: 1ChipGeeK7PDxaAWG4VgsTi31SfJ6peKHw
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1092


Ruu \o/


View Profile WWW
November 28, 2013, 04:32:47 AM
 #13638

MrTeal and I have developed mining hardware called Chili using BFL chips and it uses the BLF driver.  The driver interface / protocol defines a command (ZTX) that allows cgminer to request three voltages from the hardware.  The 3 values are typically  3.3V, 1.0V, and 12V.  cgminer displays the 3.3V value on the screen but in my opinion this is the least interesting voltage value.  I would prefer it to show the (nominal) 1.0V value as this directly impacts hashing speed and power.  On other BFL hardware, this value is fixed at the factory, but on a Chili, it is configurable by software allowing automatic overclocking.  Thus the interest in displaying this value.

Please consider this reply a formal request to change the displayed value from the 3.3V value to the 1.0V value.  If you have enough screen real estate, it should show 3 digits to the right of the decimal point.  Ex: 1.057V  Thank you.

BTW - We have added a new field to the ZCX command to distinguish our hardware apart from BFL hardware:
Code:
"MANUFACTURER: MrTeal and ChipGeek\n"

We're not as scary as we may appear. If you push code via github to cgminer that doesn't affect other drivers, we will probably give you some basic changes we'd prefer before merging the code with cgminer, but are happy to include code with the master cgminer code if you do it that way and are happy to support it. Ideally we prefer to get the hardware ourselves so we can extend/develop/bugfix/support the code for the hardware ourselves until the hardware is no longer relevant, but if not, I'm happy to merge code from you while you personally support the code unless it interferes with other drivers or the code stops being supported as bugs appear (which they always do).

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
kano
Legendary
*
Online Online

Activity: 2492
Merit: 1042


Linux since 1997 RedHat 4


View Profile
November 28, 2013, 05:21:42 AM
 #13639

MrTeal and I have developed mining hardware called Chili using BFL chips and it uses the BLF driver.  The driver interface / protocol defines a command (ZTX) that allows cgminer to request three voltages from the hardware.  The 3 values are typically  3.3V, 1.0V, and 12V.  cgminer displays the 3.3V value on the screen but in my opinion this is the least interesting voltage value.  I would prefer it to show the (nominal) 1.0V value as this directly impacts hashing speed and power.  On other BFL hardware, this value is fixed at the factory, but on a Chili, it is configurable by software allowing automatic overclocking.  Thus the interest in displaying this value.

Please consider this reply a formal request to change the displayed value from the 3.3V value to the 1.0V value.  If you have enough screen real estate, it should show 3 digits to the right of the decimal point.  Ex: 1.057V  Thank you.

BTW - We have added a new field to the ZCX command to distinguish our hardware apart from BFL hardware:
Code:
"MANUFACTURER: MrTeal and ChipGeek\n"

Yep I'll change it in the next few days Smiley

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!
PenAndPaper
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
November 28, 2013, 07:10:12 AM
 #13640

Wasn't there a scrypt readme somewhere? I can't find it anymore  Lips sealed
No scrypt support any more.

Maybe you want to reconsider that given the latest boom in price, although i don't know the reasons that you stopped in the first place.
Pages: « 1 ... 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 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 ... 847 »
  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!