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

[Luke-Jr]

So what you saying is, GBT solo installation would be easier to deploy but in terms of actually solving a block, GBT would not give me any extra edge over my current stratum setup, right?

Correct.

[Luke-Jr]

cgminer just released a fix for BFL SC that was causing crashes, new version 3.4.2 would this be the same fix bfgminer needs to fix the crashes I have been having with BFL Little SC's from 3.2.0??

Nope, there's no common code there, and BFGMiner 3.2 doesn't have the many bugs that were added in cgminer 3.4.1.
If you can post a crash report (printed to debug log or, if none, the console), I can look into it.

[goozman96]

Is it possible to minimize BFGMiner to the tray?

[Taugeran]

Is it possible to minimize BFGMiner to the tray?

 to the tray, bfgminer by itself does not support this. im sure there are some watchdog apps that start an instance of bfgminer in windowless mode, that could be trayed

[af_newbie]

How to read the bandwidth numbers:

BW:[ 75/241 B/s]

75 bytes (blocks?) per 241 seconds?  This cannot be right.

I see [441/41 B/s] and [292/29 B/s] on my systems but I'm not sure what these numbers mean.

[Luke-Jr]

How to read the bandwidth numbers:

BW:[ 75/241 B/s]

75 bytes (blocks?) per 241 seconds?  This cannot be right.

I see [441/41 B/s] and [292/29 B/s] on my systems but I'm not sure what these numbers mean.

Received/sent, or download/upload.

[goozman96]

Are there any plans for a GUI?

[Taugeran]

Are there any plans for a GUI?

nope. he plans on keeping bfg as minimalistic as possible

edit: that is waht the API is there for. or shell wrapping

[Xer0]

Is it possible to compile the OpenWRT binaries smaller if restricting mining support only to Block Eupters?

[Luke-Jr]

Is it possible to compile the OpenWRT binaries smaller if restricting mining support only to Block Eupters?

Probably, but you may need to hack the openwrt Makefile.

[Xer0]

Is it possible to compile the OpenWRT binaries smaller if restricting mining support only to Block Eupters?

Probably, but you may need to hack the openwrt Makefile.

What do you use for Compiling?

I use the official Toolchain but it reports missing libncurses-dev on Debian 6
But it compiles fine if i make directly for my CPU instead of Cross-Compile

[Luke-Jr]

Is it possible to compile the OpenWRT binaries smaller if restricting mining support only to Block Eupters?

Probably, but you may need to hack the openwrt Makefile.

What do you use for Compiling?

I use the official Toolchain but it reports missing libncurses-dev on Debian 6
But it compiles fine if i make directly for my CPU instead of Cross-Compile

To build for OpenWrt, you need to use their Buildroot toolkit.

[Luke-Jr]

...
"if you run cgminer, it will corrupt the real driver (until re-plug or reboot), which is likely why it isn't working."
...

Sigh, that's FUD.

No it doesn't corrupt anything.

It simply switches off the kernel module so that I can do direct USB access to the device.

And doesn't release it when it quits. That leaves it in a bad/unusable state.
I did ask if you would fix this, if you recall...

[Luke-Jr]

So ... why the FUD in your README? (that's rhetorical)

I added this accurate explanation to README because it is a common problem experienced by people who have used cgminer.
I'm more than happy to remove it if you fix the problem itself.

[Xer0]

Is it possible to compile the OpenWRT binaries smaller if restricting mining support only to Block Eupters?

Probably, but you may need to hack the openwrt Makefile.

What do you use for Compiling?

I use the official Toolchain but it reports missing libncurses-dev on Debian 6
But it compiles fine if i make directly for my CPU instead of Cross-Compile

To build for OpenWrt, you need to use their Buildroot toolkit.

that's what i used...

[Taugeran]

Any idea if/when you'll be adding the getwork server to the Windows binaries?  No, I'm not prepared to compile myself (my head would explode trying).

The main problem here lies with libmicrohttpd, which doesn't really support Windows (some specific versions will build with a POSIX simulation layer, which itself only works on 32-bit).
So, someone would need to do one of these:

• Port libmicrohttpd to Windows proper.
• Fix PlibC to work on not only just 32-bit Windows.
• Port BFGMiner to support another HTTP server library (I'm not aware of any decent alternatives, unfortunately).

wizkid057 thought he might have time to look into these options.

Have a looksie at http://lists.gnu.org/archive/html/libmicrohttpd/2013-03/msg00007.html

Sounds like someone already patched plibc to work on x64 and add utf-8 support but his patch was ignored/forgotten.  At least he posted a git where it can be had.

[Luke-Jr]

Any idea if/when you'll be adding the getwork server to the Windows binaries?  No, I'm not prepared to compile myself (my head would explode trying).

The main problem here lies with libmicrohttpd, which doesn't really support Windows (some specific versions will build with a POSIX simulation layer, which itself only works on 32-bit).
So, someone would need to do one of these:

• Port libmicrohttpd to Windows proper.
• Fix PlibC to work on not only just 32-bit Windows.
• Port BFGMiner to support another HTTP server library (I'm not aware of any decent alternatives, unfortunately).

wizkid057 thought he might have time to look into these options.

Have a looksie at http://lists.gnu.org/archive/html/libmicrohttpd/2013-03/msg00007.html

Sounds like someone already patched plibc to work on x64 and add utf-8 support but his patch was ignored/forgotten.  At least he posted a git where it can be had.

Well, latest plibc git didn't compile for me, so

[Taugeran]

Was worth a shot. I may give it a go in a day or so. Out of town currently :/

[Luke-Jr]

Ok, I've figured out why I think people are reporting bad hashrates on Erupters with 3.2.0...

First, a summary: it's just your perception, it will take a few hours, at least, before the average hashrate displayed settles down.

This is due to the Erupter driver only reporting hash completion once every 12.8 seconds (the time it takes to find 1 share on average). During this time, the average is skewed because while the Erupter has been hashing, it hasn't reported its progress.

So for the first 12 seconds, the erupter has "completed" a total of zero hashes. So the average is 0 despite that it's been actually performing hashes the whole time.
For the next 12 nexts, it has "completed" 4 gigahashes (total, not per second), which are then divided across the 12 seconds (which gets an accurate 335 Mh/s average); but then across 13, 14, 15, etc seconds; by the time we get to 24 seconds, it's still using the same 4 gigahash "completed" number, so the average (of 4 Gh over 24 seconds) is 178 Mh/s.
Once the second 4 gigahash "completed" come back, now the total is up to 8 gigahash, and it once again shows the correct 335 Mh/s average. By 36 seconds, however, the same thing has happened again: we have 8 gigahash divided by 36 seconds now, which is only 238 Mh/s.

After a few hours, those last 12 seconds becomes less and less relevant, and your average should begin to settle on 335 Mh/s.

The reason this didn't affect 3.1 and earlier as much is that it was abandoning work when a share was found, thus cutting the 12 seconds down to 6 on average. Scanning the whole work is more or less the main thing responsible for reducing hardware errors in 3.2.

There are a few ways to fix this to get a usable average faster:

• Only count seconds for which completed hashes are known, when performing averages. This would change behaviour such that averages would not account for time a device is disabled or waiting on failover or other issues. Probably not a good idea IMO.
• Ignore the time after the last "hashes complete" report so long as a device is actively hashing. This is probably ideal, but I need to think what the best way to be sure the device is actively hashing reliably (shockingly enough, this isn't obvious yet internally).
• Upgrade the Icarus driver to the newer API so it can report progress more often. I need to do this eventually anyway, but there are some complex issues to handle on Windows when I do.

All of these solutions have potential to introduce new bugs, so I don't expect to implement them until 3.3 at the soonest.

Edit: Original post accidentally said 355 instead of 335.

[HellDiverUK]

I wouldn't fuss too much about it Luke-Jr - bfg still handles the Erupters WAY better than the "Other Miner".  So what if the figures jump around, the little sticks do their thing no matter what.