Bitcoin Forum
July 16, 2018, 03:29:56 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 715 716 717 718 719 720 721 722 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5756838 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.
loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
November 09, 2013, 12:08:00 PM
 #13421

Yues i guess i do not understand the details but with latest git i am experiencing deadlocks

applog(LOG_WARNING, "Waiting for work to be available from pools.");
and everything is freezing

If i find out the reason i will let you know but something is not right

PS- Why did you disable Avalon lock lately - commit c3f13369961a7be6b19fe838ac4b5a7bc8592b16? If everything is ok the lock shall be ok also.

Anyway Thank you


Hello

I do think that this piece of code can create dead locks we are waiting to be awaken pthread_cond_wait holding lock mutex_lock(stgd_lock);

      mutex_lock(stgd_lock);
      ts = __total_staged();

      if (!pool_localgen(cp) && !ts && !opt_fail_only)
         lagging = true;

      /* Wait until hash_pop tells us we need to create more work */
      if (ts > max_staged) {
         pthread_cond_wait(&gws_cond, stgd_lock);
         ts = __total_staged();
      }
      mutex_unlock(stgd_lock);


From the other side wake_gws needs same lock and so on and so on....Con please take a look at it when you can

static void wake_gws(void)
{
   mutex_lock(stgd_lock);
   pthread_cond_signal(&gws_cond);
   mutex_unlock(stgd_lock);
}

A quick fix might be

      mutex_lock(stgd_lock);
      ts = __total_staged();
                 mutex_unlock(stgd_lock);

      if (!pool_localgen(cp) && !ts && !opt_fail_only)
         lagging = true;

      /* Wait until hash_pop tells us we need to create more work */
      if (ts > max_staged) {
         pthread_cond_wait(&gws_cond, stgd_lock);
         mutex_lock(stgd_lock);
                        ts = __total_staged();
                        mutex_unlock(stgd_lock);

      }



I appreciate you looking over the code, however I guess you don't understand that pthread_cond_wait DROPS the mutex lock associated with it. You are supposed to called a pthread conditional wait holding a mutex lock and it picks up the lock again when the conditional or timeout is over.

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
1531754996
Hero Member
*
Offline Offline

Posts: 1531754996

View Profile Personal Message (Offline)

Ignore
1531754996
Reply with quote  #2

1531754996
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2576
Merit: 1110


Ruu \o/


View Profile WWW
November 09, 2013, 12:11:22 PM
 #13422


PS- Why did you disable Avalon lock lately? If everything is ok the lock shall be ok also.
Everything was not okay with the avalon. There are recursive locks called in a different order from the async flush code and the avalon code. Recursive locks in a different order cause deadlocks.

If you are having deadlocks then perhaps you have a hardware driver with a similar problem. The one I have not been able to fully audit so far is the klondike driver which may be prone to the same problem.

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

Activity: 1610
Merit: 1000


View Profile
November 09, 2013, 12:13:20 PM
 #13423


PS- Why did you disable Avalon lock lately? If everything is ok the lock shall be ok also.
Everything was not okay with the avalon. There are recursive locks called in a different order from the async flush code and the avalon code. Recursive locks in a different order cause deadlocks.

If you are having deadlocks then perhaps you have a hardware driver with a similar problem. The one I have not been able to fully audit so far is the klondike driver which may be prone to the same problem.

Thank you con!!!!

You do not mind to spam the thread now and then do you? I am finding bugs from time to times Smiley

I am joking..Thank you very much

Best

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2576
Merit: 1110


Ruu \o/


View Profile WWW
November 09, 2013, 12:18:12 PM
 #13424


PS- Why did you disable Avalon lock lately? If everything is ok the lock shall be ok also.
Everything was not okay with the avalon. There are recursive locks called in a different order from the async flush code and the avalon code. Recursive locks in a different order cause deadlocks.

If you are having deadlocks then perhaps you have a hardware driver with a similar problem. The one I have not been able to fully audit so far is the klondike driver which may be prone to the same problem.

Thank you con!!!!

You do not mind to spam the thread now and then do you? I am finding bugs from time to times Smiley

I am joking..Thank you very much
Absolutely do not mind at all. People auditing code is rare, and reporting meaningful bugs is the key to fixing them. What hardware do you have anyway, if you are having deadlock problems?

By the way, if you can reliably reproduce what appears to be a deadlock, make sure you have the absolute latest git, edit miner.h to enable LOCK_TRACKING
change line 765
Code:
#define LOCK_TRACKING 0
to
Code:
#define LOCK_TRACKING 1
and start cgminer logging the output and with the API enabled with for example the following extra options:
Code:
--api-listen --api-allow "W:127.0.0.1" 2>log.txt
and when you see a deadlock send the command to get a summary of the lock status with
Code:
java API lockstats
This should spew extra information into the logging file you generated called log.txt which will allow me to see how the deadlock was caused.


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

Activity: 1610
Merit: 1000


View Profile
November 09, 2013, 12:23:11 PM
 #13425


PS- Why did you disable Avalon lock lately? If everything is ok the lock shall be ok also.
Everything was not okay with the avalon. There are recursive locks called in a different order from the async flush code and the avalon code. Recursive locks in a different order cause deadlocks.

If you are having deadlocks then perhaps you have a hardware driver with a similar problem. The one I have not been able to fully audit so far is the klondike driver which may be prone to the same problem.

Thank you con!!!!

You do not mind to spam the thread now and then do you? I am finding bugs from time to times Smiley

I am joking..Thank you very much
Absolutely do not mind at all. People auditing code is rare, and reporting meaningful bugs is the key to fixing them. What hardware do you have anyway, if you are having deadlock problems?

By the way, if you can reliably reproduce what appears to be a deadlock, make sure you have the absolute latest git, edit miner.h to enable LOCK_TRACKING
change line 765
Code:
#define LOCK_TRACKING 0
to
Code:
#define LOCK_TRACKING 1
and start cgminer logging the output and with the API enabled with for example the following extra options:
Code:
--api-listen --api-allow "W:127.0.0.1" 2>log.txt
and when you see a deadlock send the command to get a summary of the lock status with
Code:
java API lockstats
This should spew extra information into the logging file you generated called log.txt which will allow me to see how the deadlock was caused.



Thank You!

I will do as suggested. I do have HEX16A. And i am playing with them for the moment

I will let you know if i find out what happens related to your code as long hex16 is not pushed to your git ...
Best

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2576
Merit: 1110


Ruu \o/


View Profile WWW
November 09, 2013, 12:24:25 PM
 #13426

I will do as suggested. I do have HEX16A. And i am playing with them for the moment

I will let you know if i find out what happens related to your code as long hex16 is not pushed to your git ...
Ah in that case, make sure your report your bug to the hex16 maintainer, not me since it's not cgminer code.

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

Activity: 1610
Merit: 1000


View Profile
November 09, 2013, 02:48:12 PM
 #13427

I will do as suggested. I do have HEX16A. And i am playing with them for the moment

I will let you know if i find out what happens related to your code as long hex16 is not pushed to your git ...
Ah in that case, make sure your report your bug to the hex16 maintainer, not me since it's not cgminer code.
Con, I will try to filter out bugs and report the ones which are related to your code only

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
os2sam
Legendary
*
Offline Offline

Activity: 2464
Merit: 1001


Think for yourself


View Profile
November 09, 2013, 03:05:42 PM
 #13428

I have two block erupters that are producing about a Ths for me.  That would be great if weren't a Ths of Hardware errors.  I have seen others report very high hash rates for BE's but I don't remember what the consensus was.  Is this a BE, Hub or CGMiner issue?  Any insight would be appreciated.
Sam

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

Activity: 532
Merit: 501


View Profile
November 09, 2013, 03:09:15 PM
 #13429

I have a USB driver question (not a complaint).

Have you changed any USB driver components between 3.6.4 and 3.7.2?

Because all of a sudden, I cannot for the life of me get CGminer 3.7.2 to work with my USB block erupters at all, while going thru Anker USB hubs (I have two hubs, none of them wants to work with CGminer 3.7.2).

If I reboot, and start up CGminer 3.6.4, same machine, different CGminers in different directories, 3.6.4 works fine.

I start up 3.7.2, no AMUs get recognized thru the hub. The only way they get recognized by CGminer 3.7.2 is if I plug them into the computer's usb ports directly.

The Anker hubs are USB 3.0 hubs, so it seems like there is some kind of issue when going from USB 2.0 to USB 3.0., either with CGminer or the Anker hubs.

This is a pure Linux Mint 14 machine, AMD processor, with the each version of CGminer compiled using --enable-icarus --enable-klondike --no-gpu --disable-opencl

I don't remember what the flags were for each compile (I think I have them written down somewhere), but the earlier version had a different set...I'm guessing that's important? (I think I loaded libtool, libncurses-dev yasm curl , for the 3.6.4 compilation, but not for the 3.7.2 compilation).

The 3.7.2 compile I just did

cd cgminer
chmod +x ./autogen.sh
./autogen.sh
./configure --enable-icarus --enable-klondike --no-gpu --disable-opencl
make

Version 3.6.4 used to also recognized Klondikes going thru the Anker hub, but it does not anymore under 3.7.2. Both icarus and klondikes work fine when plugged directly into the usb ports under 3.6.4.

Weird, isn't it?  Shocked

Any thoughts would be greatly appreciated. Thank you for all your work on this.



disclaimer201
Legendary
*
Offline Offline

Activity: 1470
Merit: 1000


View Profile
November 09, 2013, 03:33:39 PM
 #13430

Any support for hashbusters nano in the pipe? Then I could get rid of the virtualbox. Cheers.
Sampey
Legendary
*
Offline Offline

Activity: 1848
Merit: 1016



View Profile
November 09, 2013, 08:07:36 PM
 #13431

Hi,
i've a problem and i hope i'll be able to explain.

- Windows 7
- Bitburner fury running with Zadig Driver
- If i Plug the Usb Hub with USB Asic Erupter the Bitburner stops to work and i must reinstall all drivers.

There's a way to run Bitburner Fury + Usb Asic Erupter at the same time?

Thank you so much.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2576
Merit: 1110


Ruu \o/


View Profile WWW
November 09, 2013, 08:49:21 PM
 #13432

I have two block erupters that are producing about a Ths for me.  That would be great if weren't a Ths of Hardware errors.  I have seen others report very high hash rates for BE's but I don't remember what the consensus was.  Is this a BE, Hub or CGMiner issue?  Any insight would be appreciated.
Sam
It normally takes a 335MH device ~12.8 seconds to check all nonces in a single work item. The BEs use the icarus protocol which means as soon as they find a result, they report it back and then stop working. This can happen anywhere between zero and 12.8 seconds. The driver then gives it more work and the cycle starts all over again. If you can imagine the device coming back with a "result" in say .1 second and does this every time, the driver probably thinks it's running at a terrahash. However if it's a wrong result most of the time, it's meaningless. The driver shouldn't really be reporting it back as 1TH then so it's a mistake in the calculation in the driver. Kano might want to chime in since he wrote most of the driver.

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

Activity: 2506
Merit: 1043


Linux since 1997 RedHat 4


View Profile
November 09, 2013, 08:57:16 PM
 #13433

I have two block erupters that are producing about a Ths for me.  That would be great if weren't a Ths of Hardware errors.  I have seen others report very high hash rates for BE's but I don't remember what the consensus was.  Is this a BE, Hub or CGMiner issue?  Any insight would be appreciated.
Sam
It normally takes a 335MH device ~12.8 seconds to check all nonces in a single work item. The BEs use the icarus protocol which means as soon as they find a result, they report it back and then stop working. This can happen anywhere between zero and 12.8 seconds. The driver then gives it more work and the cycle starts all over again. If you can imagine the device coming back with a "result" in say .1 second and does this every time, the driver probably thinks it's running at a terrahash. However if it's a wrong result most of the time, it's meaningless. The driver shouldn't really be reporting it back as 1TH then so it's a mistake in the calculation in the driver. Kano might want to chime in since he wrote most of the driver.
This happens when you use the timing option (short or long) and the documentation reference in FPGA-README is:

'short' or 'long' mode should only be used on a computer that has enough CPU available to run
cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
Any CPU delays while calculating the hash time will affect the result
'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
corrects itself

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: 2576
Merit: 1110


Ruu \o/


View Profile WWW
November 09, 2013, 08:57:55 PM
 #13434

I have a USB driver question (not a complaint).

Have you changed any USB driver components between 3.6.4 and 3.7.2?

Because all of a sudden, I cannot for the life of me get CGminer 3.7.2 to work with my USB block erupters at all, while going thru Anker USB hubs (I have two hubs, none of them wants to work with CGminer 3.7.2).

If I reboot, and start up CGminer 3.6.4, same machine, different CGminers in different directories, 3.6.4 works fine.

I start up 3.7.2, no AMUs get recognized thru the hub. The only way they get recognized by CGminer 3.7.2 is if I plug them into the computer's usb ports directly.

The Anker hubs are USB 3.0 hubs, so it seems like there is some kind of issue when going from USB 2.0 to USB 3.0., either with CGminer or the Anker hubs.

This is a pure Linux Mint 14 machine, AMD processor, with the each version of CGminer compiled using --enable-icarus --enable-klondike --no-gpu --disable-opencl

I don't remember what the flags were for each compile (I think I have them written down somewhere), but the earlier version had a different set...I'm guessing that's important? (I think I loaded libtool, libncurses-dev yasm curl , for the 3.6.4 compilation, but not for the 3.7.2 compilation).

The 3.7.2 compile I just did

cd cgminer
chmod +x ./autogen.sh
./autogen.sh
./configure --enable-icarus --enable-klondike --no-gpu --disable-opencl
make

Version 3.6.4 used to also recognized Klondikes going thru the Anker hub, but it does not anymore under 3.7.2. Both icarus and klondikes work fine when plugged directly into the usb ports under 3.6.4.

Weird, isn't it?  Shocked

Any thoughts would be greatly appreciated. Thank you for all your work on this.

I have heard of issues with USB3 and libusb but this is the first before and after type report like this so it could be helpful for us to find out why. If you're building it yourself from git, can you do a bisect to find when it started? Here is how to do it from 3.6.4 to 3.7.2:

Code:
git checkout v3.7.2
git bisect start
git bisect bad
git bisect good v3.6.4
Then it will find halfway points between them and you can rebuild it each time to and report back to git

Code:
git bisect bad
If it doesn't detect the devices
or
Code:
git bisect good
if it does.

If for some reason one of the steps along the way doesn't build or crashes  or hangs or something else due to being in a dodgy commit, just skip it with
Code:
git bisect skip

When it's all over git should report to you something like "The first offending commit is XXXX" and you can report that one back to me here. Once it's over you can reset your git tree back to normal with
Code:
git bisect reset

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

Activity: 2576
Merit: 1110


Ruu \o/


View Profile WWW
November 09, 2013, 08:58:45 PM
 #13435

I have two block erupters that are producing about a Ths for me.  That would be great if weren't a Ths of Hardware errors.  I have seen others report very high hash rates for BE's but I don't remember what the consensus was.  Is this a BE, Hub or CGMiner issue?  Any insight would be appreciated.
Sam
It normally takes a 335MH device ~12.8 seconds to check all nonces in a single work item. The BEs use the icarus protocol which means as soon as they find a result, they report it back and then stop working. This can happen anywhere between zero and 12.8 seconds. The driver then gives it more work and the cycle starts all over again. If you can imagine the device coming back with a "result" in say .1 second and does this every time, the driver probably thinks it's running at a terrahash. However if it's a wrong result most of the time, it's meaningless. The driver shouldn't really be reporting it back as 1TH then so it's a mistake in the calculation in the driver. Kano might want to chime in since he wrote most of the driver.
This happens when you use the timing option (short or long) and the documentation reference in FPGA-README is:

'short' or 'long' mode should only be used on a computer that has enough CPU available to run
cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
Any CPU delays while calculating the hash time will affect the result
'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
corrects itself

TL;DR - Don't use a timing option any more.

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

Activity: 2464
Merit: 1001


Think for yourself


View Profile
November 09, 2013, 09:01:08 PM
 #13436

I have two block erupters that are producing about a Ths for me.  That would be great if weren't a Ths of Hardware errors.  I have seen others report very high hash rates for BE's but I don't remember what the consensus was.  Is this a BE, Hub or CGMiner issue?  Any insight would be appreciated.
Sam
It normally takes a 335MH device ~12.8 seconds to check all nonces in a single work item. The BEs use the icarus protocol which means as soon as they find a result, they report it back and then stop working. This can happen anywhere between zero and 12.8 seconds. The driver then gives it more work and the cycle starts all over again. If you can imagine the device coming back with a "result" in say .1 second and does this every time, the driver probably thinks it's running at a terrahash. However if it's a wrong result most of the time, it's meaningless. The driver shouldn't really be reporting it back as 1TH then so it's a mistake in the calculation in the driver. Kano might want to chime in since he wrote most of the driver.
This happens when you use the timing option (short or long) and the documentation reference in FPGA-README is:

'short' or 'long' mode should only be used on a computer that has enough CPU available to run
cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
Any CPU delays while calculating the hash time will affect the result
'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
corrects itself

TL;DR - Don't use a timing option any more.

Hmm, I'm not using any timing options. I just use --usb BAS:0 in my Erupter instance so that it doesn't try to capture the Jalapeno.

I did find this earlier and it has seemed to resolve the behavior.

Thanks,
Sam

High hash with bfgm and a Pi is a sign of low current to the hubs.  With good current expect to see 333+/- 5

Thank you for this insight.  I believe you are 100%, or so, correct.

I have the new 49 Port hub and had it loaded with 47 Erupters and two Arctic Breeze fans.  Two BE's were showing over 1Ths with virtually no shares submitted.  After reading this part of your post I dropped it to 40 BE's and the two fans and it is finally stable.

Win7 64 bit.
CGMiner 3.7.2

Thanks again,
Sam

Edit: overnight I had two more BE's start reporting GHs range.  So I dropped my erupter count down to 35 on the 49 port hub.  So I'm not sure that the above has anything to do with my problem.

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

Activity: 2506
Merit: 1043


Linux since 1997 RedHat 4


View Profile
November 09, 2013, 09:06:38 PM
 #13437

... people must be pressing F5 lots on this forum Cheesy ...

Yes I was about to edit and add ...

If on the other hand it is indeed returning mostly rubbish results, it will affect the calculations of the hash rate also.
The good old saying: garbage in garbage out.
Yes the driver is not designed to correct the 'garbage in'

Aside: I do have a long standing TODO: comment in the code ...
https://github.com/ckolivas/cgminer/blob/master/driver-icarus.c#L1204
and the line after it.
But that is to do with timing mode also.

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!
georgeu2000
Jr. Member
*
Offline Offline

Activity: 35
Merit: 0


View Profile
November 10, 2013, 02:30:10 AM
 #13438

Hi,

I just started using CGMiner with 2 BFL 50GH units and BTC Guild. I have 2 questions:

1. Using Ubuntu and can only run using sudo cgminer. I changed the permissions on the USB devices, but that did not help. The USB ports work fine otherwise. Any ideas on how to fix this?

2. It stops after 8 hours, with a message about waiting for the pool. Is there a setting I need to change? What could cause this?

Thank you.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2576
Merit: 1110


Ruu \o/


View Profile WWW
November 10, 2013, 02:32:06 AM
 #13439

Hi,

I just started using CGMiner with 2 BFL 50GH units and BTC Guild. I have 2 questions:

1. Using Ubuntu and can only run using sudo cgminer. I changed the permissions on the USB devices, but that did not help. The USB ports work fine otherwise. Any ideas on how to fix this?

2. It stops after 8 hours, with a message about waiting for the pool. Is there a setting I need to change? What could cause this?

Thank you.
1.Read the readme about copying the udev rules file.
2. Upgrade to 3.7.2 since this is a bug in 3.6.6.

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

Activity: 2576
Merit: 1110


Ruu \o/


View Profile WWW
November 10, 2013, 10:25:34 AM
 #13440

I've finally bitten the bullet and killed off GPU mining from the code and it will not be in the release I'm about to post. I have given ample warning that this was coming for some time on this forum thread and IRC about this and its time has come. It's also worth noting that even GPU mining has been used lately for botnets so cgminer once again is being flagged inappropriately as malware or a virus by various "authorities". I have left a 3.7 branch on git that is based on the last code that support GPU, OpenCL and scrypt code for those who wish to use it, but it is basically unchanged in terms of its mining code for GPUs compared with 3.7.2 which will be the last official release with GPU support. You are most welcome to fork, maintain, extend etc. the existing code provided you abide by the GPLv3 copyright restrictions that cgminer is released under. I am making a conscious decision and taking a stance to only support bitcoin by doing this and will consider all discussions regarding alternative cryptocurrencies as offtopic from here on. It is absolutely clear that we are in a stage where only ASICs matter in mining bitcoin, and cgminer is moving with the rapidly changing landscape that is bitcoin mining.

On the other hand, I think it's time to remind people of a warning I put up on this very forum thread almost 1 year to date, as I seriously worry about the massive amounts of money people are pouring into bitcoin mining hardware without being completely informed of the fact that they're unlikely to ever recoup the costs of the hardware they're purchasing.

Yes I am most aware of the apparently hypocritical nature of only supporting ASIC mining for bitcoin and then saying it's a waste of money to do so. I believe this situation is transient for the next few months though and we need to ride it out as best we can for the future of bitcoin.

However, ASICs are a totally different ball game. They basically will redefine what mining means with bitcoin, where there is no point mining with anything else if any profit is to be made. They will make GPUs, and even FPGAs, look totally useless to mine with. 1 year from now, absolutely no one will be mining BTC on anything but ASICs, except for newbies to bitcoin mining, who will ask the obvious questions about GPU mining, and still even CPU mining.

I will sorely miss the "anyone can use their spare hardware to mine with" aspect to bitcoin mining. I honestly believe that is more true to the ideal of bitcoin, where everyone running a node was contributing to its security. However, what spare hardware people had has changed dramatically recently anyway as PCs are dramatically on the decline and people move to more portable devices with less CPU/GPU power in the form of tablets and phones etc. Alas the algorithm lends itself really well to ASIC based mining, meaning everything else will be a complete waste of time. Now while cgminer will continue to work on alternate cryptocurrencies, I honestly think all the alternative cryptocurrencies will go nowhere. The only reason to mine them is to find something that can be profitable by converting it to BTC.

Down the track, cgminer will indeed be used mostly to mine with dedicated ASIC hardware to mine BTC. GPU mining for BTC will be as irrelevant then as CPU mining is today. I don't like the fact that the network will be secured with devices from 4 or 5 manufacturers making hardware that serves only one purpose - btc mining. While BTC mining previously was still only in the hands of intel, amd and nvidia, the fact is it was not on their radar at all. Bitcoin mining was a lucky aside they did, where AMD/ATI GPUs happened to do better than anyone else, and anyone with spare cycles on their hardware could choose to contribute and earn a little on the side.

Long term, cgminer will be the lowest overhead c software to drive ASICs to do bitcoin mining, with lots of code in it that is no longer relevant to BTC mining. What I really worry about, is that new hardware will continue to come out frequently enough that people end up on a cycle of investing in hardware that basically never pays itself off as slightly newer hardware and higher diffs keep coming out. Sure at some stage the limits of technology will be reached, but given the best tech at the moment is going to be 65nm ASICs when CPUs are 28nm devices, I can see the cycle going on for some time, and then even if btc mining ASICs end up in line with CPU manufacturers, they still continue to evolve over time. Dramatic profits from ASICs will likely only last a couple of weeks at most for a lucky few. The rest of you who paid for devices that don't even exist yet will not be making any magical profit no matter how big the hashrate appears. Your proportion of the total bitcoin hashrate will remain pitiful.

Sigh...

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 ... 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 715 716 717 718 719 720 721 722 ... 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!