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

[os2sam]

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"

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.

[1714136482]

1714136482

[1714136482]

1714136482

[1714136482]

1714136482

[1714136482]

1714136482

[os2sam]

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

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.

[Sampey]

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"

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]

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.

[-ck]

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

[os2sam]

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

It's working on the Vista machine.

I'm in the process of rebooting the Win7 machine.  It takes a while.

[aigeezer]

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

It's working on the Vista machine.

I'm in the process of rebooting the Win7 machine.  It takes a while.

The new version is working for me so far, Win7, living dangerously without a reboot.

[-ck]

Thanks very much for your quick testing guys. Posting a hotfix 3.8.1 release for windows users. Linux/osx users should be unaffected.

[crazyates]

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)

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

BFL devices are now working, but my 2 BEs are not. Who really cares about 2 BE's anyways? I'm gonna keep 3.8. Thanks for the fix!

[crazyates]

Thanks very much for your quick testing guys. Posting a hotfix 3.8.1 release for windows users. Linux/osx users should be unaffected.

BFL devices are now working, but my 2 BEs are not. Who really cares about 2 BE's anyways? I'm gonna keep 3.8. Thanks for the fix!

Weird. Now 3.8.1 is working with my BEs. Well as I said, thanks for your hard work!

[os2sam]

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

[-ck]

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.

[kano]

For anyone who has a V1 BlackArrow Bitfury board - the latest cgminer 3.8.1 (3.8.0 also) has the RPi source for a driver now - consider it an early release since there are certain improvements I'll make to it that I've already sorted out what to do - in future versions - but it already runs with great performance.

The configure option is --enable-bab

It runs at 39.9GH/s valid shares with a bit under 10% HW errors above the 39.9GH/s on a standard board
i.e. if you were to also count bad nonces returned (which I prefer not to but I will mention in case anyone wishes to compare that number) it's returning 44GH/s of good+bad nonces.

I've run it with a single board on Raspbian to write and test it - it's based on the V1 initialisation of a single board.
I based the I/O code on the chainminer GPIO/SPI code as should be obvious for anyone who looks at my driver-bab.c and chainminer (as I also mention that at the top of driver-bab.c)

It's a bit CPU hungry so soon I'll be spending more effort on reducing that - 20% CPU with a single board - I've only tested with a single board.

It also doesn't tune the chip at all - so there is also assured performance improvement there - it runs at default settings at the moment.
That's the next effort I'll expend on the driver.

If anyone has a standard V1 BitFury board I'd also be curious to know if it works with them.

[bitterdog]

Why is it I need to run Zadig to run CGminer and the Alpha driver for BFGminer and bitminter for the BF1

[-ck]

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.

[netvope]

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.

Thank you for keeping scrypt in cgminer for the past year

[OUTSIDE]

How update a 3.7.2 to 3.8 in a Rpi?

Have I to do all the process like new?

Thx!

[Eternity]

How much does this differ from bfgminer ?

[-ck]

How much does this differ from bfgminer ?

https://bitcointalk.org/index.php?topic=140237.msg1492775#msg1492775

[aigeezer]

Thanks very much for your quick testing guys. Posting a hotfix 3.8.1 release for windows users. Linux/osx users should be unaffected.

Gulp - 3.8.1 reported four zombies after an unattended run of about 11 hours.

Edit: Update - another four hour unattended run yielded five zombies. This is with the Windows 3.8.1 executable running on Win7 64. The machine had become pretty stable at around 3.7.2.

Edit: Update - a new six hour run (still going) with no zombies and no problems. Nothing changed.

Edit: Update - that run eventually went for 18 hours. Somewhere along the way it got two zombies. The recovery pattern was different from previous versions, fwiw. I unplugged the hub USB line and all AMUs reported zombie status, as expected. I replugged the line and none of them recovered. I'm pretty sure that the pre-3.8.1 versions would have recovered. However, it looked like the hash rates were starting to climb and that the units might in fact be recovering, just not reporting it. In any case, I used "Q" and a restart and everything looks normal again.