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

[kano]

are there somewhere nightly builds of cgminer for win?

On your computer if you make them

[1714301485]

1714301485

[FiatKiller]

Update... after a couple of reboots and trying another miner and reinstalling the usb driver - I actually got everything working in 3.2.2 together. Has been stable for an hour. see what happens.

[vapourminer]

are there somewhere nightly builds of cgminer for win?

check windows-build.txt in the cgminer folder.

kinda involved to initially install mingw32 and set it up for cgminer but once done compiling for windows from git only takes a couple of minutes.

[FiatKiller]

3.2.2 stable overnight with 10 block eruptors & a Jale7. Good job with reducing CPU usage. I can run 3D games no problem now compared to 3.1.1, so CPU usage is way down.  :-D  Total Hashrate ~13.5 G   Sending tips your way.

[Queenvio]

Hey guys, I have a questions :

I have cgminer 3.1.1 running on an Rusberry Pi .
What is the best way to update the cgminer to the last version?

Greetings

[BitMinerN8]

Hey guys, I have a questions :

I have cgminer 3.1.1 running on an Rusberry Pi .
What is the best way to update the cgminer to the last version?

Greetings

I have always found this to work, but I don't know what device(s) you're trying to support, this was from a while ago:
https://bitcointalk.org/index.php?topic=138921.msg1509722#msg1509722

But you can always grab Kano's compiled versions he makes:
https://bitcointalk.org/index.php?topic=28402.msg2490901#msg2490901

[kibblesnbits]

It is giving me the message--  BitForceSc detect (2:1) Warning unknown firmware 'FIRMWARE: 1.2:40x00'     
I did use zadig and changed the driver.

Got the same message, updated from git hub, recompiled, now it just hangs at "starting 3.2.2".  Using Debian.  Any solutions?

[kibblesnbits]

It is giving me the message--  BitForceSc detect (2:1) Warning unknown firmware 'FIRMWARE: 1.2:40x00'     
I did use zadig and changed the driver.

Got the same message, updated from git hub, recompiled, now it just hangs at "starting 3.2.2".  Using Debian.  Any solutions?

Disregard.  Fat fingered the port number on stratum.  Carry on. 

[-ck]

New release: version 3.3.0, 24th June 2013

ASIC device focused release. Minor version update due to new driver support for BFL SC singles, SC minirigs. Numerous other improvements for existing devices. We don't have those devices so all code for this has been done while working on remote hardware and working blindly. Hopefully kano and I will have singles (or doubles as I call them now) soon to ensure the best possible support for the hardware.

GPU owners should start getting used to the idea that at some stage in the future, GPU mining in cgminer will be deprecated the way it was for CPU mining. Since GPU mining is still just above the waterline profitable for BTC and remains profitable for altcoins at the moment, that time has not yet come. But it will.

USB3 hubs continue to be problematic with USB devices for reasons that are still unclear. Since the devices in question that are problematic are all usb1.1, if you were looking to purchase a hub and use cgminer as your primary mining platform, please go with a USB2 hub instead. The problem only manifests with multiple usb1.1 devices on the USB3 hub (i.e. all icarus based devices). If you wish to use multiple devices on a USB3 hub and cgminer, version 3.1.1 which uses the old driver model works best.

I should point out that besides USB3 hubs, these newer direct USB code versions of cgminer are STABLE for all other devices, operating systems and hardware combinations we have access to. This does not include ztex and cairnsmore since we are coding blind for those devices.

Again: Cgminer uses direct USB on all USB devices, so to work on linux you must set your permissions (Instructions in ASIC/FPGA README) and on windows you must install a WinUSB driver (Instructions in ASIC/FPGA README)
 

Human readable changelog:

- Device support for BFL SC singles and minirigs. Assumed to support little singles, but unknown at this stage.
- Support for the newer firmware in BFL devices and that people are flashing to their devices.
- Numerous improvements to the reliability of USB communications should lead to less lost work, less restarts, and fixes for stale files that prevented devices starting without a reboot, along with more reliable shutdown.
- Significant increase in the hashrate on Avalons, fixing the regression introduced on the 3.2 series, along with more reliability.
- New speeds supported on avalon of 325, 350 and 375; 350 seems the sweet spot for many devices.
- New PID-like fan control for Avalons designed to maintain an ~constant temperature instead of using a static fanspeed to temperature ratio, along with the ability to set the target temperature with --avalon-temp.
- Quieter console output with most of the hw errors no longer showing as regular logging since some hw errors on USB devices are routine, not exceptional.
- More fixes to cope with variations in BFL SC device firmware, including very slow to respond ones.
- Prevention of the hashmeter showing 0 for some devices intermittently along with other hashrate display fixes.
- Fixed the block solve detection on big endian hardware (eg Avalon).
- Updated API for ASIC devices.
- New api-example.py courtesy of Setkeh
- No crashing on resizing when hotplugging devices on windows - simple workaround by not trying to resize windows since pdcurses on windows is buggy.
- Display the difficulty as an integer when it is one with stratum.
- Less chance of devices inappropriately being reported as SICK when pools go down.


Full changelog:

- Add an --avalon-temp option to allow a user specified target temperature.
- Demote no matching work message to verbose logging only on avalon.
- Make the fan control on the avalon a simple PID controller with a target
temperature of 45.
- Demote bflsc hw error messages to verbose logging only.
- bflsc - handle xlink timeouts by having generic IO functions
- Demote the invalid nonce warning to log info.
- Ignore iManufacturer for BFLSC devices since the device name will still match
and some unbinned chips are missing it.
- sc_count shouldn't be +1 in bflsc.
- Use the info timeout for read_nl in getidentify bflsc.
- Add a usb_read_nl_timeout macro.
- bflsc try getinfo twice
- set MSG_ASCUSBNODEV always defined
- Hard code the preferred packet size for AMU, BLT and ICA.
- API V1.26 update ASIC support
- Icarus enable the read buffer for the detect nonce
- Support new overclocking speeds for avalon: 325, 350 and 375
- undo icarus show errno, put it as debug in ubsutils
- icarus add errno to rerr and werr
- Sleep after sending icarus work to emulate working at 115200 baud.
- Use the nusleep function for sleeping after sending work in avalon.
- Show an integer only for diff if it is one.
- Set the avalon preferred packet size to 512.
- Reinstate the maxPacketSize determined by the end descriptor but allow the
driver to override it.
- Only update hashmeter if we have done hashes or haven't updated longer than
the log interval, fixing a us/ms error.
- Use only one cgsem in avalon signalling when the write thread should commit
work by reading the status bytes off during an avalon_read, minimising the
number of usb calls and resetting from only one place.
- Change avalon no valid work message to no matching work to match API
terminology.
- Use low latency usb transfers on the avalon, sleeping up to half a buffer's
worth only if no data is returning to increase hashrate, abolish lost work and
decrease CPU.
- Minimise the sleep times in avalon read to avoid result loss.
- Use a half nonce range before cycling through avalon's scanwork to ensure it
gets a chance to fill work if time is tight for the write thread to signal a
wakeup.
- Temporarily limit usb transfer sizes to 512 till we provide a way for each
driver to choose the upper limit.
- Increase watchdog sick time to longer than it takes for a pool to be detected
dead.
- Limit USB transfers to the max size reported by the descriptors.
- Increase the BFLSC timeout to allow the maximum number of results to be
returned for BAS in time.
- Decrease BAL and BAS latency to be just larger than one result read.
- disable curses device resize that crashes on windows
- BFLSC latest firmware has its own thermal cutoff set to 90, so use the same
value in case we have an old firmware that isn't throttling by itself.
- Drop watermark low limits for bflsc.
- Set the fanspeed on bflsc to max if we don't know the temperature.
- Use a low watermark for queueing mandatory work on bflsc instead of zero.
- Only mandatorily grab the bflsc mutex on submitting work when the queue is
empty.
- Adjust bflsc v2 watermarks.
- Only increase sleep time on bflsc if the queue isn't emptying at all over the
sleep duration.
- Fix warning.
- bflsc yet more API stats
- bflsc add some more API stats
- bflsc correct firmware matching
- bflsc correct comment
- Fixed Commands with No params
- bflsc driver support for v2 firmware
- Odd Issues
- Fixed Python Example
- Added Python Api Example
- Added Python Api Example
- Multiplier fail for microseconds vs milliseconds when updating hashmeter in
hash_queued_work.
- Only make threads report in/out across the actual driver code and update their
status on reporting out as well as in.
- usbutils initialise close key/sem
- usbutils cleanup linux semaphores on release
- Difficulty should be unconditionally byteswapped, not swapped to big endian.
- We should be setting cancelstate, not canceltype when disabling it for usb
locking.
- Pthread cancel state should be set to disable on usb DEVLOCK.
- Fanauto on bflsc is Z9X according to the source code, not 5 as per the draft
protocol document.

[crazyates]

New release: version 3.3.0, 24th June 2013

Thanks for all your hard work!

[kano]

3.3.0a
3.3.0 recompiled on 64 bit Fedora18, 64 bit xubuntu 11.04 and also on the RPi 32 (2012-12-16-wheezy-raspbian and rpi-update)

https://github.com/kanoi/cgminer-binaries

To get the 64 bit xubuntu 11.04 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Ubuntu_11.04_x86_64/cgminer-3.3.0a
chmod +x cgminer-3.3.0a
md5sum cgminer-3.3.0a
bbabc0f5d047b8b91656719dd2f796f9  cgminer-3.3.0a
(this version should also work on Fedora 16 and Fedora 17)

To get the RPi 32bit binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/RPi_32/cgminer-3.3.0a
chmod +x cgminer-3.3.0a
md5sum cgminer-3.3.0a
6d3dad50604e26fff44316b01ac52419  cgminer-3.3.0a

To get the Fedora 18 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Fedora18_x86_64/cgminer-3.3.0a
chmod +x cgminer-3.3.0a
md5sum cgminer-3.3.0a
6b7e23ea8012618b236db3a4456d99c6  cgminer-3.3.0a

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
On xubuntu 11.04 - first get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

I've run all three binaries for 3.5hrs without any problems so far, with 1x6950, 1xJalapeno, 1xAMU, 1xBLT, 1xBFL, 1xICA, 1xMMQ (Total ~8.6GH/s)

All have been built with -g
The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has core dumps enabled, it will dump a much more useful debug core.

Otherwise, the same configure options as ckolivas' binary version for 64 bit xubuntu 11.04
In case anyone was wondering:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon --enable-scrypt
make clean
make

All USBs (only) for the RPi 32bit version
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon
make clean
make
You will need to install libusb-1.0.0

All USBs (only) for the Fedora18 x86_64 version
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon
make clean
make
You will need to install libusb-1.0.0


Note I have binary folders of ckolivas official release files in my binaries git also, for if you can't get to his downloads
To get them you select the folder (e.g. 3.3.0) then click on the file you want then right-click save-as "View Raw"


Important: Read ASIC-README or FPGA-README about USB configuration on linux and windows

[andrewsg]

Can't wait to try it.

Quick question - I believe 3.3.2 had a note in the changelog about fixing cgminer from hanging on stratum disconnects. This still happened to me a few times after upgrading, is it a known issue, are others experiencing the same issue?

[-ck]

Can't wait to try it.

Quick question - I believe 3.3.2 had a note in the changelog about fixing cgminer from hanging on stratum disconnects. This still happened to me a few times after upgrading, is it a known issue, are others experiencing the same issue?

It's a known issue, for some versions of windows only, and if you had the problem in 3.2.2, you will still have it in 3.3.0 since I have not found a code reason for why it would happen.

[andrewsg]

Can't wait to try it.

Quick question - I believe 3.3.2 had a note in the changelog about fixing cgminer from hanging on stratum disconnects. This still happened to me a few times after upgrading, is it a known issue, are others experiencing the same issue?

It's a known issue, for some versions of windows only, and if you had the problem in 3.2.2, you will still have it in 3.3.0 since I have not found a code reason for why it would happen.

Thanks for the update! This happens to me on Windows 7 x64, I will have a go with different versions.

[-ck]

For Avalon users:

So I thought I'd make it easy for everyone to try the latest cgminer 3.3.0 and overclock settings all rolled into one, so here is a firmware with the overclock settings settable from the web interface:

http://ck.kolivas.org/apps/cgminer/avalon/20130624/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin

Note that I have donation settings in the configuration so if you do not use your own config settings, it will start mining for me until you change them.

Usual warnings apply with aggressive overclocking: do so at your own risk!

Enjoy 

[Subw]

I have a pool that rejects about 35-50% of my shares, i run load-balancing multipool config.
I run cgminer with --disable-rejecting swith but it does not disable bad pool:

cgminer version 3.3.0 - Started: [2013-06-25 03:39:26]
--------------------------------------------------------------------------------
 (1s):385.2M (avg):383.9Mh/s | A:15  R:11  HW:0  U:1.8/m  WU:4.9/m
 ST: 2  SS: 0  NB: 2  LW: 115  GF: 2  RF: 0
 Connected to multiple pools without LP
 Block: 00a3d71a4f419dc9...  Diff:19.3M  Started: [03:39:46]  Best share: 55
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [ S ]ettings [D]isplay options [Q]uit
 GPU 0:                | 384.3M/383.9Mh/s | A:15 R:11 HW:0 U:1.75/m I: 8
--------------------------------------------------------------------------------

 [2013-06-25 03:44:26] Pool 2 difficulty changed to 2
 [2013-06-25 03:44:31] Accepted ddb8d8b8 Diff 1/1 GPU 0 pool 1
 [2013-06-25 03:44:40] Accepted 3c8269c7 Diff 4/2 GPU 0 pool 0
 [2013-06-25 03:44:47] Accepted 6417bafe Diff 2/2 GPU 0 pool 0
 [2013-06-25 03:44:47] Accepted 0c7b0f0e Diff 20/1 GPU 0 pool 1
 [2013-06-25 03:44:48] Accepted fae749e0 Diff 1/1 GPU 0 pool 1
 [2013-06-25 03:44:56] Accepted 37bc0d55 Diff 4/2 GPU 0 pool 2
 [2013-06-25 03:44:56] Stratum from pool 2 requested work restart
 [2013-06-25 03:45:24] Rejected 324adb6e Diff 5/2 GPU 0 pool 2 ((20, u'unknown-work', None))
 [2013-06-25 03:45:25] Accepted 204e06e8 Diff 7/2 GPU 0 pool 0
 [2013-06-25 03:45:40] Rejected 74a16707 Diff 2/2 GPU 0 pool 2 ((20, u'unknown-work', None))
 [2013-06-25 03:45:57] Rejected 41228217 Diff 3/2 GPU 0 pool 2 ((20, u'unknown-work', None))
 [2013-06-25 03:46:14] Rejected 49256258 Diff 3/2 GPU 0 pool 2 ((20, u'unknown-work', None))
 [2013-06-25 03:46:16] Rejected 3612856b Diff 4/2 GPU 0 pool 2 ((20, u'unknown-work', None))
 [2013-06-25 03:46:48] Accepted 77f0404b Diff 2/1 GPU 0 pool 1
 [2013-06-25 03:47:48] Stratum connection to pool 2 interrupted
 [2013-06-25 03:47:48] Pool 2 difficulty changed to 2
 [2013-06-25 03:47:53] Accepted ea2cda0a Diff 1/1 GPU 0 pool 1

[Trongersoll]

awwww, come on, don't be quick to get rid of the GPU mining ability.

It may not be cost effective, may even lose money, but it is the only way for newbies to get involved and see what mining is all about. Telling future miners that they can't mine without buying special equipment(which most are predicting won't see ROI) isn't exactly great for Bitcoins future. Telling them that the can mine with the GPU in their current computer but will spend more on electricity than the make in Bitcoin will at least see the technical side of mining and decide about buying better equipment.

I'd think that the GPU code is pretty solid by now. Would it be so hard just to leave it in? or, make a separate GPU only build for beginners to use? I've just got one GPU working this week and there is a second in the box that i want to get going. I don't care if they make expensive Bitcoins, I just need the Bitcoins to buy more ASICS, and don't want to go through transferring money through exchanges. For me this is a hobby, not a business. I'm mining because i enjoy it.

[-ck]

awwww, come on, don't be quick to get rid of the GPU mining ability.

It may not be cost effective, may even lose money, but it is the only way for newbies to get involved and see what mining is all about. Telling future miners that they can't mine without buying special equipment(which most are predicting won't see ROI) isn't exactly great for Bitcoins future. Telling them that the can mine with the GPU in their current computer but will spend more on electricity than the make in Bitcoin will at least see the technical side of mining and decide about buying better equipment.

I'd think that the GPU code is pretty solid by now. Would it be so hard just to leave it in? or, make a separate GPU only build for beginners to use? I've just got one GPU working this week and there is a second in the box that i want to get going. I don't care if they make expensive Bitcoins, I just need the Bitcoins to buy more ASICS, and don't want to go through transferring money through exchanges. For me this is a hobby, not a business. I'm mining because i enjoy it.

Same arguments as CPU. This equation has been done before. I'm talking about a year or more from now, not very soon, but I do like to give plenty of warning.  When you're spending $300 a month in energy to earn $0.30 in BTC, you will see things differently, trust me.

[yantis]

Ckovivas -

Question for you (Cross post):

https://bitcointalk.org/index.php?topic=140539.msg2569627#msg2569627

[bicer]

Anyone seen below error before and perhaps knows what it relates to? I'm suspecting it's some kind of limitation on USB hubs (1a40:0101 Terminus Technology Inc.).

Code:

USB: AMU0 read1 buffering 252 extra bytes