Same port for either proxy, 8332
Also if it matters: BFG is given -u worker.name -p pass and the blade is using worker.name2 same password.
I also tried them both being the same with no luck.
I would think that should work. BFGMiner doesn't care about the username or password the blade is using, as long as each blade has a unique username. Is it possible that the other proxy is not really releasing port 8332? I would think that BFGMiner would complain if it couldn't open the port, but I don't know what else might be wrong here. Maybe check Windows Firewall? |
|
|
|
all i see retard Luke is complaining for not receiving some free hardware (yes for development) As I said, I respect his decision not to provide one. This thread has absolutely nothing to do with that. Have you considered glasses? |
|
|
|
how difficult is it going the winUSB route? WinUSB is the wrong driverfor this device, so won't work at all with any standard programs. work division probably would not make a noticeable difference with 12 erupters. If you run 100 erupters then its worth it. Work division must be correct for it to mine properly. If it's failing to autodetect, there's likely a hardware problem (power, heat, etc). |
|
|
|
|
I don't consider it unethical to "judge" a bet based on evidence rather than emotion; as a matter of my personal opinion (ie, not an official bet judgement), much less!
|
|
|
|
That unit you "received" never left the building and you were not the "average" customer were you? I never said or implied otherwise. No one said you did. Did they? The ethical response should be that the bet was lost and to fully support that side. Where did you come down on the bet? Won or Lost? IMO, the bet terms were poorly defined, and satisfied by BFL handing over the unit to me. There may have been some room for legitimate interpretation contrary to my opinion (although IIRC the arguments for the "BFL didn't ship" side didn't really hold water), but the end result was that the moderator (who has the final call on interpretation of disputed bets) decided to call it a draw. As much as it might emotionally have made sense to support the "BFL didn't ship" side, things like this really need to be looked at from a strictly logical view. Some other betting site had more specific terms, and clearly had a "BFL didn't ship" outcome. I hope that eventually someone may make a betting site that does proper review of terms to ensure there's no room for different interpretations, but I haven't seen one so far. |
|
|
|
That unit you "received" never left the building and you were not the "average" customer were you? I never said or implied otherwise. |
|
|
|
When Luke Jr. asked for a BF1 I gave him the same speech. No I wouldn't ever think about putting a device in your hand due to your lack of integrity with the whole BFL fiasco. Open Source Software developers and Open Source projects in general need to remain neutral but these guys are not playing that way. CKolivas is neutral and we need more people like that. I wasn't going to say anything in public, but since you see fit to bring it up... While I respect your decision not to provide me with a device, I think you have some grossly inaccurate views of at least myself. It's true that I have been working with Butterfly Labs the longest, but that is a given considering they were the first to market with FPGAs. I think there are many people who can acknowledge that I have gone an extra mile in remaining vendor-neutral. The Bet. The only bet I've had any significant involvement in, was only because I was dragged into it because I posted about receiving my first SC device, nearly a year after having ordered it. I don't see how you can blame me because a bunch of people who lost a bet got upset that the website doing it called a draw. P.S. I don't really want to hijack your thread. Feel free to continue in PM, or ask a mod to split it to another thread if you prefer to keep it public-but-not-here. |
|
|
|
When Luke Jr. asked for a BF1 I gave him the same speech. No I wouldn't ever think about putting a device in your hand due to your lack of integrity with the whole BFL fiasco. Open Source Software developers and Open Source projects in general need to remain neutral but these guys are not playing that way. CKolivas is neutral and we need more people like that. I wasn't going to say anything in public, but since you see fit to bring it up... While I respect your decision not to provide me with a device, I think you have some grossly inaccurate views of at least myself. It's true that I have been working with Butterfly Labs the longest, but that is a given considering they were the first to market with FPGAs. I think there are many people who can acknowledge that I have gone an extra mile in remaining vendor-neutral. |
|
|
|
|
What does this have to do with the BF1?
|
|
|
|
Anyone care to donate a thumb and a board to Luke-Jr so we can get BFGMiner support too at some point? I will send boards to Luke Jr once we have them made.  ^ looks like I can confirm future Drillbit support for BFGMiner. |
|
|
|
Failed to init bfd from (C:\bfgminer321\pdcurses.dll)
0x66e43b50 : C:\bfgminer321\pdcurses.dll : wclrtoeol
Failed to init bfd from (C:\Windows\syswow64\msvcrt.dll)
0x763fa442 : C:\Windows\syswow64\msvcrt.dll : unlock
Failed to init bfd from (C:\Windows\syswow64\msvcrt.dll)
0x7640a490 : C:\Windows\syswow64\msvcrt.dll : getenv
Failed to init bfd from (C:\Windows\syswow64\msvcrt.dll)
0x7640a462 : C:\Windows\syswow64\msvcrt.dll : getenv
Failed to init bfd from (C:\bfgminer321\pdcurses.dll)
0x66e41408 : C:\bfgminer321\pdcurses.dll : waddch This doesn't make any sense, so I presume the stack must be corrupt somehow :/ Can you guys try out this special recompiled EXE? It has some stack protector stuff added, so hopefully will crash with more useful info... You might also need libssp-0.dll |
|
|
|
Thanks Luke.
That go me a step farther.
Now I got
configure: error: Could not find HASH_ITER - please install uthash-dev 1.9.2+
tried
install uthash-dev 1.9.2+
but, of course, that didn't work.
Don'cha just hate newbies
sudo aptitude install uthash-dev |
|
|
|
I'm hoping this will get me mining on the Pi with my ASIC.
I really appreciate the well written Guide. Even I could follow it.
With an exception...
I got to 6 ./autogen.sh
and got back...
Getting submodules...
fatal: Not a git repository (or any of the parent directories): .git
I did see the post from Phraust,
but don't understand what it means I should do.
Unfortunately, I don't speak Linux.
Someone please guide me a little.
Edit: forgot to mention - I'm using 2013-09-10-wheezy-raspbian and bfgminer-3.2.1
Skip autogen, it's not supposed to be used with zips. |
|
|
|
Ooh Bitfury code? Will that mean the Bitfury based Drillbit boards will be supported on BFGminer?
As of right now, I can confirm with testing that BFGMiner's dev branches support Littlefury and Metabank miners. The following Bitfury manufs have confirmed they will be providing a dev unit (my apologies if I missed anyone - PM me and I'll fix): - BigPictureMining (RedFury, BF1, and some other brands)
- BitCentury (Littlefury)
- Metabank
- MegaBigPower
Additionally, someone with a BFSB unit (not sure if official or a user) is providing patches to port to their boards. I've never heard of Drillbit before. If they send me a sample board, I'd be glad to ensure BFGMiner has full support for it. |
|
|
|
Looks like the same error that's making mine crap out, too.
Yeah, same as me I added the-T to see what was going on and it had an unexpected side effect I got my 2 boards working just about but it won`t work without the -T instruction. with it, everything hashes away real nice. Luke, any idea why this might happen? Ta. Will look into it later... buried deep in bitfury code atm |
|
|
|
Cheers for all the help, When I try to run I now get [2013-09-21 19:37:10] bfgminer.exe: --http-port: unrecognized option Cheers Then you're either using the Win64 version (not supported with http-port) or an older version than 3.2.1. |
|
|
|
|
Anyone know if there's a way I can bundle a PIF or such that tells Windows to never just close the console when it exits with non-zero status? :/
|
|
|
|
Hi, Was just looking for a basic setup guide. Noticed that it will not work on my 64bit machine  I take it there s no possible way to run this on 64bit ? Currently running the Stratum Proxy but keeps crashing on the clean_jobs=False causing all my blades to restart every 2mins How's everyone else running there blades ? Cheers If you have WoW64 (you probably do!), you can run Win32 applications with only minimal performance overhead. |
|
|
|
Ok, so I have more news on the 'ADDRESS' vs. 'ADDRESS_worker' issue.
It seems what happens is this:
a) If I funnel 4 blades through 1 stratum/getwork proxy server with 4 different user accounts *, I get the issue where they all stay at difficulty "1".
b) If I funnel 4 blades through 1 stratum/getwork proxy server with the same user account, they'll VARDIFF up to 16.
c) If I use 1 proxy server per blade under 1 user account, everything works fine, and they VARDIFF up to 4 or 8 within a few minutes. This is behaving exactly as I would expect. Stratum doesn't "really" support multiple users on a single connection: it uses the same jobs and difficulty for all of them. While the jobs are easily split up by your proxy, there is simply no way to express different difficulties per user/worker. Since Eloipool tracks difficulty per user/worker, it doesn't even try and always sends the (pool's) minimum difficulty if there are multiple users/workers on a connection. The only reasonable solution I can see to this problem, is to use the lowest difficulty of all users. * Actually, I've only tried different workers - don't know yet what will happen with multiple wallet addresses. I'll try that next. Eloipool doesn't know or care whether two usernames have the same address or not. |
|
|
|
As far as my difficulty display of "0" is concerned, it is actually 1. For small values of 1... Setting new difficulty: 0.999984741211
Setting new difficulty: 3.99993896484Ughm. Doing our floating point math on a Pentium, are we?  When it gets up to 8 however, it works: Setting new difficulty: 8Not sure if this is an Eligius bug or a mining_proxy bug. However, neither Slush nor BTCGuild shows a non-integer difficulty update on the same mining_proxy software. It's a "bug" in the stratum protocol, which use bdifficulty instead of pdifficulty. Pdifficulty 1 (standard for pools) is defined as a target with 32 leading zero bits. Bdifficulty 1 is the same, after being truncated in a 24+8 bit floating point format ("bits", also used in blocks). Eligius uses pdifficulty, since it can be stored cleanly in 4 bits instead of 32 (remember it needs to store the difficulty for every share). BFGMiner also consistently displays pdifficulty correctly. |
|
|
|
|
Show Posts
