I went to check something on my mining rig and found that it was more sluggish than it should be. top revealed that bfgminer was using an inordinately large amount of memory: top - 09:06:31 up 8 days, 15:38, 1 user, load average: 1.57, 0.51, 0.22
Tasks: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.5%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 955744k total, 945944k used, 9800k free, 308k buffers
Swap: 2097148k total, 120000k used, 1977148k free, 10296k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26545 salfter 20 0 1179m 812m 3172 S 1 87.1 39:04.07 bfgminer
...
It had only been running a couple of days. I've had it running longer before, but this is the first time I've seen this problem: bfgminer version 2.8.0 - Started: [2012-10-02 09:16:12] - [ 1 day 23:50:28]
--------------------------------------------------------------------------------
5s:161.9 avg:133.6 u:135.5 Mh/s | A:5434 R:46 HW:0 E:240% U:1.9/m
TQ: 0 ST: 2 SS: 0 DW: 196 NB: 273 GW: 2267 LW: 11715 GF: 91 RF: 1
Connected to http://us1.eclipsemc.com:8337/ with LP as user salfter_lanbox
Block: 000005527d3997046e82f85edbb2cc94... Started: [09:06:35]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
OCL 0: 62.0C 39% | 100.1/133.6/135.5Mh/s | A:5434 R:46 HW:0 U: 1.89/m
--------------------------------------------------------------------------------
[2012-10-04 08:51:33] Accepted aa6cd27b.2bfb5b6c OCL 0 pool 0
[2012-10-04 08:52:41] Accepted 2e1a56fa.7e86004e OCL 0 pool 0
...
I restarted it, and performance returned to normal: top - 09:08:27 up 8 days, 15:40, 1 user, load average: 0.33, 0.42, 0.22
Tasks: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.5%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 955744k total, 241732k used, 714012k free, 6632k buffers
Swap: 2097148k total, 8216k used, 2088932k free, 86560k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18706 salfter 20 0 381m 53m 21m S 1 5.7 0:02.37 bfgminer
...
I haven't updated to 2.8.1 yet. On this machine, I'm GPU-mining with a Radeon 7750. |
|
|
|
...and it looks like BFL has committed to not test on mainnet: https://forums.butterflylabs.com/showthread.php/52-ASIC-Pre-Shipment-Testing-PolicyWe are often asked what our official policy is towards testing the ASIC equipment prior to shipping it to customers.
Our official policy is that we will burn in/test your equipment for a minimum of 24 hours on what is called "Testnet-in-a-box." This will allow us to verify that you equipment is working and able to sustain operations at normal operating conditions for a minimum of 24 hours.
Further down, there's something about testnet-in-a-box somehow not being fully up to the task of testing a TH/s-class device (bitcoind can't handle the throughput), but that they'd figure something out. Given that the 20 or so people who've ordered Mini Rigs could potentially have such a device banging away at their bitcoind instances when they arrive, what exactly does this mean for them? |
|
|
|
I've gotten Armory up and running without any issues on Gentoo, but thought I'd try adding it to SystemRescueCD to make a portable offline version that you can boot on any computer. I've documented the steps I used here, but have run into a snag. It tries to start, but throws these errors: ********************************************************************************
Loading Armory Engine:
Armory Version: 0.82.4
PyBtcWallet Version: 1.35
Detected Operating system: Linux
User home-directory : /root
Satoshi BTC directory : /root/.bitcoin/
Armory home dir : /root/.armory/
(CRITICAL) armoryengine.py:647 - C++ block utilities not available.
(CRITICAL) armoryengine.py:648 - Make sure that you have the
SWIG-compiled modules
(CRITICAL) armoryengine.py:649 - in the current directory (or added to
the PATH)
(CRITICAL) armoryengine.py:650 - Specifically, you need:
(CRITICAL) armoryengine.py:651 - CppBlockUtils.py and
(CRITICAL) armoryengine.py:653 - _CppBlockUtils.so
Error in sys.excepthook:
Traceback (most recent call last):
File "/root/BitcoinArmory/armoryengine.py", line 480, in
logexcept_override
strList = traceback.format_exception(type,value,tback)
AttributeError: 'NoneType' object has no attribute 'format_exception'
Original exception was:
Traceback (most recent call last):
File "ArmoryQt.py", line 41, in <module>
from armoryengine import *
File "/root/BitcoinArmory/armoryengine.py", line 643, in <module>
import CppBlockUtils as Cpp
File "/root/BitcoinArmory/CppBlockUtils.py", line 26, in <module>
_CppBlockUtils = swig_import_helper()
File "/root/BitcoinArmory/CppBlockUtils.py", line 22, in
swig_import_helper
_mod = imp.load_module('_CppBlockUtils', fp, pathname, description)
ImportError: /root/BitcoinArmory/_CppBlockUtils.so: undefined symbol:
_ZN8CryptoPP17AlignedDeallocateEPv
It looks like it's complaining that some files are missing, but they're not: total 16567
-rw-r--r-- 1 root root 6263 Oct 2 20:06 armorycolors.py
-rw-r--r-- 1 root root 367195 Oct 2 20:06 armoryengine.py
-rw-r--r-- 1 root root 267204 Oct 3 13:59 armoryengine.pyc
-rwxr-xr-x 1 root root 46073 Oct 2 20:06 armorymodels.py
-rw-r--r-- 1 root root 107210 Oct 2 20:06 ArmoryQt.py
-rw-r--r-- 1 root root 107893 Oct 2 20:15 CppBlockUtils.py
-rw-r--r-- 1 root root 193167 Oct 3 18:04 CppBlockUtils.pyc
-rwxr-xr-x 1 root root 10226922 Oct 2 20:43 _CppBlockUtils.so
drwxr-xr-x 4 root root 784 Oct 2 20:15 cppForSwig
-rw-r--r-- 1 root root 6882 Oct 2 20:06 createTxFromAddrList.py
-rw-r--r-- 1 root root 2772 Oct 2 20:06 cryptoTimings.txt
drwxr-xr-x 2 root root 203 Oct 2 20:06 dpkgfiles
drwxr-xr-x 2 root root 321 Oct 2 20:06 extras
drwxr-xr-x 2 root root 2747 Oct 2 20:06 img
-rw-r--r-- 1 root root 6721 Oct 2 20:06 imgList.xml
-rw-r--r-- 1 root root 1057 Oct 2 20:06 LICENSE
-rwxr-xr-x 1 root root 33711 Oct 2 20:06 LICENSE.py
-rw-r--r-- 1 root root 426 Oct 2 20:06 Makefile
-rw-r--r-- 1 root root 4989706 Oct 2 20:44 qrc_img_resources.py
-rw-r--r-- 1 root root 27199 Oct 2 20:06 qrcodenative.py
-rw-r--r-- 1 root root 10440 Oct 2 20:06 qt4reactor.py
-rw-r--r-- 1 root root 17104 Oct 2 20:06 qtdefines.py
-rwxr-xr-x 1 root root 417157 Oct 2 20:06 qtdialogs.py
-rwxr-xr-x 1 root root 33505 Oct 2 20:06 README
-rw-r--r-- 1 root root 186 Oct 2 20:06 setup.py
-rw-r--r-- 1 root root 79787 Oct 2 20:06 unittest.py
-rw-r--r-- 1 root root 4031 Oct 2 20:06 versions.txt
drwxr-xr-x 2 root root 149 Oct 2 20:06 windowsbuild
-rw-r--r-- 1 root root 2506 Oct 2 20:06 WindowsBuild.txt
Why would it do this? It looks like I'm 99% to where I want to be...how difficult will the remaining 1% turn out to be? |
|
|
|
UPDATE: (7 Apr 14) It's now working!NOTE: This should've worked, but I ran into a problem getting Armory working with the crypto++ library built within the SystemRescueCD image. I shifted gears a bit and put together a working system on top of the Gentoo Linux LiveDVD; go here to see how it's put together. I've long kept a copy of SystemRescueCD on an 8GB flashstick on my keychain; it's a handy tool for installing Gentoo on a new box (it's based on Gentoo), imaging systems, clearing Windows passwords, and a bunch of other stuff. I also have a TrueCrypt hidden volume on the aforementioned flashstick with my private keys (as PDFs generated by bitaddress.org); SystemRescueCD can access this. I took a look at Armory and figured it'd be a more secure way to manage keys than what bitcoind offers by itself. Instead of dedicating a computer to offline use, though, why not add Armory to SystemRescueCD? You can boot it fairly quickly on any computer when you need it. Keep your wallet in a TrueCrypt hidden volume and it should be safe from prying eyes, or even against getting lost. The directions for customizing SystemRescueCD are here: http://www.sysresccd.org/Sysresccd-manual-en_How_to_personalize_SystemRescueCdThese instructions assume you're working with SystemRescueCD 3.0, the most recent version. I won't rehash them here, but will go through the particular steps needed to get Armory working. Once you have SystemRescueCD unpacked to an image, mounted, chrooted, and have updated Portage (I just rsync /usr/portage from the nearest Gentoo box at hand), you'll want to do the following, which corresponds to step 4d: 1) Change some USE flags to build the components we need and not build components we don't: 2) Use Portage to update/rebuild these packages (we need a newer OpenSSL, and some X header files are missing): emerge -1 --nodeps dev-libs/openssl \
dev-lang/python \
x11-libs/xproto \
x11-libs/xtrans \
x11-libs/libXau \
x11-libs/libXext \
x11-proto/kbproto \
x11-proto/fixesproto \
x11-proto/renderproto \
x11-proto/randrproto \
x11-libs/libXrender \
x11-libs/libXfixes \
x11-libs/libXcursor \
x11-libs/libXrandr \
x11-libs/libX11 \
x11-libs/libXv \
x11-libs/libXi \
x11-libs/libICE \
x11-libs/libSM 3) Use Portage to install these Armory dependencies: emerge dev-libs/crypto++ \
dev-lang/swig \
dev-python/twisted \
dev-python/PyQt4 \
dev-vcs/git 4) Clone qt4reactor from GitHub, build, and install: git clone https://github.com/ghtdak/qtreactor && \
cd qtreactor && \
python setup.py build && \
python setup.py install 5) Clone Armory from GitHub and build: git clone https://github.com/etotheipi/BitcoinArmory && \
cd BitcoinArmory/cppForSwig && \
make swig With this done, you should now have a working ArmoryQt.py in /root/BitcoinArmory. While you're at it, you could also add other useful Bitcoin-related tools, like bitaddress.org, a QR-code generator, or vanitygen. (I have bitaddress.org and a QR-code generator combined into a couple of data: URLs here.) (Quick aside on vanitygen...this build is really simple: git clone https://github.com/samr7/vanitygen && cd vanitygen && make vanitygen && make keyconv && cp vanitygen keyconv /usr/bin Follow the "want to make vanity addresses for others" instructions here to securely generate vanity keys offline.) Continue with the instructions to produce the updated SystemRescueCD image, then go here for instructions on getting your image onto a flashstick.
|
|
|
|
Can't get the ocl version to work... on 7970: (seems it is finding matches, but disregarding due to mismatch? CPU hash: 6707a76e848f5e9368c2d9d9ec6d60880df44891
GPU hash: 020b0bda39a9bbb2eeddd194a8be20934835dff6
Found delta: 94027 Start delta: 1
I had the same thing happen with my 7750. IIRC, I got it working by passing the -S (safe mode) option to oclvanitygen. |
|
|
|
That's a USB 3.0 hub. Most computers are equipped with USB 2.0 ports. It should fall back to USB 2.0 data rates, but will it allow the increased power that USB 3.0 can deliver while it's plugged into a USB 2.0 port? When USB devices negotiate for the power they can obtain from the bus, does that negotiation run between the device and the computer (which will only allow up to 500 mA, because that's all it can deliver) or between the device and the hub? I think there's still an empty slot in my mining rig that could take a USB 3.0 card, if necessary...though with one of those, a hub wouldn't be necessary right away. The card I have in another machine has two external ports, which would support the two Jalapeņos I have on order by itself if I were to pick up another. |
|
|
|
PHP might be timing out. I can't say I'm 100% happy with the time it takes to run. I might need to find a faster way to do the recursive source verification. (I should probably set it to run against a bitcoind instance instead of Blockchain.info.) |
|
|
|
doesnt work with pools (EMC)
I switched to Eclipse after having a bit of a dry spell with P2Pool, which gave me some motivation to fix the script to work with other pools. It's a fair bit slower, but it works. If we were to assume that all input to a given address is from a pool, I could ditch the recursive search and speed things up considerably. Read the original post for details...it's been updated. |
|
|
|
It looks like you let the captcha expire.
After just the few seconds you have to wait to click submit? I wouldn't think so. (The screenshot was taken a bit after that...took a bit to find the KDE screenshot app.) Why does the Daily Bitcoins timer have 37 minutes on it then? Geez...I wasn't expecting the Spanish Inquisition. Maybe this sequence will make the problem more obvious: Waiting for the timer to count down:  Clicked the button and got this:  These were taken with Chrome on Windows, but it happens in every browser I've tried (Firefox, Chrome, Chromium, iCab Mobile) on every OS I have (Windows, Linux, iOS). |
|
|
|
It looks like you let the captcha expire.
After just the few seconds you have to wait to click submit? I wouldn't think so. (The screenshot was taken a bit after that...took a bit to find the KDE screenshot app.) |
|
|
|
Which captchas are broken fore you? They all work for me.
Tried it just now against Daily Bitcoins:  |
|
|
|
The new version seems to have a memory problem. I'm on a box with 32gb of ram and it will crash after 5-6 hours with a out of memory error, and run_p2pool.exe hogging it all.
FWIW, I have it (and bitcoind and cgminer) running on a box with 1 GB. I've only run into memory shortage issues when compiling newer versions of bitcoind. |
|
|
|
|
What's responsible for P2Pool's current run of bad luck? Currently, it's been 29 hours (and counting) since the pool last found a block. The last three blocks (excluding the orphan) also took longer than expected...in one case, more than 2.5x longer. Is this a sign of something going wrong, an indication of an anomaly with the larger Bitcoin network, or is it just some unusually bad luck that we're stuck riding out?
|
|
|
|
Nice website  doesnt work with pools (EMC) I kinda figured it wouldn't. That would require looking at all income to an address, not just generation income. If the source address for income from a given pool is constant, it might be feasible to filter on that. |
|
|
|
cool tool!!!! :-)
Thanks! Can you add another Graph?
e.e. Daily stats for a Week, not a full month ?
If someone mines not a full month around the clock, the average ist not correct..
The blue average line is generated by the graph package I'm using. There's an option to disable it, but I think the better approach to take is to know when you have bad data that will throw off the average. With mine, for instance, there's about a one-week interval before I first brought the 7750 online that I was off of P2Pool. That's depressing the averages, but will scroll out of view before long. A graph of the past week's activity wouldn't be much to add to it, though. |
|
|
|
|
Something changed to break the CAPTCHAs on most of the linked pages if you let them load in the frame below the header. If you right-click and select "open in another tab," they work properly. I thought it was just another bit of Chrome weirdness at first, but Firefox behaves the same way as well.
|
|
|
|
I knocked together a script to go through the transaction history for a given address, filter out the pool transactions, add them up, and chart them so you can more easily see what you're making: For P2Pool or solo mining, use this type of URL: http://alfter.us/income.php?addr=<your-bitcoin-address>For other pools, use this type of URL: http://alfter.us/income.php?addr=<your-bitcoin-address>&src=<pool-bitcoin-address>The second address is where your pool receives its generated coins; you can get this from blockchain.info by digging back through the transaction history for recently-mined coin. (For instance, Eclipse receives its generated coins at 1Baf75Ferj6A7AoN565gCQj9kGWbDMHfN9.) A recursive search is done on transactions on your address to filter out those which can be traced back to your pool. It's probably not perfect; for instance, coins sent to your address by someone else that originated at some point at the same pool will be counted. For a couple of examples, here's what I made with P2Pool: http://alfter.us/income.php?addr=1N6UPydscNkUAL6ab1XaJ9i1hTV17EFr67...and here's what I've gotten so far with Eclipse: http://alfter.us/income.php?addr=1NgYDzGuHrJUmRSocfScYgBuGwsuvBB9Kz&src=1Baf75Ferj6A7AoN565gCQj9kGWbDMHfN9&simple=trueIt will give you your total income to date (in BTC and $, the latter based on the current MtGox bid price) and graphs of the last 30 days' daily income and 30 weeks' weekly income. Source information is from BlockExplorer and Blockchain.info. P2Pool and solo-mining results will come up much more quickly than results for other pools, due to the aforementioned recursive search. Update: Since the recursive-search feature is so slow that PHP can time out, you might have better luck appending "&simple=true" to your mining-pool query to disable it. So long as the only income at that address is mining income (no change received back from a transaction, no income from other sources), the graph will still be an accurate indication of mining income. In this case, src can be any non-empty string. |
|
|
|
I'm interested in one account.
Thanks for your order, just send you a PM Received, sent, logged in, changed login credentials, and it's up and running like a champ.  |
|
|
|
|
Show Posts
