Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 128. (Read 1193368 times)

& doesn't help, it would still terminate after you logged out.  You would need to use nohup to keep it running the background. So:

nohup &

But screen is much easier to work with than a backgrounded process and allows you to reconnect to your bfgminer console session at will.

You can use an ampersand after the command to make it execute in a background process.  You may need to redirect stdin and/or stdout to allow ssh to exit cleanly, depending on exactly how you start BFGMiner.

If you have a script that starts BFGMiner with your favorite arguments, you could do this:

% ./bfg_miner_script /dev/null &

screen bash
run your bfgminer command
CTL-A d to disconnect
logout
screen -r to reconnect when you log back in

Stupid linux-noob question here.  How do I run bfgminer so it doesn't stop mining when I log out? 

I want to be able to SSH in to my linux box, run BFGMiner, and log out and have it run on.  Currently when I do, an close my SSH session, the miner stops.

The LittleFury is what I was talking about.  

The author of the "other" miner says that you MUST run the BitFury chips off a RPi.  Herp Derp. 

This error is completely impossible with BFGMiner.
I would suspect it is due to cgminer's attempt to reinvent their own non-standard drivers.

If it doesn't work with BFGMiner, using the official FTDI drivers (ie, NOT winusb/zadig), please post the error you get.

Your video is inverted in both dimensions btw O.o

No mining chips support USB themselves. USB devices require an additional controller chip.
RPi-based Bitfury devices (Metabank and c-scape) are using SPI and GPIO to communicate directly to the chip(s).
There is also the LittleFury, which has a MCU that does (among other things) USB interfacing - this should work on any USB system.

Note that the code for handling BitFury is still immature, and I plan to rewrite a lot of it before merging it into mainline for BFGMiner 3.3.

I get this error, both in cgminer and BFGminer for my 30gh/s Little SC:


BitForceSC detected (5:1) invalid s-link count: '--DEVICES IN CHAIN: 00x00'


Here's a vid: https://www.dropbox.com/s/y5adr1ae4okzilk/VID-20130910-WA0004.mp4


Can anyone point me to a solution?

Luke-Jr, have you heard anything about the BitFury USB miners?  Someone says they need to be plugged in to a RPi, which sounds like bollocks to me.  USB is USB is USB...and the Pi has a shitty USB implementation if we're being fair to it.

Surely it's just a case of drivers?

I would recommend -S bfl:all if it is the only USB miner hooked up to the box

And windows com ports need to be of the form \\.\COMx where x is the number

I'm trying to set up my friends new 60gh bfl unit remotely. It connects fine to the pool  but I don't get any accepted, rejected shares. No HW errors either. I've tried it on two of his pc's. A windows 7 and a windows 8. The speed just sits at zero. I tried easyminer as well. Anyone seen something similar or have time to login and try to fix it? The only thing else out of the ordinary is a device that was showing up like another miner, called MMQ. I had to use -s COM4 so it would stop picking up the other device. He said there was nothing else hooked to the pc though.

There are many variables in play here, hardware and software; I don't have the tools necessary to determine the root cause and there's little point in speculating. If some software crashes once in a blue moon I don't worry about it much. Especially when it can be easily mitigated.

The reason I say that it isn't the machine (hardware), is that (1) I have 4 different machines on which I have encountered bfgminer crashes and (2) enough other people have reported crashes. It has happened often enough in the past that I have sometimes watched the crash first-hand as it happened. On those occasions there was always a network/pool issue associated with it: either my pool (bitminter) crashed, or my wireless went down. Luke and I have worked together to debug some of these crashes in the past with some success.

The quoted batch file is for Windows machines. Do you run Windows as well, or Linux? Anecdotally it seems that bfgminer is more stable running on Linux. My understanding is that bfgminer is developed on Linux and has been 'ported' to Windows; it isn't what would be normally considered a 'native' Windows app. And I run Windows.

The machine is 100% stable, Epoch explained it well

Thx again for the loop

I registered at butterflylabs forums only to say thank you, couldnt pm before 5 posts though really helped me out as non coder

Huh, odd that I've never had bfgminer crash, ever, in about a year of mining.     That's on home-built machines (Asus boards), or on OEM Asus PC. 

Maybe your machines aren't as stable as you think?

Yes, in an ideal world you *should* only need to run bfgminer once. But the fact is that it does crash. And the machine isn't the cause. Having said that, version 3.2.0 is one of the more stable releases and I'm quite happy with it.

Snakee isn't the only one with the crashing problem. That's why programs like cgwatcher and akbash exist; to restart the mining software if something goes wrong. The batch file snakee quotes actually comes from me. I have 4 separate machines running BFL Singles in various configurations; all 4 have experienced bfgminer crashes at one time or another. Sometimes it would happen within a day or two; other times it could take a week or two. I can't say for sure if I've experienced a crash with 3.2.0 yet, but I haven't been running it all that long. From what I have seen with past versions the crashes seem to be related to network or pool problems.

I use that batch file myself; it is cheap insurance. If bfgminer does crash when I'm not around to notice, it will automatically restart it for me and I don't lose any mining time. That is, of course, if you have your Windows Error Reporting deactivated so that 'crash dialog' doesn't pop up asking you to 'click ok'. In fact I wouldn't even know if bfgminer crashed unless I look at its uptime display.

If you need that loop batch file, then you've got something wrong with your machine.  You should only need to run bfg once.

tried to download with win 64 mirror @ 3.2.0 wont work,  win 32 does

and maybe this is helpful for some non coders

to minimize downtime i found a loop for the batchfile, looks like this

cd bfgminer-3.2.0-win32
:loop
bfgminer ^
-o http://stratum.btcguild.com:3333 -u snakee_1 -p xxx ^
--disable-gpu ^
-S erupter:all --icarus-options 115200:1:1 --icarus-timing 3.0=100
waitfor /t 10 dummy
goto loop


works great for me, i hope i typed everything correct now

My BFGMiner config is set to connect to gbt.mining.eligius.st:9337, but it always falls back to stratum.  I don't think it matters a whole lot, but I am curious as to why this might be.

No, Eligius doesn't honour --request-diff except as a default for new GBT clients.
(although I am working on an upgrade for the Eloipool software to improve this)

I'm running BFGMiner 3.2.0 against the Eligius pool. I have just reached enough hashing power where I think I could benefit from raising the difficulty of work units handed out by the pool. I have gone and told Eligius to hand out a minimum difficulty of 2.0 work units. I have run for a while and the work units continue to be difficulty of 1.0. So I decided to try the '--request-diff 2.0' argument. However, the pool is still handing out difficulty 1.0 work units.

Since BFGMiner is the recommended for Eligius I'm surprised that neither methods are working.

Is this a bug in BFGMiner?