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"
Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 114. (Read 1193368 times)
October 01, 2013, 04:53:02 AM
October 01, 2013, 03:18:35 AM
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).
October 01, 2013, 02:57:44 AM
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.
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.
October 01, 2013, 02:24:32 AM
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.
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.
October 01, 2013, 01:40:23 AM
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)
October 01, 2013, 12:23:11 AM
I'm using this Zotac machine for some of my miners, FWIW.
September 30, 2013, 11:32:04 PM
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? September 30, 2013, 11:21:20 PM
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.
September 30, 2013, 05:42:15 PM
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 :
in my bfgminer.conf :
i dont know why the config write allways "temp-cutoff" and "temp-target" in this.
i hope you can help.
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"
}
"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.
September 30, 2013, 03:58:26 PM
Will you be supporting the bluefurry usb's?
Should already work with -S bigpic:all on the bitfury branch. 
September 30, 2013, 03:48:57 PM
Will you be supporting the bluefurry usb's?
September 30, 2013, 02:54:30 PM
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.
And the other one won't take these chips.
So it looks like I'm out of luck.
https://bitcointalksearch.org/topic/the-chili-30ghs-bfl-based-bitcoin-miner-assembly-304250
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
September 30, 2013, 02:51:17 PM
One of the board devs had 'Cointamination' in his signature, so I asked him about it, maybe it will work after all. I hope I'm wrong in my assumption that it doesn't fit.
Either way I'll have opened up a dialog & can ask that he talk to you.
Either way I'll have opened up a dialog & can ask that he talk to you.
September 30, 2013, 02:47:15 PM
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.
Well, I wouldn't give up without asking the vendors if they can provide documentation and/or a sample unit for development... That's pretty standard. And the other one won't take these chips.
So it looks like I'm out of luck.
September 30, 2013, 02:11:17 PM
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.
And the other one won't take these chips.
So it looks like I'm out of luck.
September 30, 2013, 02:08:51 PM
Hi,
I'm considering purchasing a custom mining rig that's made out of these BFL chips that are for sale as part of the following Group Buy listed at this URL: https://bitcointalksearch.org/topic/closed-bfl-4-ghs-chips-06-btc-per-chip-batch-29-236103
I'd like to know before I commit to buying it whether or not the device will work with bfgminer running in Windows.
Does anyone know who can tell me if it would work?
Thanks.
The only boards I can confirm support for at this time, besides the official BFL ones, are:I'm considering purchasing a custom mining rig that's made out of these BFL chips that are for sale as part of the following Group Buy listed at this URL: https://bitcointalksearch.org/topic/closed-bfl-4-ghs-chips-06-btc-per-chip-batch-29-236103
I'd like to know before I commit to buying it whether or not the device will work with bfgminer running in Windows.
Does anyone know who can tell me if it would work?
Thanks.
- Cointamination
- Eligius Mining Patty
- GamaStack
I'd be glad to support more though - perhaps ask your potential vendor if they can send me a PM.
September 30, 2013, 01:08:52 PM
Hi,
I'm considering purchasing a custom mining rig that's made out of these BFL chips that are for sale as part of the following Group Buy listed at this URL: https://bitcointalksearch.org/topic/closed-bfl-4-ghs-chips-06-btc-per-chip-batch-29-236103
I'd like to know before I commit to buying it whether or not the device will work with bfgminer running in Windows.
Does anyone know who can tell me if it would work?
Thanks.
I'm considering purchasing a custom mining rig that's made out of these BFL chips that are for sale as part of the following Group Buy listed at this URL: https://bitcointalksearch.org/topic/closed-bfl-4-ghs-chips-06-btc-per-chip-batch-29-236103
I'd like to know before I commit to buying it whether or not the device will work with bfgminer running in Windows.
Does anyone know who can tell me if it would work?
Thanks.
September 30, 2013, 12:46:12 PM
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://bitcointalksearch.org/topic/windows-many-usb-hubs-and-besfuries-clean-up-in-your-devices-manager-300638) 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.
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://bitcointalksearch.org/topic/windows-many-usb-hubs-and-besfuries-clean-up-in-your-devices-manager-300638) 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.
September 30, 2013, 12:32:01 PM
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...
You can always ask BFGMiner to rescan...But sounds like your UPS program has it locked.
September 30, 2013, 12:29:38 PM
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
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...
if may be that that COMx is now reserved by windows for the UPS monitor. If you are running bfgminer as a user not administrator a -S all or -S COM(that x) will fail. you can try running bfgminer as admin but the will allow bfgminer to send a data string as part of it's scan over a reserved COM port (Might mess up UPS monitor) 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...
Jump to: