OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[disclaimer201]

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

[1714098009]

1714098009

[1714098009]

1714098009

[Sampey]

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]

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.

[kano]

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

[-ck]

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?  

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

[-ck]

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.

[os2sam]

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.

[kano]

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

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.

[georgeu2000]

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]

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.

[-ck]

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

[-ck]

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

[aneutronic]

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

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.   

http://pastebin.com/bGQt7c38

[aigeezer]

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]

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

[IYFTech]

3.8.0. working fine for me on Xubuntu 12.04 64bit

Less HW errors too 

[Sampey]

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 

[os2sam]

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 

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.

[Sampey]

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 

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]

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