Bitcoin Forum
June 23, 2024, 08:04:43 AM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 ... 165 »
  Print  
Author Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB  (Read 1192980 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
September 03, 2013, 03:49:48 PM
 #681

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 (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
September 03, 2013, 07:57:09 PM
 #682

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
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
September 03, 2013, 10:22:47 PM
 #683

Is it possible to minimize BFGMiner to the tray?

BTC: 19DKtsdGfQyFzNiEze9KuFQrWGiLDvg6F1 | LTC: LbV6UGyjYbVP49NvQFmuAnkADcaFYvNagK | NMC: NDCdMJmTmGH54Cezmo3CwSxAC7grAoZJbj
Taugeran
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


CCNA: There i fixed the internet.


View Profile
September 03, 2013, 10:40:14 PM
 #684

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

Bitfury HW & Habañero : 1.625Th/s
tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1
Come join Coinbase
af_newbie
Legendary
*
Offline Offline

Activity: 2688
Merit: 1468



View Profile WWW
September 03, 2013, 10:43:35 PM
 #685

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 (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
September 03, 2013, 10:47:27 PM
 #686

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
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
September 03, 2013, 11:02:59 PM
 #687

Are there any plans for a GUI?

BTC: 19DKtsdGfQyFzNiEze9KuFQrWGiLDvg6F1 | LTC: LbV6UGyjYbVP49NvQFmuAnkADcaFYvNagK | NMC: NDCdMJmTmGH54Cezmo3CwSxAC7grAoZJbj
Taugeran
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


CCNA: There i fixed the internet.


View Profile
September 03, 2013, 11:13:24 PM
 #688

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

Bitfury HW & Habañero : 1.625Th/s
tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1
Come join Coinbase
Xer0
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000


°^°


View Profile
September 03, 2013, 11:23:42 PM
 #689

Is it possible to compile the OpenWRT binaries smaller if restricting mining support only to Block Eupters?
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
September 03, 2013, 11:26:32 PM
 #690

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
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000


°^°


View Profile
September 04, 2013, 12:30:49 PM
 #691

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 (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
September 04, 2013, 12:36:23 PM
 #692

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 (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
September 04, 2013, 01:54:19 PM
 #693

...
"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 (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
September 04, 2013, 02:16:53 PM
 #694

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
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000


°^°


View Profile
September 04, 2013, 02:42:18 PM
 #695

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
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


CCNA: There i fixed the internet.


View Profile
September 04, 2013, 05:03:11 PM
 #696

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.

Bitfury HW & Habañero : 1.625Th/s
tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1
Come join Coinbase
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
September 04, 2013, 05:12:40 PM
 #697

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 Sad

Taugeran
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


CCNA: There i fixed the internet.


View Profile
September 04, 2013, 05:20:55 PM
 #698

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

Bitfury HW & Habañero : 1.625Th/s
tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1
Come join Coinbase
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
September 04, 2013, 06:33:06 PM
Last edit: September 06, 2013, 12:59:04 PM by Luke-Jr
 #699

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. Smiley

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
Hero Member
*****
Offline Offline

Activity: 1246
Merit: 501



View Profile
September 05, 2013, 10:25:51 AM
 #700

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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 ... 165 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!