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

[Taugeran]

Right click the upper left corner click defaults and change settings. Save close window

Restart. Should be in effect now min width and buffer I recommend is 81 characters

cheers

Thanks man.  Can you post an image of your qr code?  I wanna send you a tip.  Can't seem to log into my blockchain right now, but my phone works.

no need to tip. just being a helpful miner

[1714849471]

1714849471

[1714849471]

1714849471

[1714849471]

1714849471

[vesperwillow]

Trying to use BFG miner as a getwork proxy to see how it compares to other options. Can't get blades to connect.. must be doing something wrong. I read the documentation and all it says is to run with the --http-port option. Here's how I've tried it:

bfgminer -o url:port -u workername -p password --http-port xxxx

this loads up just fine. the blade is setup to point to the system running bfgminer. bfg never sees a connection. if i close bfg and load the other proxy, the blade connects. This is the win32 version.

What am I doing wrong?

[xyzzy099]

Trying to use BFG miner as a getwork proxy to see how it compares to other options. Can't get blades to connect.. must be doing something wrong. I read the documentation and all it says is to run with the --http-port option. Here's how I've tried it:

bfgminer -o url:port -u workername -p password --http-port xxxx

this loads up just fine. the blade is setup to point to the system running bfgminer. bfg never sees a connection. if i close bfg and load the other proxy, the blade connects. This is the win32 version.

What am I doing wrong?

Maybe a stupid question, but are the blades set to connect to the port you specified in '--http-port xxxx', or the default port for your other proxy?

[vesperwillow]

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.

[Luke-Jr]

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

[xyzzy099]

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.

[Luke-Jr]

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?

[vesperwillow]

I thought about the port release issue but verified that nothing was using the ports using netstat. The other proxy was on another machine entirely.

No firewall on the computer (makes testing easier)

However, I got it up and running by using another port entirely. Instead of 8332, I chose 8339. Now it's up and running. Going to let it stabalize and report its stats back.

I do find it curious that nothing is trying to use 8332 (or anything close) but that port just won't work. I'll try some other software on the port later and see if it's an issue regardless of software.

[Zanatos666]

I thought about the port release issue but verified that nothing was using the ports using netstat. The other proxy was on another machine entirely.

No firewall on the computer (makes testing easier)

However, I got it up and running by using another port entirely. Instead of 8332, I chose 8339. Now it's up and running. Going to let it stabalize and report its stats back.

I do find it curious that nothing is trying to use 8332 (or anything close) but that port just won't work. I'll try some other software on the port later and see if it's an issue regardless of software.

What about a firewall on your router (if you are using one)?  Would also be an issue with that blocking it, instead of a Windows firewall.

[vesperwillow]

What about a firewall on your router (if you are using one)?  Would also be an issue with that blocking it, instead of a Windows firewall.

Hardware WAN firewall doesn't affect lan-side equipment, and the devices are all connected between each other with switches anyhow.

Regarding the win32 crashes

I noticed that I was getting the connect-crash bug like some others. I haven't tried the special EXE yet which luke linked, I'll try that later. I didn't have all the failures the other guys did, mine only  had one issue loading pdcurses (I believe that was the name).

Things were running fine, I told another blade to connect, and it pooped BFG. I restarted BFG in the same process window and then both connected fine. I exited/restarted BFG and then had them both connect simultaneously, and then tried it again with them connecting one at a time--without issue.

Whatever it is, it seems to be constrained to the process window. Close the window and then try doing it, and it'll happen again but only once per blade.

Other than that, it's running very well. I'm going to do some more cgminer/bfgminer tests to see how I like it. Fast response from luke is always a huge plus.

[vesperwillow]

Related: Are there any reccomendations for a good linux build to run BFG solely for getwork proxy ? I use headless ubuntu 12.04 right now but libmicrohttpd-dev is old, and I was hoping to simply install a new distro than trying to duct-tape something together. Willing to do that if necessary though.

[vulgartrendkill]

All,

I'm currently using the -T command to make sure my blades and BE work ok (without it BFG crashes out).  While in this mode, BFG does not respond to any normal commands.

Is there a way to enable them?  I'd like to try out Load Balancing etc.

Thanks

[HellDiverUK]

Related: Are there any reccomendations for a good linux build to run BFG solely for getwork proxy ? I use headless ubuntu 12.04 right now but libmicrohttpd-dev is old, and I was hoping to simply install a new distro than trying to duct-tape something together. Willing to do that if necessary though.

Why not, you know, update libmicrohttpd-dev?    

It runs OK off Ubuntu 13.04 Server OK for me.

[JBT]

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

found it. not power issue. i ran the 3 problem eruptors on their own and got this message.  " ICA 0: Seems too slow to be an Icarus; calibrating with short timing" now all 12 are working

ed. also found if you stop start to many times i get this "Too many values passed to set temp cutoff"  a reboot fixes this but is there a quicker way to reset this?

[vulgartrendkill]

ed. also found if you stop start to many times i get this "Too many values passed to set temp cutoff"  a reboot fixes this but is there a quicker way to reset this?

Yeah, I had this issue also.  I went into my .conf file and removed all but 1 number in the temp cutoff part saved it as a .conf file and voila, no more error.  The USBs do not have temp sensors, so the input is useless.

[JBT]

ed. also found if you stop start to many times i get this "Too many values passed to set temp cutoff"  a reboot fixes this but is there a quicker way to reset this?

Yeah, I had this issue also.  I went into my .conf file and removed all but 1 number in the temp cutoff part saved it as a .conf file and voila, no more error.  The USBs do not have temp sensors, so the input is useless.

yup that worked

[JBT]

noticed some odd when i ran my 3 problem erupters with "C:\miner\bfgminer321\bfgminer.exe -o http://stratum.bitcoin.cz:3333 -u worker1 -p password1  -L log.txt -G -S \\.\com94 -L log94.txt --icarus-options 115200:1:1 --icarus-timing 3.0=100" they work ok until i run the other lot with "C:\miner\bfgminer321\bfgminer.exe -o http://stratum.bitcoin.cz:3333 -u worker1 -p password1 -Q 8 --net-delay -L log.txt -G -S erupter:all "


the first three just Stratum from pool 0 requested work update
now i know i am missing something here, any ideas?

[vesperwillow]

Related: Are there any reccomendations for a good linux build to run BFG solely for getwork proxy ? I use headless ubuntu 12.04 right now but libmicrohttpd-dev is old, and I was hoping to simply install a new distro than trying to duct-tape something together. Willing to do that if necessary though.

Why not, you know, update libmicrohttpd-dev?    

It runs OK off Ubuntu 13.04 Server OK for me.

Because the latest I could find for ubuntu was 0.9.3, unless it's super easy to take from another build of linux and toss it into 12.04. Would be interested to hearing how you did it.

[Mudbankkeith]

noticed some odd when i ran my 3 problem erupters with "C:\miner\bfgminer321\bfgminer.exe -o http://stratum.bitcoin.cz:3333 -u worker1 -p password1  -L log.txt -G -S \\.\com94 -L log94.txt --icarus-options 115200:1:1 --icarus-timing 3.0=100" they work ok until i run the other lot with "C:\miner\bfgminer321\bfgminer.exe -o http://stratum.bitcoin.cz:3333 -u worker1 -p password1 -Q 8 --net-delay -L log.txt -G -S erupter:all "


the first three just Stratum from pool 0 requested work update
now i know i am missing something here, any ideas?

Just a comment on directories.

If you place the "mine.bat" file in the same directory as "bfgminer.exe"
then you do not need the directory path:- C:\miner\bfgminer321\
Just use:-
"mine1.bat"   bfgminer.exe -o http://stratum.bitcoin.cz:3333 -u worker1 -p password1  -L log.txt -G -S \\.\com94 -L log94.txt --icarus-options 115200:1:1 --icarus-timing 3.0=100
"mine2.bat"   bfgminer.exe -o http://stratum.bitcoin.cz:3333 -u worker1 -p password1 -Q 8 --net-delay -L log.txt -G -S erupter:all "

You can then run the ".bat" file from its location, or "right click" it and send to desktop as shortcut once you have the file de-bugged.

keep it simple as long as you can, there are less places for bugs/typos to creep in.

[JBT]

Just a comment on directories.

If you place the "mine.bat" file in the same directory as "bfgminer.exe"
then you do not need the directory path:- C:\miner\bfgminer321\
Just use:-
"mine1.bat"   bfgminer.exe -o http://stratum.bitcoin.cz:3333 -u worker1 -p password1  -L log.txt -G -S \\.\com94 -L log94.txt --icarus-options 115200:1:1 --icarus-timing 3.0=100
"mine2.bat"   bfgminer.exe -o http://stratum.bitcoin.cz:3333 -u worker1 -p password1 -Q 8 --net-delay -L log.txt -G -S erupter:all "

You can then run the ".bat" file from its location, or "right click" it and send to desktop as shortcut once you have the file de-bugged.

keep it simple as long as you can, there are less places for bugs/typos to creep in.

yeah,i know that. point is that the 3 problem eruptors seem to get stuck on "Stratum from pool 0 requested work update" when i run the others either via batch files or bfg shortcuts either specifying each com port or via -S all