Mac OS X Resources & Howtos for Mining (Homebrew/DIY/Bin/Xcode Debugging)

[jedimstr]

Thanks Nate!!!!! Building now!

[nwoolls]

Homebrew formulas, Shell scripts, and precompiled binaries have all been updated with cgminer 3.8.4.

[nwoolls]

Homebrew formulas, Shell scripts, and precompiled binaries have all been updated with bfgminer 3.8.0.

[nwoolls]

Homebrew formulas for bfgminer have been updated with Hashbuster2/Hashbuster Micro support.

[nwoolls]

Homebrew formulas, Shell scripts, and precompiled binaries have all been updated with bfgminer 3.8.1.

[nwoolls]

Homebrew formulas, Shell scripts, and precompiled binaries have all been updated with cgminer 3.8.5.

[nwoolls]

The original post has been updated with a new article:

How-to mine with HashBuster Micro

[nwoolls]

New repo and how-to coming soon for you Mac devs  :

[nwoolls]

The original post has been updated with a new article:

How-to mine with Bi•Fury

[nwoolls]

If you are an OS X user or developer and interested in contributing to bfgminer, I've put together a repository with an Xcode project and scripts that allow you to compile and debug bfgminer in Xcode. You can view the instructions and get started here:

https://github.com/nwoolls/xgminer-osx-dev

[nwoolls]

Homebrew formulas, Shell scripts, and precompiled binaries have all been updated with bfgminer 3.9.0.

[nwoolls]

The original post has been updated with a new article:

How-to mine with Twinfury

[shofty]

been reading your blog and noticed the link here, so wondered if i could ask a question

would you say the following results from a bi*fury left to run for 30 secondsish indicates an issue?

so this is a bi*fury, in a usb 3 slot on a new macbook pro, running bfgminer --HEAD installed by home-brew from your excellent instructions.

Code:

Summary of runtime statistics:
                    
 [2013-12-29 13:15:39] Started at [2013-12-29 13:13:51]                    
 [2013-12-29 13:15:39] Pool: http://pit.deepbit.net:8332                    
 [2013-12-29 13:15:39] Runtime: 0 hrs : 1 mins : 47 secs                    
 [2013-12-29 13:15:39] Average hashrate: 0.0 Megahash/s                    
 [2013-12-29 13:15:39] Solved blocks: 0                    
 [2013-12-29 13:15:39] Best share difficulty: 33                    
 [2013-12-29 13:15:39] Share submissions: 32                    
 [2013-12-29 13:15:39] Accepted shares: 32                    
 [2013-12-29 13:15:39] Rejected shares: 0 + 0 stale (0.00%)                    
 [2013-12-29 13:15:39] Accepted difficulty shares: 32                    
 [2013-12-29 13:15:39] Rejected difficulty shares: 0                    
 [2013-12-29 13:15:39] Hardware errors: 79                    
 [2013-12-29 13:15:39] Network transfer: 153.0 /  67.9 kB  (  1.5 /   0.7 kB/s)                    
 [2013-12-29 13:15:39] Efficiency (accepted shares * difficulty / 2 KB): 0.30                    
 [2013-12-29 13:15:39] Utility (accepted shares / min): 18.81/min
                    
 [2013-12-29 13:15:39] Unable to get work from server occasions: 0                    
 [2013-12-29 13:15:39] Work items generated locally: 0                    
 [2013-12-29 13:15:39] Submitting work remotely delay occasions: 0                    
 [2013-12-29 13:15:39] New blocks detected on network: 1
                    
 [2013-12-29 13:15:39] Summary of per device statistics:
                    
 [2013-12-29 13:15:39] BIF0 53.1C | 5s: 0.00 avg: 0.00 u: 1.27 Gh/s | A:32 R:0+0(none) HW:79/ 71%                    
 [2013-12-29 13:15:39] BIF0a 53.1C | 5s: 0.00 avg: 0.00 u: 1.27 Gh/s | A:32 R:0+0(none) HW:73/ 70%                    
 [2013-12-29 13:15:39] BIF0b 53.1C | 5s:  0.0 avg:  0.0 u:  0.0  h/s | A:0 R:0+0(none) HW:6/100%                    
 [2013-12-29 13:15:39]                      
Shutdown signal received.

if i read it right, one of the two chips isn't hashing, hardware errors of 100%. the other one has a pretty terrible return of 70%.

I know the temperature is sky high, was running it away from the fan briefly. I get very similar results from the device when i run it in an enclosure with a fan on it, on a ubuntu pc with latest bfgminer too. it did cause crashes in 3.8.0 every so often, segmentation faults. couldn't get it to run very long at all on the ubuntu box.

any thoughts?

[nwoolls]

Code:

          
 [2013-12-29 13:15:39] Summary of per device statistics:
                    
 [2013-12-29 13:15:39] BIF0 53.1C | 5s: 0.00 avg: 0.00 u: 1.27 Gh/s | A:32 R:0+0(none) HW:79/ 71%                    
 [2013-12-29 13:15:39] BIF0a 53.1C | 5s: 0.00 avg: 0.00 u: 1.27 Gh/s | A:32 R:0+0(none) HW:73/ 70%                    
 [2013-12-29 13:15:39] BIF0b 53.1C | 5s:  0.0 avg:  0.0 u:  0.0  h/s | A:0 R:0+0(none) HW:6/100%                    

if i read it right, one of the two chips isn't hashing, hardware errors of 100%. the other one has a pretty terrible return of 70%.

I know the temperature is sky high, was running it away from the fan briefly. I get very similar results from the device when i run it in an enclosure with a fan on it, on a ubuntu pc with latest bfgminer too. it did cause crashes in 3.8.0 every so often, segmentation faults. couldn't get it to run very long at all on the ubuntu box.

any thoughts?

I only have experience with a single Bi•Fury stick but I definitely didn't have any issues like that. I will say they seem to get very hot, so I would always have a fan on them while hashing (like a small USB fan). It does sound to me like you have a hardware problem (with the ASIC).

You may want to see if Felipeo can offer any advice:

https://bitcointalk.org/index.php?topic=309918.0

[hayseed]

I had used your brew tap formula before and had everything running with homebrew.

something has broke and I can't figure out what.

mining with mixture of blades and usb BE has been fine for 30+ days.

24+ hours ago blade mining broke with bfgminer. the PXY all show as SICK. I have tried on two different mac's with same result.

The mac's, blades, router are all in the same switch. I can ping the blades and configure them from the either mac.
I have powered everything off and back on.

I ripped out brew and reinstalled.

I noticed in the brew install of bfgminer

==> Installing bfgminer dependency: curl
==> Downloading http://curl.haxx.se/download/curl-7.34.0.tar.gz
Already downloaded: /Library/Caches/Homebrew/curl-7.34.0.tar.gz
==> ./configure --prefix=/usr/local/Cellar/curl/7.34.0
==> make install
==> Caveats
This formula is keg-only, so it was not symlinked into /usr/local.

Mac OS X already provides this software and installing another version in
parallel can cause all kinds of trouble.

Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:

    LDFLAGS:  -L/usr/local/opt/curl/lib
    CPPFLAGS: -I/usr/local/opt/curl/include

==> Summary
🍺  /usr/local/Cellar/curl/7.34.0: 75 files, 2.0M, built in 2.1 minutes


then noticed this in a debug log of bfgminer


[2014-01-01 16:30:57] No devices detected!
 [2014-01-01 16:30:57] Waiting for devices; press 'M+' to add, or 'Q' to quit
 [2014-01-01 16:30:57] Probing for an alive pool
 [2014-01-01 16:30:57] Testing pool stratum+tcp://mint.bitminter.com:443

===>>  [2014-01-01 16:30:57] HTTP request failed: Protocol stratum+tcp not supported or disabled in libcurl
 [2014-01-01 16:30:57] Failed to connect in json_rpc_call
 [2014-01-01 16:30:57] initiate_stratum with sockbuf=0x0

although with bfgminer running, I can open a web page to the ip of the mac localhost:8332 and get a login request then a work to solve

{"error":null,"result":{"target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000","data":"000000021357b4f4e1de19a52a54e5f2f406556706921cdc5793f5d6000000010000000082eb8f9 85bb972edb3cff59b05692cc0b2c9fb49a289533324bd3599253baa4552c4ae481903a30c000000 0000000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000","midstate":"a20eac8b68b458f89803a1b00b3c9a1f4972b05b660ff4312e964fc94cb85f6d","hash1":"0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000"},"id":0}

and if I leave out the --http-port 8332 I get no response to localhost:8332 so even though there are those error messages, it must be taking requests at 8332 ?

I even fired up a parallels windows 7 / installed win32 bfgminer and get the same results. i.e SICK for the blade now pointed to the parallels virtual running bfgminer (interface in bridge and firewall rule in windows to allow 8332)

Thanks for any assistance i this hair pulling session.

[nwoolls]

Thanks for any assistance i this hair pulling session.

If everything worked fine and now your Blade shows as SICK running in bfgminer on two different machines, odds are your Blade is the problem. Are you sure it's still functional? Have yo tried using other proxies like slush's or connecting directly to a GetWork pool?

[hayseed]

Thanks for any assistance i this hair pulling session.

If everything worked fine and now your Blade shows as SICK running in bfgminer on two different machines, odds are your Blade is the problem. Are you sure it's still functional? Have yo tried using other proxies like slush's or connecting directly to a GetWork pool?

I have pointed the blade to mint.bitminter.com and it hash's, not at full speed but it does hash.

There are 5 blades and 1 cube. All are having the issue. Blades have their own power seperate from the cube.

I also tried running the mining-proxy.py and they will not hash through it either.

I wanted to make sure that the error reported in the brew install and bfgminer were not it.

I have just changed a blade (.48) to point to mint.bitminter.com and in about 2 mins it is mining at 4.2ghs

It has to be a local problem. I wasnt sure at first as the days leading up both bitminter and btcguild were suffering ddos attacks

[hayseed]

Im making a mavericks virtual so I have a fresh sandbox to reinstall home-brew in and see what that results in.

[nwoolls]

I have pointed the blade to mint.bitminter.com and it hash's, not at full speed but it does hash.

There are 5 blades and 1 cube. All are having the issue. Blades have their own power seperate from the cube.

I also tried running the mining-proxy.py and they will not hash through it either.

I wanted to make sure that the error reported in the brew install and bfgminer were not it.

I have just changed a blade (.48) to point to mint.bitminter.com and in about 2 mins it is mining at 4.2ghs

It has to be a local problem. I wasnt sure at first as the days leading up both bitminter and btcguild were suffering ddos attacks

I know this probably isn't very helpful, but my own experience and 2-cents:

I have a single Blade v2 and a single Cube. I had no problem getting the Cube going through a proxy. The Blade, however, when I received it behaved more or less as you are describing. It would hash directly against a GetWork pool but at low speed. It refused to hash at all through a proxy. I banged my head against every option for a day.

The next morning it all worked fine. 

[hayseed]

I have have the same experience. I really had hoped it would all just "solve its self" the next day. I started with USB BE using the bitminter client, added a single blade pointed directly to bitminter. Sold off most BE at the right time that bought more blades. Didn't like the slow hash rates on the blades so got a stratum proxy running thanks to your articles and had it chugging away for about 30 days. even set it up on another computer just in case. Everything was all fine till yesterday 

My first thought was the sites were getting hammered as Doc had predicted that it occurs more often around the holidays.

Ill post back after the virtual is done and tested probably on the morrow

Happy New Year