Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 153. (Read 5805670 times)

legendary
Activity: 1450
Merit: 1013
Cryptanalyst castrated by his government, 1952
Running 3.9.0 on two machines for a few hours now. One (very) minor issue - Some AMU devices are not getting recognized for several minutes after startup. The simplest example I had is 7 Eruptors on a single hub, with five recognized instantly and the other two automatically hotplugged about three minutes later. The issue seems to be replicable on both my machines - I imagine it could be exciting for 49-port hub users.



Just out of curiosity do you have

"--hotplug 60"

I do and that is my normal behavior.

No - I have no special settings at all in this version - just the pool identifiers. The behavior is new to 3.9.0 for me, I think. There have often been some AMU delays in previous versions, but only for a few seconds. Often I would get a delay on the machine that has a BAL unit, just after it was detected, but the rest of the AMUs would usually show up within seconds. I think Con has been tweaking delay times to keep AMUs from going zombie, so perhaps it's a side-effect from that.
legendary
Activity: 3583
Merit: 1094
Think for yourself
Running 3.9.0 on two machines for a few hours now. One (very) minor issue - Some AMU devices are not getting recognized for several minutes after startup. The simplest example I had is 7 Eruptors on a single hub, with five recognized instantly and the other two automatically hotplugged about three minutes later. The issue seems to be replicable on both my machines - I imagine it could be exciting for 49-port hub users.



Just out of curiosity do you have

"--hotplug 60"

I do and that is my normal behavior.
legendary
Activity: 1450
Merit: 1013
Cryptanalyst castrated by his government, 1952
Running 3.9.0 on two machines for a few hours now. One (very) minor issue - Some AMU devices are not getting recognized for several minutes after startup. The simplest example I had is 7 Eruptors on a single hub, with five recognized instantly and the other two automatically hotplugged about three minutes later. The issue seems to be replicable on both my machines - I imagine it could be exciting for 49-port hub users.

member
Activity: 109
Merit: 10
3.9.0 compiles and runs great on Mac.  My updated unofficial binaries for Mac OS X are here.

Happy holidays to all the cgminer devs Cheesy
hero member
Activity: 798
Merit: 1000
Direct.

There is a reason why we have spent a lot of time (Con most of the time for a while now) on working on libusb issues ...

If you use other software that uses libusb directly and doesn't deal with it properly you can expect problems.
. Wow nice!  I'll try it out later.  Thanks!!!
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Direct.

There is a reason why we have spent a lot of time (Con most of the time for a while now) on working on libusb issues ...

If you use other software that uses libusb directly and doesn't deal with it properly you can expect problems.
hero member
Activity: 798
Merit: 1000
Much appreciated! Can now have my Pi using both the Drillbit thumbs and the Block Erupter in the same instance of CGMiner without needing to run two separate versions for each. And it will put my mind at ease a bit when I plan to go on a roadtrip for a couple of weeks over east next month and won't be able to reboot it from there.
Yep my RPi with the thumb also has 2 AMUs - all 3 in a USB3 hub attached to the RPi with an Arctic USB fan on them ... though I've been stealing the mining fans for myself the last few days ... been hot down here ...

If you have any Drillbit boards (not thumbs) I've been told by the drillbit guys, and noticed (though it's probably already been said elsewhere) that if it has problems you simply leave it idle (on power) for a few minutes and then it's OK again.

Also make sure they have the latest firmware 20131217
http://drillbitsystem.com/forum/index.php?topic=235.0

How'd you get the USB3 hub working on the Pi? I thought they had "issues". Is it daisy chained through a usb2 hub? I have a bunch of unused AITech and Anker USB3 Hubs that could be put to good use with my Mining Pi's.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Much appreciated! Can now have my Pi using both the Drillbit thumbs and the Block Erupter in the same instance of CGMiner without needing to run two separate versions for each. And it will put my mind at ease a bit when I plan to go on a roadtrip for a couple of weeks over east next month and won't be able to reboot it from there.
Yep my RPi with the thumb also has 2 AMUs - all 3 in a USB3 hub attached to the RPi with an Arctic USB fan on them ... though I've been stealing the mining fans for myself the last few days ... been hot down here ...

If you have any Drillbit boards (not thumbs) I've been told by the drillbit guys, and noticed (though it's probably already been said elsewhere) that if it has problems you simply leave it idle (on power) for a few minutes and then it's OK again.

Also make sure they have the latest firmware 20131217
http://drillbitsystem.com/forum/index.php?topic=235.0
sr. member
Activity: 388
Merit: 250
Much appreciated! Can now have my Pi using both the Drillbit thumbs and the Block Erupter in the same instance of CGMiner without needing to run two separate versions for each. And it will put my mind at ease a bit when I plan to go on a roadtrip for a couple of weeks over east next month and won't be able to reboot it from there.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Thanks for the Drillbit Support!!!
ASIC-README hasn't been updated though with the --drillbit-options stuff... Sad
Ah well - I didn't spot they missed that Smiley
I'll update it in git shortly.
hero member
Activity: 798
Merit: 1000
Thanks for the Drillbit Support!!!
ASIC-README hasn't been updated though with the --drillbit-options stuff... Sad
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Been a while ... again Smiley

My cgminer-binaries git at github: https://github.com/kanoi/cgminer-binaries

3.9.0a/3.9.0bab 3.9.0 recompiled on:
Fedora 18
64 bit xubuntu 11.04 (should also work on Fedora 16 and 17)
RPi 32bit Arch
RPi 32bit Raspbian

3.9.0a includes the Drillbit Bitfury board and thumb driver

I did actually do a 3.8.5+ release yesterday but didn't announce it.

I've got this version running on ...
1 DRB board, 1 DRB Thumb, 2 BASs, 2 BAJs, 2 KLNs, 1 BTB, 2 AMUs.

So 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.9.0a
chmod +x cgminer-3.9.0a
mv cgminer-3.9.0a cgminer


The 5 others are:
https://github.com/kanoi/cgminer-binaries/raw/master/Fedora18_x86_64/cgminer-3.9.0a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Arch/cgminer-3.9.0a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Arch/cgminer-3.9.0bab
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Raspbian/cgminer-3.9.0a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Raspbian/cgminer-3.9.0bab

All 3.9.0a are all USB only:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-avalon --enable-bflsc --enable-bitforce --enable-bitfury --enable-drillbit --enable-hashfast --enable-icarus --enable-klondike --enable-modminer

All RPi 3.9.0bab are BlackArrow Bitfury GPIO and all USB:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-avalon --enable-bflsc --enable-bitforce --enable-bitfury --enable-drillbit --enable-hashfast --enable-icarus --enable-klondike --enable-modminer --enable-bab
If you only have BlackArrow Bitfury GPIO devices - i.e. no USB mining devices attached also - then you can add the command line option --usb :0 when you run cgminer and it won't look for any USB devices

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.

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.9.0) then click on the file you want then right-click save-as the "View Raw" link.

Important: Read README, ASIC-README or FPGA-README about USB configuration on linux and windows
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New version: 3.9.0, 23rd December 2013

New stable version that coincidentally includes a new driver, hence the updated minor version.


Human readable changelog:

- Driver for drillbit ASICs.
- Fixes for various KnC hardware errors, with improvements to hashrate. Note this is not a comprehensive fix for the hardware errors specific to rEligius - you will find a substantial drop in hardware errors if you start cgminer with the quiet and text only options (-q -T). An updated binary is here: http://ck.kolivas.org/apps/cgminer/kncminer/
- Updated bi*fury driver with support for the latest firmware. This includes dynamic clocking based on temperature which tries to maintain a constant temperature set intiially to 82 degrees but adjustable with --bxf-temp-target .
- Much more API output for bxf devices.
- Less spewing of errors when bxf devices are removed/die
- Updates to hashfast driver code
- Fixes for working with proxies that use small nonce2 sizes


Full changelog:

- drillbit asic - enable in api.c
- Fix trivial warnings in knc driver.
- Reinstate work utility based hashmeter for knc.
- drillbit format %z not valid on windows
- drillbit more formatting changes
- usbutils remove old code added back
- Memset the spi tx buffer under lock in knc driver.
- drillbit fix temp display to fit in standard space
- Drillbit formatting
- drillbit - use one drvlog and display dname before add_cgpu
- Keep orginal naming for the bitfury driver
- knc: Bugfix - good shares wrongly reported as HW errors.   Root cause of the
problem: several work items were assigned the same   work_id in the active works
queue of the knc driver. Thus when good   nonce report arrived from the FPGA,
wrong work item was picked up from   the queue, and submit_nonce evaluated that
as an error.   Fix: Limit the work_id counter update rate. Update it only to the
number of   works actually consumed by the FPGA, not to the number of works
send.
- Store per-chip submit information for bxf device and show them in the API.
- Check for removed bxf devices before trying to update work or send messages.
- api.c no decref if not json
- Minimise risk of nonce2 overflow with small nonce2 lengths by always encoding
the work little endian, and increasing the maximum size of nonce2 to 8 bytes.
- Change default hashfast timeout to 500ms.
- Ensure we can look up the work item in the hashfast driver or print out an
error if we don't.
- Drillbit source formatting - reindent and retabify
- Add ASIC count, temperature status to drillbit API output (closes #1)
- Many warning fixes
- knc: Do not include variable "last minute" data into the "last hour" per-core
stats
- knc: Make per-core statistics available through API
- Implement command line control of the bxf target temperature.
- Add a simple PID-like controller to bi*fury devices to dynamically alter the
clock setting to maintain a nominal target temperature set to 82 degrees.
- Add data to BXF API output.
- Add support for newer protocol bi*fury commands job, clock and hwerror,
setting clock to default 54 value, turning parsing into a compact macro.
- Look for the thermal overload flag in the gwq status message in the hashfast
driver and send it a shutdown followed by an attempted reset.
- Log message fixups
- Fix for "Timing out unresponsive ASIC" for pools which send early reconnect
requests, and then take a short time to send work (ie BTCGuild)
- Shorten initial config line, win32/pdcurses doesn't like long lines during
early logging
- Pull back the very long timeouts set in fe478953cf50
- Fix bug where work restart during results scan could lead to bad device state
- Align device status lines same regardless of number of temp status or >10
ASICs
- Tag log lines from brand new devices as DRB-1 until they are initialised
- Tag log lines as 'DRB0' rather than 'DRB 0', same as other places in cgminer
- Print a summary of the device settings at level NOTICE during initialisation
- Allow choosing device settings based on 'short' product names shown in status
line
- Allow per-device settings to use "DRBnn" as an identifier instead
- Issue an ASIC restart during a work_restart, removes spurious timeout messages
from ASICs and probably some rejected shares
- Check all results against all work instead of just taking the first match
(avoids some rejected submissions to the pool, ASIC can produce multiple
candidate results.)
- Fix memory leak caused by unnecesarily copied work
- Fix bug with find_settings not returning default value
- Set timeouts on write, set very long timeouts
- Merge drillbit driver
legendary
Activity: 1274
Merit: 1004
New release: Version 3.8.4, 1st December 2013
[skipped]
- Voltage displayed for BFL SC devices is the 2nd voltage which is allegedly more relevant.
[skipped]
- Use vcc2 in bflsc voltage displayed.

Dear Con Kolivas,

Could you explain what's the difference between vcc1 and vcc2?

It was previously 3.27V, but it's 1.00V now. Roll Eyes

Thanks.
vcc1 is the 3.3V rail that powers things like the ASIC IO, microcontroller, USB chip, etc. Except under fault conditions, it should always be 3.3V as it's not a highly stressed rail. It's basically a useless measurement; if you can read it it's probably working fine.
vcc2 is the main (80A+) voltage rail that feeds the ASICs. It is much more heavily loaded, and since the internal clock generator is powered off this rail the frequency that the chips run varies in almost direct proportion to the voltage on vcc2.
LZ
legendary
Activity: 1722
Merit: 1072
P2P Cryptocurrency
New release: Version 3.8.4, 1st December 2013
[skipped]
- Voltage displayed for BFL SC devices is the 2nd voltage which is allegedly more relevant.
[skipped]
- Use vcc2 in bflsc voltage displayed.

Dear Con Kolivas,

Could you explain what's the difference between vcc1 and vcc2?

It was previously 3.27V, but it's 1.00V now. Roll Eyes

Thanks.
newbie
Activity: 48
Merit: 0
I am happy to see that cgminer supports Bitmains U1: https://github.com/AntMiner/AntGen1/tree/master/cgminer

But I can't find the sources. I need a version running on raspberry. How could I get it?


I'll wait until they release the sources for close inspection.
hero member
Activity: 591
Merit: 500
Using cgminer to connect to bitminter.

Code:
[root cgminer-2.5.0]# ./cgminer -o http://mint.bitminter.com:80 -u doesnt -p matter
 [2013-12-22 21:17:21] Started cgminer 2.5.0                   
 [2013-12-22 21:17:21] Probing for an alive pool                   
 [2013-12-22 21:18:21] Pool 0 slow/down or URL or credentials invalid                   
 [2013-12-22 21:18:21] Unable to get work from pool 0 http://mint.bitminter.com:80                   
 [2013-12-22 21:18:21] No servers were found that could be used to get work from.                   
 [2013-12-22 21:18:21] Please check the details from the list below of the servers you have input                   
 [2013-12-22 21:18:21] Most likely you have input the wrong URL, forgotten to add a port, or have not set up workers                   
 [2013-12-22 21:18:21] Pool: 0  URL: http://mint.bitminter.com:80

Any ideas? I've tried the other ports listed for bitminter too, nothing.
Mate, 2.5.0 is ANCIENT. It won't connect to shit worth shit.

I need to use CPU for mining, I have machines that I'm paying for regardless and they don't have GPU's. How can I use cgminer to connect to bitminter and use CPU's?
BitMinter is experiencing connectivity issues right now. Also, don't CPU mine. It'd probably take you all day just to submit one difficulty 2 share.
member
Activity: 115
Merit: 10
I am happy to see that cgminer supports Bitmains U1: https://github.com/AntMiner/AntGen1/tree/master/cgminer

But I can't find the sources. I need a version running on raspberry. How could I get it?
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I need to use CPU for mining, I have machines that I'm paying for regardless and they don't have GPU's. How can I use cgminer to connect to bitminter and use CPU's?
Cgminer hasn't mined on CPUs in ages for a reason. You'll get no support for that here. It doesn't even mine on GPUs any more either. Feel free to do some research before asking why as well.
newbie
Activity: 7
Merit: 0
Using cgminer to connect to bitminter.

Code:
[root cgminer-2.5.0]# ./cgminer -o http://mint.bitminter.com:80 -u doesnt -p matter
 [2013-12-22 21:17:21] Started cgminer 2.5.0                   
 [2013-12-22 21:17:21] Probing for an alive pool                   
 [2013-12-22 21:18:21] Pool 0 slow/down or URL or credentials invalid                   
 [2013-12-22 21:18:21] Unable to get work from pool 0 http://mint.bitminter.com:80                   
 [2013-12-22 21:18:21] No servers were found that could be used to get work from.                   
 [2013-12-22 21:18:21] Please check the details from the list below of the servers you have input                   
 [2013-12-22 21:18:21] Most likely you have input the wrong URL, forgotten to add a port, or have not set up workers                   
 [2013-12-22 21:18:21] Pool: 0  URL: http://mint.bitminter.com:80

Any ideas? I've tried the other ports listed for bitminter too, nothing.
Mate, 2.5.0 is ANCIENT. It won't connect to shit worth shit.

I need to use CPU for mining, I have machines that I'm paying for regardless and they don't have GPU's. How can I use cgminer to connect to bitminter and use CPU's?
Jump to: