OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB

[Luke-Jr]

I was wondering how stratum pool distributes work to miners.  Does it split extranonce1,2 ranges among miners?
On the miner side, if you have 10 devices attached to one PC, is bfgminer splitting work and distributes ranges to individual devices.
And finally do devices split work to individual chips and engines?

Extranonce1 is assigned by the pool, unique to each connection.
Extranonce2 is what the miner is free to do whatever they want with.
BFGMiner currently just increments extranonce2 to create unique block headers for the drivers.

Someday ASICs might get fast enough that they need to do the their own header production, in which case drivers will be able to get a stratum-like job for them. Some devices are already in development to work this way, but it's a risky thing to do because it can negatively impact Bitcoin scalability if they have unreasonable limits on how quickly they can produce headers internally.

Is it better to have many miners or few more powerful miners.  Say in case of mini rig, would it be better to run 24 miners each 60GH/s or one 1440 GH/s miner?

A single 1.4 Th/s miner (eg, 3 minirigs) would make more sense.

Hmm.  If Extranonce1 is assigned by the pool, having more miners would distribute the work better as each miner would get its own version of Extranonce1, no?

Not sure I understand the question. Distributing the work "better" is useless - all that matters is that nobody overlaps.

So miner can create new merkleroots/work jobs as it iterates through Extranonce2.  Each new/generated work would need 1 sec@4GH/s to do a full nonce scan?

Correct.

16TH to do a full Extranonce2 scan?  And 256 PH to have any block solved in 1 second, by hashing all Extranonce1,2 and nonce all at once (assuming the miner can iterate through Extranonce1)?  Is that how it works?

Extranonces do not have fixed sizes. Either could be any length (including 0, although I suspect no miner actually supports this for extranonce2).

[noncecents]

On Windows it seems bfgminer doesn't know the difference between a problem with user access privileges and a device not responding/device sending back bad data due to a low power condition.

The error doesn't make sense on Windows since there's no user privileges restriction on non-storage USB devices.

I tested this by using a USB2.0 powered hub that doesn't provide enough power to operate Block Erupters and a USB3.0 hub that provides adequate power.

With the USB2.0 hub that did not provide enough power, when more than 2 block erupters were plugged in an error was reported by bfgminer on startup:

"Do not have user privileges required to open \\.\COMxx"

...where "xx" is a port number.

When I plugged the devices into a USB3.0 hub that provided adequate power for all the devices the error went away.

I was able to replicate this consistently by switching between the powered hubs.

This is an OS/driver issue. The message about user privs is shown when Windows reports ERROR_ACCESS_DENIED.

This is provably not a driver/OS issue.

If the same device is plugged into one hub it does not work and the error is presented. However, if it's unplugged and plugged into another hub it does work and the error is not presented.

If Windows is reporting ERROR_ACCESS_DENIED maybe Windows is reporting that error because of a problem that is different than the one you anticipated.

If you could anticipate every possible scenario there would never be bugs in your software and you'd be omnipotent.

[Luke-Jr]

If Windows is reporting ERROR_ACCESS_DENIED maybe Windows is reporting that error because of a problem that is different than the one you anticipated.

It's not a matter of anticipation.
ERROR_ACCESS_DENIED is defined as a permissions issue.
If Windows is returning it for a non-permissions problem, Windows (or a driver instructing Windows to do it) is at fault.

[af_newbie]

Hmm.  If Extranonce1 is assigned by the pool, having more miners would distribute the work better as each miner would get its own version of Extranonce1, no?

Not sure I understand the question. Distributing the work "better" is useless - all that matters is that nobody overlaps.

You are probably right.  It is like searching many haystacks (extranonce2) only 10%, instead of one at 80% before going to the next field of haystacks (new block).  Either way, finding that needle (hash) is a game of chance.

[HellDiverUK]

Just installed bfgminer on Ubuntu 13.04 Server.  I'm a linux n00b, so I think I've installed as per the README (I cloned off git, compiled, etc).

When I run bfgminer I get:

"bfgminer: error while loading shared libraries: libblmaker_jansson-0.1.so.0: cannot open shared object file: no such file or directory"

Err...help? 

[HellDiverUK]

Never mind, did a apt-get upgrade and all is working.

[Xer0]

I would be very keen to use this if you did.  I'm planning on using the TL-WR703N, which I think has 4MB flash and 32MB RAM. 

4 MB flash is too small for even the normal BFGMiner packages (or really any packages).
The only way I expect you'll be able to make this work is to build a custom firmware with BFGMiner included in the main image.
Whether libmicrohttpd could be squeezed into this or not, I'm not sure of.

nah, its much easier: "opkg -d ram" 

[Luke-Jr]

I would be very keen to use this if you did.  I'm planning on using the TL-WR703N, which I think has 4MB flash and 32MB RAM. 

4 MB flash is too small for even the normal BFGMiner packages (or really any packages).
The only way I expect you'll be able to make this work is to build a custom firmware with BFGMiner included in the main image.
Whether libmicrohttpd could be squeezed into this or not, I'm not sure of.

nah, its much easier: "opkg -d ram" 

Did you get this to work?
I tried for Avalon's TP-Link, and found this feature is pretty broken.

[Xer0]

working fine on a MR3020 with AA
Avalon's WR703N Firm is very limited

[HellDiverUK]

Avalons use the 703N?  Wow, that didn't occur to me. 

[drofdelm]

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?

[Luke-Jr]

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?

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)

[xyzzy099]

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.

[snakee]

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

[HellDiverUK]

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

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

[Epoch]

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

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

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.

[HellDiverUK]

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?

[snakee]

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

[Epoch]

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?

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.

[Beans]

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.