Why is it I need to run Zadig to run CGminer and the Alpha driver for BFGminer and bitminter for the BF1
We chose early on in our support of USB devices to talk directly to them via USB unlike all the other software out there. This means we deal with the Microsoft supplied WinUSB driver for any and all types of USB devices instead of using a separate 3rd party driver for every different device (eg ftdi_sio, sil, alpha etc). There are advantages to doing this in that it's much lower overhead and is more flexible in terms of what we can communicate with the device, but is more work for us to write the drivers to begin with, but then all operating systems end up using the same direct USB communications. Zadig is simply a tool that associates devices with whatever driver you choose (i.e. Zadig is NOT a driver) and happens to be the easiest way to associate the WinUSB driver with usb devices. Windows happens to be the only operating system that needs this sort of driver set up because on Linux and OSX we don't even use a driver to talk direct USB, bypassing the need for a driver entirely. |
|
|
|
|
Recommended cgminer for bluefuries is 3.8.1. However windows 8.1 I have heard has lots of problems with usb devices.
|
|
|
|
Since a new version came out before I was able to get my Win7 w/49 Port Hub rebooted, again, I went with the new version 3.8.1.
So far so good. One instance with 40 BE's and one with one Jalapeno.
Wonder if my 1 Ths BE's will recur again?
Thanks,
Sam
Thanks for quick testing. Unless the improved usb writes change helps indirectly, then nothing was done directly for that particular problem. |
|
|
|
|
I've put up a new version of cgminer, 3.8.1 with improvements to the blue/red fury devices.
|
|
|
|
|
Thanks very much for your quick testing guys. Posting a hotfix 3.8.1 release for windows users. Linux/osx users should be unaffected.
|
|
|
|
|
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
|
|
|
|
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...
|
|
|
|
Oh, I'm not worried about the HW errors.
I was just hoping to get the "2.2-2.7GH/s" that was advertised for this thing.
Alas software can only do so much  |
|
|
|
Just noticed that ckolivas commited a changeset a few hours ago with an update to the bitfury driver. Re-compiling from source, with those changes, made a difference in the numbers I was seeing in cgminer. Cgminer reported hash rate went from around 1.7-1.8Gh/s to around 2.2 - 2.5Gh/s.
I didn't think the changes would make such a difference, but there will be hardware errors reported now. Anyway in case someone cares to try it, here's an updated windows binary with the changes: http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exeI'm not on Windows so I can't try that - checked out what's on git right now and didn't seem to make much difference (except now I am getting HW errors). Before: BF1 0: | 2.089G/2.037Gh/s | A:1538 R:2 HW:0 WU:29.4/m After: BF1 0: | 1.991G/1.973Gh/s | A:273 R:0 HW:114 WU:27.7/m Anyone have any suggestions? It just wasn't reporting them before. Any difference there is purely luck related and the performance is, presumably, identical otherwise. I wasn't expecting performance advantages which is why I was surprised anyone noticed any. However there may be some usb devices out there that benefited from the flushing code I added, and they were previously performing really bad (1.3GH). 2-2.2GH seems about normal for these devices. Interesting how scary actually seeing hardware errors is - it's probably going to be enough for droves of people to go "Oh my god it now has hardware errors, I'm downgrading". I've seen the pattern enough by now  |
|
|
|
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. |
|
|
|
Hey I've got my red fury in the mail today. I tried and failed to get the bfgminer to work with them so i am trying with cgminer 3.7.2 . I have used the Zadig app to switch to the WINUSB driver on the BF1 but when I run CGminer-nogpu.exe it says it can't detect any devices. Any idea's on how to correct this?
USB3 slots can be problematic so try USB2 if you can, and sometimes you may need to reboot after changing the driver association to winusb. Also be 100% clear that you're doing the driver switch exactly as it says in the README file. |
|
|
|
Just noticed that ckolivas commited a changeset a few hours ago with an update to the bitfury driver. Re-compiling from source, with those changes, made a difference in the numbers I was seeing in cgminer. Cgminer reported hash rate went from around 1.7-1.8Gh/s to around 2.2 - 2.5Gh/s.
I didn't think the changes would make such a difference, but there will be hardware errors reported now. Anyway in case someone cares, here's an updated windows binary with the changes: http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exeSeems to be helping my numbers a bit, on two different ubuntu boxes. Recompiling now on a beagle-board xm... will post results after a soak in. Early Results from the beagleboard-xm Before After Well that looks quite significant then. It's probably a minor USB change I made to the code rather than a change to the bitfury driver itself. |
|
|
|
Just noticed that ckolivas commited a changeset a few hours ago with an update to the bitfury driver. Re-compiling from source, with those changes, made a difference in the numbers I was seeing in cgminer. Cgminer reported hash rate went from around 1.7-1.8Gh/s to around 2.2 - 2.5Gh/s.
I didn't think the changes would make such a difference, but there will be hardware errors reported now. Anyway in case someone cares to try it, here's an updated windows binary with the changes: http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe |
|
|
|
|
Ah apologies then, for I didn't know you were speaking about compiling it on windows. I agree, compiling cgminer for windows is bullshit as a result of it being primarily developed as a unix program.
|
|
|
|
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. |
|
|
|
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: 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 If it doesn't detect the devices or 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 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 |
|
|
|
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. |
|
|
|
|
Then just use cgminer? The performance is tied to the device, not the software...
|
|
|
|
|
Show Posts
