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

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

[JLM]

Hi Luke!!!!

Could i mine SHA and scrypt AT SAME TIME?
SHA with Block Erupters and FPGA´s; Scrypt With GPU.
If possible?
What should do?

Thanks!!!

[Luke-Jr]

Hi Luke!!!!

Could i mine SHA and scrypt AT SAME TIME?
SHA with Block Erupters and FPGA´s; Scrypt With GPU.
If possible?
What should do?

Thanks!!!

No. It doesn't even make sense - there are no blockchains with multiple POWs.

[-Redacted-]

Hi Luke!!!!

Could i mine SHA and scrypt AT SAME TIME?
SHA with Block Erupters and FPGA´s; Scrypt With GPU.
If possible?
What should do?

Thanks!!!

Run multiple instances....

[PatMan]

OK, decided to try out bfg due to high cpu usage with my other mining program & need a little guidance compiling bfg for usb eruptors, getting this at the end of make log:

checking whether HASH_ITER is declared... no
configure: error: Could not find HASH_ITER - please install uthash-dev 1.9.2+
blahblah@btc:~/bfgminer$ make
make: *** No targets specified and no makefile found. Stop.

If I apt-get install uthash-dev 1.9.2+ thats over 1000mb's!!  Not gonna happen  

Where am I going wrong here?

..................

Anyone?

..................

[Taugeran]

OK, decided to try out bfg due to high cpu usage with my other mining program & need a little guidance compiling bfg for usb eruptors, getting this at the end of make log:

checking whether HASH_ITER is declared... no
configure: error: Could not find HASH_ITER - please install uthash-dev 1.9.2+
blahblah@btc:~/bfgminer$ make
make: *** No targets specified and no makefile found. Stop.

If I apt-get install uthash-dev 1.9.2+ thats over 1000mb's!!  Not gonna happen  

Where am I going wrong here?

..................

Anyone?

..................

im going to guess debian. the 1.9.7-1 uthash-dev package weighs in at ~400Kb so i think you may have either selected wrong package, have pending package installs, or misread apt-get output

[PatMan]

OK, decided to try out bfg due to high cpu usage with my other mining program & need a little guidance compiling bfg for usb eruptors, getting this at the end of make log:

checking whether HASH_ITER is declared... no
configure: error: Could not find HASH_ITER - please install uthash-dev 1.9.2+
blahblah@btc:~/bfgminer$ make
make: *** No targets specified and no makefile found. Stop.

If I apt-get install uthash-dev 1.9.2+ thats over 1000mb's!!  Not gonna happen 

Where am I going wrong here?

..................

Anyone?

..................

im going to guess debian. the 1.9.7-1 uthash-dev package weighs in at ~400Kb so i think you may have either selected wrong package, have pending package installs, or misread apt-get output

Close - Xubuntu 13.04 64bit - & the text was copy/pasted.....it's also listed in the dependency list on bfg git. Never used it before when compiling though......

[Luke-Jr]

uthash isn't even 1 MB.

[Luke-Jr]

A bunch of posts were accidentally split off to another thread

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

Is this error or is USB ASICminer really doing 355GH with your software? I thought 336 is theoretical max...

It's really doing 335 Mh/s for me at least (5½ day average):

Code:

 BES 0:       | 336.0/335.7/335.7Mh/s | A: 37464 R: 72+0(.19%) HW:202/.54%
 BES 1:       | 336.0/335.7/336.5Mh/s | A: 37564 R: 66+0(.18%) HW:191/.51%
 BEE 0:       | 327.5/335.8/333.1Mh/s | A: 37177 R: 60+0(.16%) HW:153/.41%
 BES 2:       | 336.0/335.7/330.5Mh/s | A: 36887 R: 71+0(.19%) HW:202/.54%

Any idea if/when you'll be adding the getwork server to the Windows binaries?

The main problem here lies with libmicrohttpd

Is this the same issue with the OpenWRT version?  I just picked up a little TP-Link pocket router to run my Block Erupters, but it'd be nice if it'd run the Blades as well.

No, OpenWrt has a native port of libmicrohttpd already, so it should be possible.
The problem there is that it's all or nothing: if I build with libmicrohttpd support, it won't be usable without it, and may increase the flash requirements.
I haven't taken the time to measure just how much yet... Maybe I can offer multiple alternative BFGMiner packages to get around this.

[Luke-Jr]

Is this the same issue with the OpenWRT version?  I just picked up a little TP-Link pocket router to run my Block Erupters, but it'd be nice if it'd run the Blades as well.

No, OpenWrt has a native port of libmicrohttpd already, so it should be possible.
The problem there is that it's all or nothing: if I build with libmicrohttpd support, it won't be usable without it, and may increase the flash requirements.
I haven't taken the time to measure just how much yet... Maybe I can offer multiple alternative BFGMiner packages to get around this.

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.

[Lucko]

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

Is this error or is USB ASICminer really doing 355GH with your software? I thought 336 is theoretical max...

It's really doing 335 Mh/s for me at least (5½ day average):

Code:

 BES 0:       | 336.0/335.7/335.7Mh/s | A: 37464 R: 72+0(.19%) HW:202/.54%
 BES 1:       | 336.0/335.7/336.5Mh/s | A: 37564 R: 66+0(.18%) HW:191/.51%
 BEE 0:       | 327.5/335.8/333.1Mh/s | A: 37177 R: 60+0(.16%) HW:153/.41%
 BES 2:       | 336.0/335.7/330.5Mh/s | A: 36887 R: 71+0(.19%) HW:202/.54%

OK I made a mistake with GH and you made a mistake with 355...

[Luke-Jr]

OK I made a mistake with GH and you made a mistake with 355...

Right, sorry, missed that distinction somehow. Fixed my original post.

[HellDiverUK]

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.

Yeah, I think running the system off a 4GB USB stick is probably a better idea.    Assuming there's no limitation in storage space, is there any other issues you can foresee?

I'm guessing most people running OpenWRT will be running it on bigger routers that have more flash.

[Luke-Jr]

Yeah, I think running the system off a 4GB USB stick is probably a better idea.    Assuming there's no limitation in storage space, is there any other issues you can foresee?

OpenWrt doesn't seem to handle external storage for applications too well

[JLM]

Hi Luke!!!!

Could i mine SHA and scrypt AT SAME TIME?
SHA with Block Erupters and FPGA´s; Scrypt With GPU.
If possible?
What should do?

Thanks!!!

Run multiple instances....

I had that idea, but i don´t know how.
Could you give a hand??

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