Bitcoin Forum
July 20, 2018, 03:26:34 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
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 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5756958 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.
jmc1517
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
October 30, 2013, 07:21:14 PM
 #13161

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712
1532100394
Hero Member
*
Offline Offline

Posts: 1532100394

View Profile Personal Message (Offline)

Ignore
1532100394
Reply with quote  #2

1532100394
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1532100394
Hero Member
*
Offline Offline

Posts: 1532100394

View Profile Personal Message (Offline)

Ignore
1532100394
Reply with quote  #2

1532100394
Report to moderator
1532100394
Hero Member
*
Offline Offline

Posts: 1532100394

View Profile Personal Message (Offline)

Ignore
1532100394
Reply with quote  #2

1532100394
Report to moderator
1532100394
Hero Member
*
Offline Offline

Posts: 1532100394

View Profile Personal Message (Offline)

Ignore
1532100394
Reply with quote  #2

1532100394
Report to moderator
aigeezer
Legendary
*
Offline Offline

Activity: 1426
Merit: 1009


Cryptanalyst castrated by his government, 1952


View Profile
October 30, 2013, 07:26:25 PM
 #13162

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712


Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.
aigeezer
Legendary
*
Offline Offline

Activity: 1426
Merit: 1009


Cryptanalyst castrated by his government, 1952


View Profile
October 30, 2013, 07:46:22 PM
 #13163

I'd like to think some other variable is at play here.  I've run every single version of cgminer from 3.3.1 to 3.5.1 and have never had a single problem.  I ran it on a Windows 7 machine 24/7 with two 7970 video cards and six block erupters.  The only down time I've had is from halting for software updates and the maybe an average of one restart a month for system updates.  After 3.5.1 I moved the block erupters to a raspberry pi and it has almost literally 100% up time.  The only times it has stopped mining are when I halted the process to start the latest version of cgminer.  It's run every version between 3.5.1 all the way up to 3.6.6 without issue.

There almost has to be some key variable...os, wiring, electrical, hardware defect, environment...

Chad

Were your 7970s hashing along with the erupters? I've got one 7970 on this machine, but haven't used it for hashing in quite a while - I've been running the nogpu version of cgminer through all this testing. One quirk of my testing was that whenever I ran with debug/logging on the errors didn't happen - no zombies, no failures, leading to the impression that it is some kind of timing/timeout issue.
forzendiablo
Legendary
*
Offline Offline

Activity: 1526
Merit: 1000


the grandpa of cryptos


View Profile
October 30, 2013, 08:21:49 PM
 #13164

That's the scrypt version of guiminer

yes but im speaking of mining BTC here, just thats the setup that works. i dont knwo what flags to use to make it work. mayeb some fan flags?

please help guys i mclueless.

yolo
chadtn
Sr. Member
****
Offline Offline

Activity: 481
Merit: 250



View Profile
October 30, 2013, 08:29:40 PM
 #13165

I'd like to think some other variable is at play here.  I've run every single version of cgminer from 3.3.1 to 3.5.1 and have never had a single problem.  I ran it on a Windows 7 machine 24/7 with two 7970 video cards and six block erupters.  The only down time I've had is from halting for software updates and the maybe an average of one restart a month for system updates.  After 3.5.1 I moved the block erupters to a raspberry pi and it has almost literally 100% up time.  The only times it has stopped mining are when I halted the process to start the latest version of cgminer.  It's run every version between 3.5.1 all the way up to 3.6.6 without issue.

There almost has to be some key variable...os, wiring, electrical, hardware defect, environment...

Chad

Were your 7970s hashing along with the erupters? I've got one 7970 on this machine, but haven't used it for hashing in quite a while - I've been running the nogpu version of cgminer through all this testing. One quirk of my testing was that whenever I ran with debug/logging on the errors didn't happen - no zombies, no failures, leading to the impression that it is some kind of timing/timeout issue.


Yeah...the video cards were hashing with the erupters in the same cgminer instance before going to the raspberry pi.

Chad

jmc1517
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
October 30, 2013, 09:13:10 PM
 #13166

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712
Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.

Well - hopefully it's the same problem!   That's how I stumbled upon this thread in the first place, remember?  We seem to confirm each other's findings re the test-builds, i.e. we both consistently get zombies and/or decaying hash-rates on the builds we've tested, but perhaps I see them more quickly as I'm running 34 erupters. Anyway, at the moment I'm happy with 3.5.1. It's been running about 4 hours in total and no errors, so hopefully it will survive overnight and become my new "stable" build.

As an aside, I have 2 * 7970's in my machine also, but they are happily mining LTC using another instance of 3.3.1 (I'll upgrade that to 3.5.1 at some point, even though it's not strictly necessary).

I haven't bothered trialling the latest test-builds.  I'll just leave 3.5.1 running until morning and see what ckolivas makes of all this. Shocked
aigeezer
Legendary
*
Offline Offline

Activity: 1426
Merit: 1009


Cryptanalyst castrated by his government, 1952


View Profile
October 30, 2013, 10:04:21 PM
 #13167

I'll just leave 3.5.1 running until morning and see what ckolivas makes of all this. Shocked

I just noticed I went straight from 3.5.0 to 3.6.2 "way back then" - never tried 3.5.1 along the way.

I've been running candidate rs10 all day. It gets occasional zombies but it seems as good as anything for the moment. Maybe I'll add debugging to it and see if that keeps the zombies from showing up the way it used to do.

The pressure mounts!         Smiley
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
October 30, 2013, 10:11:35 PM
 #13168

I'd like to think some other variable is at play here.  I've run every single version of cgminer from 3.3.1 to 3.5.1 and have never had a single problem.  I ran it on a Windows 7 machine 24/7 with two 7970 video cards and six block erupters.  The only down time I've had is from halting for software updates and the maybe an average of one restart a month for system updates.  After 3.5.1 I moved the block erupters to a raspberry pi and it has almost literally 100% up time.  The only times it has stopped mining are when I halted the process to start the latest version of cgminer.  It's run every version between 3.5.1 all the way up to 3.6.6 without issue.

There almost has to be some key variable...os, wiring, electrical, hardware defect, environment...

Chad

I have two win7x64 machines. One is AMD based, somewhat older technology (was a sempton single core, is now an athlon II dual core @ 3.4GHz with 4 gb memory), doesn't have any USB 3.0 ports.  3.6.4 works fine with my 36 erupters.  No problems aside from the possible winsock error, but recently I've been restarting it for other reasons before it runs more than a few days, so I don't know if the winsock error is still around or not.

I move the same 36 erupters and same hubs to the other machine, Intel based, core i7, 12 gb of memory, with USB 3.0 ports.  I almost immediately get zombies and IO errors.  Neither of which I get on the older machine.  Oh, and the erupters aren't detected at all on the USB 3.0 ports.  I have to plug them into the 2.0 ports to see them.

I think it's hardware based.  Chipset maybe?  Something beyond your control?

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
October 30, 2013, 10:13:33 PM
 #13169

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712


Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.

I'd get errors left and right on my AMD box with anything after 3.3.4, I think... until 3.6.4.  So what fixed problems for me caused problems for others.

M

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

Activity: 2590
Merit: 1111


Ruu \o/


View Profile WWW
October 31, 2013, 12:57:41 AM
 #13170

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712


Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.

In that case let me try

http://ck.kolivas.org/apps/cgminer/temp/cgminer-to.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
aigeezer
Legendary
*
Offline Offline

Activity: 1426
Merit: 1009


Cryptanalyst castrated by his government, 1952


View Profile
October 31, 2013, 01:09:18 AM
 #13171

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712


Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.

In that case let me try

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

Running "to" now after shutting down "rs10 with debug/log". As before, when debug is on, cgminer runs fine with no zombies or errors of any kinds - no LED drama either, just normal pinpoint flashes.

Only 5 minutes into "to" but it is well-behaved so far.

Edit: one hour in and the "to" version is perfect so far. It will run more-or-less unattended now for about 10 hours if possible.
paladin281978
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile
October 31, 2013, 01:12:08 AM
 #13172

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
 

techman05
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500


View Profile WWW
October 31, 2013, 01:20:43 AM
 #13173

whatever it is I'd think its right but just different. It looks like each device recognizing the block.

Like the info address for potential tips Wink
BTC 1CL5BnNhdL2wDVmSDwMbW1cNhZew87CAPV
* http://www.miningrigrentals.com/register?ref=563
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1111


Ruu \o/


View Profile WWW
October 31, 2013, 01:44:43 AM
 #13174

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.

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

Activity: 742
Merit: 500



View Profile
October 31, 2013, 02:01:59 AM
 #13175

I stay on 3.6.4

jmc1517
Jr. Member
*
Offline Offline

Activity: 56
Merit: 0


View Profile
October 31, 2013, 10:31:52 AM
 #13176

3.5.1 was stable overnight with my 34 erupters, although in the morning I had "lost" AMUs 17-12 which had been replaced by 34-37, but no zombies and my average hash-rate on Slush over ten rounds was the max I would have expected.

Now trialling the "to" version. Fingers crossed.
aigeezer
Legendary
*
Offline Offline

Activity: 1426
Merit: 1009


Cryptanalyst castrated by his government, 1952


View Profile
October 31, 2013, 11:50:18 AM
 #13177

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712


Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.

In that case let me try

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

After 10.75 hours the "to" version has one zombie, AMU5. I'm not sure how long it was there before I checked. I think the "to" version is the best of the recent candidates on my machine. I'll swap the zombie and keep the run going if I can.

Edit: the swap of AMU5 worked fine, but I just did a double-take looking at the allocations. The AMUs usually start out as AMU 0-12, with BAL0 somewhere in the middle or at the end. Now I have AMU0-4, BAL0, AMU7-8, 11, 14-17 - yikes it just changed again. It's saying AMU5 has gone zombie but there was no AMU5 a moment ago because it had been reallocated when the first zombie showed up. There is an LED on solid, but it's not the erupter that I just swapped. Bottom line - apparent allocation anomalies, and I get the feeling that it might have recovered from errors on its own and done some reallocations without intervention. I'll swap out the new zombie AMU5 and keep going if possible. Total run time now is 11 hours.

Edit: Getting weird. The "second AMU5" was reallocated to AMU18 when it was restarted - as expected. A few seconds later AMU3 went zombie. I think this is the same physical erupter as the original AMU5, which I restarted without moving it to a different location on the hub. Maybe I haven't had enough coffee but I thought it would be known as AMU17. Bottom line - the run seems to be getting flaky now, but my observations may include human error. I'll try to keep the run going though.

Edit: the AMU3 zombie was restarted as AMU19, as expected. Now showing AMU 0 1 2 4 7 8 11 14-19, with BAL 0 after AMU 4.

Edit: about an hour later - the display now says that AMU3 is a zombie - but there was no AMU3 (see list above). The display also shows AMU15 has gone to hashrate zero. Two LEDs are on. I'll keep it all going if possible.

Edit: I unplugged an erupter with its LED on. The display said AMU5 had gone zombie. Five? There was no five. AMU15 had morphed to five, it seems, as it was no longer showing at zero hashrate. Plugged it back in and it got reallocated to AMU20. The list is now AMU 0 1 2 4 BAL0 AMU 7 8 11 14 17-20 then AMU3 showing as a zombie. I imagine 3 will get reallocated to 21 when I restart it.

Edit: Yes, 3 became 21 when plugged back in, and it is slowly climbing back to full hash rate.

Edit: Another hour or so later I find five zombies, listed as AMU 3,5,6,9 and 10 - none of those numbers were in use (see above). Still reported running are AMU 0, 1, 2, 4, 7, 8, 11, 17 and the BAL. I'll start the run from scratch, I think, sticking with "to" candidate.

Edit: Since the restart, the "to" candidate has run for seven hours with no errors or anomalies, still going strong.




-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1111


Ruu \o/


View Profile WWW
October 31, 2013, 12:03:54 PM
 #13178

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712


Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.

I'd get errors left and right on my AMD box with anything after 3.3.4, I think... until 3.6.4.  So what fixed problems for me caused problems for others.
Since yours got better moving to 3.6.x, can you also test to see if the -to binary does not make things worse for you please?

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

Thanks!

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
October 31, 2013, 12:31:17 PM
 #13179

Looks like the "bug" - if we can call it that - started with the 3.6.x build:
    https://bitcointalk.org/index.php?topic=28402.msg3443712#msg3443712
Yikes, you and I may have separate issues after all and/or there may be more than one issue to be found. The plot thickens. I sure hope my problem isn't right under my nose.
In that case let me try

http://ck.kolivas.org/apps/cgminer/temp/cgminer-to.exe
After 10.75 hours the "to" version has one zombie, AMU5. I'm not sure how long it was there before I checked. I think the "to" version is the best of the recent candidates on my machine. I'll swap the zombie and keep the run going if I can.
ckolivas, I think you may be on to something here with the "to" build.  It seems to be the best so far, but not stable like the 3.5.1 build.

I had it running for 1 hour 20 mins before a zombie AMU 29 appeared, which in itself is longer than the other tests have managed.  However, I checked the logfile and found that the zombie was preceded by LIBUSB_ERROR_TIMEOUTs from AMU 20 and it was followed by repeated LIBUSB_ERROR_TIMEOUTs from AMU 0.  Once the errors from AMU 0 start, there appears to be a permanent condition such they never stop.

Now here's the interesting bit: I unplugged the zombie AMU 29 and removed it for about 5-10 secs, then plugged it back in.  It hotplugged perfectly as AMU34 and started working and at the same time the errors for AMU 0 stopped.

Wait.... Now I have another zombie AMU 16, and repeated errors from AMU 0.   I have unplugged it and left it out and the errors from AMU 0 have stopped.  The zombie is still showing in the list (I suppose it would as no communication exists with it?)  Anyway, I've now plugged it back in and the zombie has disappeared, to be replaced by AMU 35.  All working normally again for a few minutes, but now more errors and another zombie AMU 16.  This is behaving almost like a memory leak (?) - once the errors start, they keep coming and re-occur more frequently.

I have unplugged AMU 16 - so only 33 erupters plugged in at the moment -and the errors on screen have stopped.

I suspect that if I plug it in again, the errors will restart, but I'll give it one more go. Hotplugged at 12:22 - Recognised as AMU 36 - ...and mining ok again.  I'll leave it while I have lunch and come back in an hour...

Edit: Stopped due to ongoing errors.

Logfile (without --debug) here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-to.txt
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1111


Ruu \o/


View Profile WWW
October 31, 2013, 12:39:19 PM
 #13180

ckolivas, I think you may be on to something here with the "to" build.  It seems to be the best so far, but not stable like the 3.5.1 build.

I had it running for 1 hour 20 mins before a zombie AMU 29 appeared, which in itself is longer than the other tests have managed.  However, I checked the logfile and found that the zombie was preceded by LIBUSB_ERROR_TIMEOUTs from AMU 20 and it was followed by repeated LIBUSB_ERROR_TIMEOUTs from AMU 0.  Once the errors from AMU 0 start, there appears to be a permanent condition such they never stop.
Thanks. What was the initial timeout error? Did it say whether it was a write or a read?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
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 ... 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!