Bitcoin Forum
December 11, 2016, 04:31:21 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 723 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4827807 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


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

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.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
1481430681
Hero Member
*
Offline Offline

Posts: 1481430681

View Profile Personal Message (Offline)

Ignore
1481430681
Reply with quote  #2

1481430681
Report to moderator
1481430681
Hero Member
*
Offline Offline

Posts: 1481430681

View Profile Personal Message (Offline)

Ignore
1481430681
Reply with quote  #2

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

Activity: 1918


Think for yourself


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

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

Activity: 1932


Linux since 1997 RedHat 4


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

... 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 BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
georgeu2000
Jr. Member
*
Offline Offline

Activity: 35


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

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: 2002


Ruu \o/


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

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.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


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

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.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 10, 2013, 10:44:24 AM
 #13447

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.


Human readable changelog:

- Remove all GPU code.
- Driver for Black Arrow Bitfury hardware (for use on RPi)
- Updates to make USB writes more reliable. Should help more on windows than anywhere else.
- Slight improvements to the blue and redfury drivers will decrease duplicates at startup, lost work across block changes, and will now show hardware errors - NOTE the hardware errors are not more than before, they simply weren't being reported before.
- Numerous tweaks to improve Avalon behaviour (possibly still problematic on wrt hardware but works better on PC).
- Fixes to prevent Avalons from hanging rarely on block change.
- Low level clean ups, bugfixes and preparation for more driver code.


Full changelog:

- api update version to 2.0 and remove GPU form API-README
- Remove now unused scrypt files.
- api.c remove all GPU/gpu references and correct code as required
- Rudimentary removal of GPU OpenCL and Scrypt features from api.c
- Reorder configure alphabetically for devices to compile and fail if no support
is selected to be compiled in.
- BaB update/format some comments
- BlackArrowBitfury early GPIO V1 driver
- Fine tune the reading of results in bitfury driver to not lose any across work
restarts or corrupt due to store results not parsed during restart.
- Send a zero length packet at the end of every usb transfer on windows in case
libusb internally has batched them into one maxpacket sized.

- Framework for ntime rolling, keep looking for OP_USB_INIT replies when other
packets received
- Configure source for a new BaB driver
- sha2 allow external access to some macros and the K array
- Fixed a math issue when reporting fan speed on the status line.
- Use the main hashlist to store work done in the bitfury driver and remove work
from the list by time, thereby fixing the duplicates at startup. Count hardware
errors for when no match occurs.
- Add a get and queue helper work function.
- Remove GPU mining code.
- Use libusb's own zero length packet support unless we have to emulate it on
windows since only libusb knows for sure if it's needed.
- Unlock the avalon qlock while sending tasks to not hold the lock for an
extended period.
- Sleep in avalon send task on return to the function to allow other code to
work during the sleep period.
- Send zero length packets when terminating a usb write aligned to
maxpacketsize.
- Do the driver flush in avalon code lockless since it can lead to deadlocks.
- Reset the work_restart bool after the scanwork loop in case the driver flushes
work synchronously.
- Only check for the stratum clean message if we have had a valid message.
- Get rid of the stage thread since all work can be asynchronously added now via
hash_push anyway.
- Remove the now incorrect faq entry regarding scrypt difficulty.
- Check for fatal read errors and break out of the read loop in avalon.
- Send errors are basically fatal in avalon driver so break out of the send
tasks loop.
- Make the avalon driver return -1 for hash count when usb fails, allowing the
main loop code to send it the shutdown flag.
- Break out of the hash work loops when a failure is detected instead of
dropping into mt disable.
- Use usbutils' own ftdi parser for avalon and the ftdir's own latency for
managing timeouts since we can wait on reads with completely asynchronous
reads+writes.
- Use usbutils' own cps function for slowing rate of usb writes on avalon.
- Fix build for no libcurl
- Check length before submitting sync transfers

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

Activity: 170


View Profile
November 10, 2013, 12:55:10 PM
 #13448

Much better than 3.7.2, it ran strong for 4 minutes before the usb errors this time.   Smiley

Don't know if you or anyone else is testing on avalon but wondering if you're seeing the same or if it's an issue with my tplink or controller.    Undecided

http://pastebin.com/bGQt7c38

aigeezer
Legendary
*
Offline Offline

Activity: 1281


Cryptanalyst castrated by his government, 1952


View Profile
November 10, 2013, 01:49:55 PM
 #13449

Hmmn, 3.8.0 won't work for me. Nothing initializes correctly and various error messages scroll by. The BFL unit fan stays at idle and the AMU LEDs stay on - no hashing by anything. I'll look more deeply when I get a chance - the problem may be on my end. Meanwhile, I'm back to 3.7.2 "ymmv" version, which is working well (3 day run before I took it down to try 3.8.0).

Of possible significance, I've done all my prior testing using the cgminer-nogpu executables so this is the first time I've run cgminer.exe directly.

SpaceCadet
Full Member
***
Offline Offline

Activity: 164


Just mining my own business...


View Profile
November 10, 2013, 04:38:15 PM
 #13450

3.8.0 doesn't return anything for me - I get:

[2013-11-10 09:31:14] FAIL: USB get_lock not found (4:1)
[2013-11-10 09:31:14] FAIL: USB remove not already in use (4:1)

I get this on both an win7 box and a win8 box on both usb2 and usb3 ports. (the 4:1 reference changes with the port used) I suspect it has to do with the usb driver (zadiag), but not sure.

3.7.2 does the same sometimes, though I haven't checked all combos of it yet.

Currently sticking with 3.6.5 for my BEs Sad

IYFTech
Hero Member
*****
Offline Offline

Activity: 686


WANTED: Active dev to fix & re-write p2pool in C


View Profile
November 10, 2013, 05:38:50 PM
 #13451

3.8.0. working fine for me on Xubuntu 12.04 64bit

Less HW errors too  Grin

-- Smiley  Thank you for smoking  Smiley --  If you paid VAT to dogie for items you should read this thread:  https://bitcointalk.org/index.php?topic=1018906.0
Sampey
Legendary
*
Offline Offline

Activity: 1288



View Profile
November 10, 2013, 06:02:44 PM
 #13452

Hi guys, i'm running CGMiner under Windows 7.
I have 1 Bitburner Fury and 6 USB Erupter
With command i must use to tell CGMiner to use Only Bitburner Fury or Only 6 Usb Erupter?

Thank you  Grin

os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
November 10, 2013, 06:06:20 PM
 #13453

Hi guys, i'm running CGMiner under Windows 7.
I have 1 Bitburner Fury and 6 USB Erupter
With command i must use to tell CGMiner to use Only Bitburner Fury or Only 6 Usb Erupter?

Thank you  Grin

To tell it not to use BE's use
"--usb ICA:0"

Read the advanced usb options in the readme for the proper name for the other device plus many more useful options.

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

Activity: 1288



View Profile
November 10, 2013, 06:09:18 PM
 #13454

Hi guys, i'm running CGMiner under Windows 7.
I have 1 Bitburner Fury and 6 USB Erupter
With command i must use to tell CGMiner to use Only Bitburner Fury or Only 6 Usb Erupter?

Thank you  Grin

To tell it not to use BE's use
"--usb ICA:0"

Read the advanced usb options in the readme for the proper name for the other device plus many more useful options.

But i want to tell "What To Use", no "To use what is in not in use".
When i plug the 6USB Erupter, CGMiner stops work if i'm working with the Bitburner.

os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
November 10, 2013, 06:12:13 PM
 #13455

New release: Version 3.8.0, 10th November 2013
in keeping with even number releases sounding more stable.

I can't remember the last time, if there was one, when I used .0 version for any length of time.

3.8.0 doesn't work for me either.  Here is the text from a Vista 32 bit machine

Code:
cgminer version 3.8.0 - Started: [2013-11-10 11:27:12]
------------------------------------------------------------------------------
 (5s):0.000 (avg):0.000h/s | A:0  R:0  HW:0  WU:0.0/m
 ST: 11  SS: 0  NB: 1  LW: 0  GF: 0  RF: 0
 Connected to pit.deepbit.net diff 1 with LP as user xxx@xxx.xxx_erupter
 Block: 81e15399...  Diff:511M  Started: [11:27:11]  Best share: 0
------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
------------------------------------------------------------------------------

 [2013-11-10 11:27:04] Started cgminer 3.8.0
 [2013-11-10 11:27:07] AMU 0 SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-10 11:27:07] FAIL: USB get_lock not found (5:4)
 [2013-11-10 11:27:07] FAIL: USB remove not already in use (5:4)
 [2013-11-10 11:27:10] No devices detected!
 [2013-11-10 11:27:10] Waiting for USB hotplug devices or press q to quit
 [2013-11-10 11:27:10] Probing for an alive pool
 [2013-11-10 11:27:11] Pool 2 difficulty changed to 2
 [2013-11-10 11:27:11] Switching to pool 2 http://stratum.btcguild.com:3333 -
rst alive pool
 [2013-11-10 11:27:11] Network diff set to 511M
 [2013-11-10 11:27:11] Pool 1 http://pit.deepbit.net:8332 alive, testing stabi
ty
 [2013-11-10 11:27:11] Switching to pool 1 http://pit.deepbit.net:8332
 [2013-11-10 11:27:11] Long-polling activated for http://pit.deepbit.net:8332/
stenChannel
 [2013-11-10 11:27:13] Pool 0 slow/down or URL or credentials invalid

Had to reboot the machine to get 3.7.2 to work again.  I also rebooted the machine before trying 3.8.0.
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?
os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
November 10, 2013, 06:15:24 PM
 #13456

But i want to tell "What To Use", no "To use what is in not in use".
When i plug the 6USB Erupter, CGMiner stops work if i'm working with the Bitburner.

Well like my daddy always used to say "want in one hand and crap in the other and see what fills up first" Smiley

Check the advanced USB options and see if there is a --usb command that does it the way you want it to.  I tell my instances what I don't want them to use and how many of the devices that I do want them to use.

To tell it to use 6 BE's use
"--usb ICA:6,<furydrivernamehere>:1"

I don't know the bitburner interface type/drivername.

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

Activity: 1918


Think for yourself


View Profile
November 10, 2013, 06:28:33 PM
 #13457

... 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.

When you say "But that is to do with timing mode also." do you mean overriding the default timings?  Or that the default timings may be an issue as well?

I had two more BE's start reporting GHash rates overnight with 3.7.2.

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

Activity: 1288



View Profile
November 10, 2013, 06:38:57 PM
 #13458

But i want to tell "What To Use", no "To use what is in not in use".
When i plug the 6USB Erupter, CGMiner stops work if i'm working with the Bitburner.

Well like my daddy always used to say "want in one hand and crap in the other and see what fills up first" Smiley

Check the advanced USB options and see if there is a --usb command that does it the way you want it to.  I tell my instances what I don't want them to use and how many of the devices that I do want them to use.

To tell it to use 6 BE's use
"--usb ICA:6,<furydrivernamehere>:1"

I don't know the bitburner interface type/drivername.

Ok! Thank you so much.

nwoolls
Hero Member
*****
Offline Offline

Activity: 798


View Profile WWW
November 10, 2013, 07:57:07 PM
 #13459

I can't remember the last time, if there was one, when I used .0 version for any length of time.

3.8.0 doesn't work for me either.  Here is the text from a Vista 32 bit machine

Same results for me on a Windows 7 x64 machine. Same LibUSB timeout errors. cgminer doesn't detect any devices.

MultiMiner: Any Miner, Any Where, on Any Device |  MobileMiner: Monitor and manage your rigs from your browser or phone  |  Xgminer: Mine with popular miners on Mac OS X
btc: 1BmXY4ZZQh1iHSVre658gM1gPAEtDnq8rv  |  ltc: LP1SsHZTDexndkvRKsqAkXNsienPHwaMb5  |  hardware: nwoolls at gmail dot com
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 10, 2013, 08:13:47 PM
 #13460

Weee what a fun ride, not. Apologies to windows users.

Windows users having trouble try this binary instead please:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 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 723 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!