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

[Taugeran]

It looks like the 2 boards that are on the Eligius website- Gamastack & Patty aren't available yet, even if they were to accept these chips.

And the other one won't take these chips.

So it looks like I'm out of luck.

https://bitcointalk.org/index.php?topic=304250.0

just cropped up a day or two ago. has a fully hashing unit with cgminer bfl drivers. so in theory bfgminer could be swapped in

i also chuckled at his naming choice of chili (as they go spicier than jalapeños)



Edit: changed hotter to spicier as to not mislead on the temp profile of unit

[albon]

Will you be supporting the bluefurry usb's?

[Luke-Jr]

Will you be supporting the bluefurry usb's?

Should already work with -S bigpic:all on the bitfury branch.

[SpAcEDeViL]

Hy Luke-Jr,

i use now your bfgminer on my Pi.

But it dont restart "sick" or "dead" usb miners.

i start the miner with :

Code:

./bfgminer/bfgminer --config /home/pi/bfgminer.conf -S erupter:all --api-listen --api-network --force-dev-init --disable-gpu --scan-time 60 

in my bfgminer.conf :

Code:

{
"pools" : [
	{
		"url" : "*",
		"user" : "*",
		"pass" : "*",
		"pool-priority" : "1"
	},
	{
		"url" : "*",
		"user" : "*",
		"pass" : "*",
		"pool-priority" : "3"
	},
	{
		"url" : "*",
		"user" : "*",
		"pass" : "*",
		"pool-priority" : "2"
	},
	{
		"url" : "*",
		"user" : "*",
		"pass" : "*",
		"pool-priority" : "0"
	}
]
,
"temp-cutoff" : "95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95,95",
"temp-target" : "89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89,89",
"api-listen" : true,
"api-mcast-port" : "4028",
"api-network" : true,
"api-port" : "4028",
"expiry" : "120",
"expiry-lp" : "3600",
"failover-only" : true,
"gpu-dyninterval" : "7",
"log" : "5",
"no-pool-disable" : true,
"no-show-processors" : true,
"no-show-procs" : true,
"queue" : "5",
"scan-time" : "60",
"skip-security-checks" : "0",
"submit-stale" : true,
"temp-hysteresis" : "3",
"shares" : "0",
"load-balance" : true,
"kernel-path" : "/usr/local/share/bfgminer",
"icarus-options" : "115200:1:1",
"icarus-timing" : "3.0=100"
}

i dont know why the config write allways "temp-cutoff" and "temp-target" in this.

i hope you can help.

[DrGuns4Hands]

I had to give up on my raspberry pi because it couldn't handle the number of singles I was running on it. The USB support on the pi is rather weak and running more than a few units will likely cause this to happen. I built a AMD APU set up for about 180(mobo, cpu, and RAM using one of the Singles PSU's) and it's running perfectly for the past week. It uses a bit more power, but it will hardly be noticeable compared to the singles. The pi had good potential, just can't quite handle the load.

[village.idiot]

I had to give up on my raspberry pi because it couldn't handle the number of singles I was running on it. The USB support on the pi is rather weak and running more than a few units will likely cause this to happen. I built a AMD APU set up for about 180(mobo, cpu, and RAM using one of the Singles PSU's) and it's running perfectly for the past week. It uses a bit more power, but it will hardly be noticeable compared to the singles. The pi had good potential, just can't quite handle the load.

Don't know how many singles you're running, but why not just use more PIs?

[Luke-Jr]

I'm using this Zotac machine for some of my miners, FWIW.

[Mudbankkeith]

I'm using this Zotac machine for some of my miners, FWIW.

Same here. Zotac with win7x86 drawing 65W

64 BE's connected with no problem. and BFGMiner 3.2.1
(It looks like it will take close to the maximum usb of 127 for those who can afford that many devices)
Also hosting Bitcoin-Qt

I have a Pi with minepeon. drawing 6W. This starts to become unstable with more than 20 BE's
(Overheating and cpu load of 160%)

Edit:- Also I have a spare Pi in the system programmed, tested, and ready to run. Just for the day when S*** happens.

2nd edit:- the primary Pi will take over the hosting for BlueFury when they arrive in 10 days
(I still need assurance that minepeon will run them)

[HellDiverUK]

I use a http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-kit-dccp847dye.html - it runs BFGMiner and p2pool.  Uses around 10-20W.  I've got 11 Block Erupters, 2 Blades running through it, and I've got 2 BlueFuzzies and 2 Jalapenos ordered.  Running Windows 7 x86.

Sometimes I run the Block Erupters on a TPLink 703N running OpenWRT, and it uses about 0.5W.  It doesn't do the proxy for the blades, though, and certainly won't run p2pool.

[Mudbankkeith]

I use a http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-kit-dccp847dye.html - it runs BFGMiner and p2pool.  Uses around 10-20W.  I've got 11 Block Erupters, 2 Blades running through it, and I've got 2 BlueFuzzies and 2 Jalapenos ordered.  Running Windows 7 x86.

Sometimes I run the Block Erupters on a TPLink 703N running OpenWRT, and it uses about 0.5W.  It doesn't do the proxy for the blades, though, and certainly won't run p2pool.

Long live the celeron, its still a useful CPU.

Power saving is going to become a subject of serious value in the next few months.

[HellDiverUK]

Long live the celeron, its still a useful CPU.

It's a Celeron, but it's still a dual core Sandy Bridge running at 1.1GHz.  It's as quick as an old Core2Duo machine and uses about a 10th of the power.  They're even pretty decent as a workstation, if you've got enough memory and a fast HDD (I used to use this machine as the workstation in my den).

[rupy]

I get "/dev/ttyACM0 is already in use by another process" running bitfury branch with BF1

Edit: using -S littlefury:all returns "Read of fd 5 returned 0"

[Nemo1024]

An update on the UPS/bfgminer problem (previous quotes below).

It was the conflict with the UPS monitoring software after all (ViewPower 2.1.1), which follows with PowerWalker UPS. After uninstalling ViewPower, the problem disappeared.

Having started and stopped bfgminer almost a hundred times, I can see a pattern. ViewPower seems to be locking a random COM port for a very short period of time to communicate with the UPS unit, and then releases it.

bfgminer has two start-up phases, which I would call phase A ("Found BESx at \\.\COMx") and phase B ("Opened Icarus on \\.\COMx"). So:

1. In most cases bfgminer would report the privilege problem on a random COM port during phase A, and then not use it in phase B, resulting in one BE not hashing. Meaning ViewPower still uses the same port between the phases.

2. The same as above, but bfgminer does not find any problems during phase A, but then gets an error during phase B. Meaning ViewPower was in-between communications during the first phase, but then opened one COM port just before phase B started.

3. In less frequent cases, bfgminer would report the problem on one port during phase A and then on another port during phase B, resulting in 2 BEs not hashing. Meaning ViewPower closed the first port and opened a new one between phases.

4. The least frequent case is when bfgminer does not report any problems during either phase A or phase B - all miners are hashing. Meaning the timing was just right for ViewPower to be in the in-between communication state in both phases.

This also seems consistent with the number of BEs, hosted by a machine and probabilities of one case or the other: a machine with 96 BEs has a greater chance of #1 and #2, with an occasional #3. A machine with 43 BEs would see an occasional #1 and #2 with a more frequent #4.

Luke-Jr, could you, please, implement a command-line switch controlled function to rescan a list of previously-failed ports on a time-interval basis? That way I would be able to use the UPS monitoring software, while still having all BEs hashing.

Luke-jr, I have a problem with bfgminer on Windows 7 (both 32 and 64 bit builds), which appeared recently (possibly after I installed monitoring software for UPS units). It appeared on both machines, running about 60 BEs each.

The problem is that when bfgminer starts, I would get

Code:

Do not have user privileges required to open \\.\COMx

where 'x' is some random port (it tends to be in the range 1-15, but will sometimes pick ports in the higher range).

The port will then light solid green and will not hash.

Restarting bfgminer will yield another "failed" port. Sometimes all ports will get recognised and will not light green, but then all miners will blink a little and one port will light solid green again. I have double-checked and have enough power for all miners. I also tried with a smaller subset.

My request: could you for ports that give that "privileges" error, make a retry at a later point. It seems that time-out for failure is too short or something...

The thing is: it's not a specific port, but rather a random one, which will be different between bfgminer restarts.
Also I run bfgminer unattended in my Crypto Miners in Tray with -T command line arguments, so an automatic rescan of failed ports with some command-line defined delay/interval would be welcome.

I also tried removing all USB-COM port mappings (https://bitcointalk.org/index.php?topic=300638.0) and re-inserting the miners from scratch, allowing Windows to reinitialise all hubs and BEs.

In the meantime, I'll try uninstalling the UPS monitoring software and see if the problem goes away.

[HellDiverUK]

Luke-Jr, any update on when an official version of BFG is due with the Bluefury USB stick stuff built in?  Particularly the Windows version?

I see there's a version supplied by the Bitfury guys, but downloading "bfgMiner.zip" from a non-Luke-Jr server makes my ass twitch a bit. 

[Mudbankkeith]

Luke-Jr, any update on when an official version of BFG is due with the Bluefury USB stick stuff built in?  Particularly the Windows version?

I see there's a version supplied by the Bitfury guys, but downloading "bfgMiner.zip" from a non-Luke-Jr server makes my ass twitch a bit. 

same thoughts here. The "official source" is so much safer.

[rupy]

I had trouble getting my redfury to work with bfg (bitfury branch and whatnot) on my rpi, but cgminer 3.5 worked perfectly; just configure with --enable-bitfury.

[HellDiverUK]

I'd rather not use my 3 Bluefurys than use cgminer again, it sucks pretty hard when compared to bfgminer - no built-in proxy, poor BlockErupter support, the retarded need for fucking about with WinUSB drivers, terrible interface...  BFG also has and a developer who has a personality and is happy to help with issues rather than saying "README  " in response to any questions.

But, hey, horses for courses.

[vulgartrendkill]

I'd rather not use my 3 Bluefurys than use cgminer again, it sucks pretty hard when compared to bfgminer - no built-in proxy, poor BlockErupter support, the retarded need for fucking about with WinUSB drivers, terrible interface...  BFG also has and a developer who has a personality and is happy to help with issues rather than saying "README  " in response to any questions.

But, hey, horses for courses.

+1

Cgminer`s main downfall is that its main developers don`t seem to understand that not everyone can code\compile linux\compile anything.

I must have installed winusb 5 times and it still didn`t work.  Then I was told there is a problem with usb3 hubs. so the 100 gbp anker hub i`d bought was useless because they hadn`t got round to fixing it

[HellDiverUK]

I must have installed winusb 5 times and it still didn`t work.  Then I was told there is a problem with usb3 hubs. so the 100 gbp anker hub i`d bought was useless because they hadn`t got round to fixing it

I have an Anker USB3 hub, and it works perfectly with BFGMiner - it works with BFG on USB3 on three different PCs (AsMedia USB3, Intel USB3, NEC USB3), and USB2 on all the computers I've tried.  It also works on a TPLink 703N micro-router running OpenWRT with the Anker hub, which also powers the router.

[Luke-Jr]

3.3 will be released as soon as it's ready...

In the meantime, Windows binaries of the latest bitfury code are here:
http://luke.dashjr.org/tmp/code/webisect/webisect.php?dobuild=bitfury