Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 101. (Read 1193368 times)

move the jalapeno into your master hub.

Hey, sorry if this has already been covered but I just got a jalapeno and I'm running it under BFGMiner 3.3.0 along with 14 BEs.  It's on a MacMini running Ubuntu 12.04 i386.  The setup will run fine for anywhere from 2-3 hours to 20+ hours but then the jalapeno will report as sick.  The jalapeno is plugged directly into the MacMini and the BEs are in 2 Anker hubs that are plugged into another hub and from there into the mini.  Once I shutdown BFGMiner and restart everything works again.  The temps look fine, 38-41, and I'm just wondering if anyone has a suggestion.

If you are looking into reducing your overhead even more, you might want to checkout http://minepeon.com
It's a mining distro that runs off a Raspberry Pi.

Hi my setup doc for xubuntu should help you http://tinyurl.com/cboxzdy

How hard is it to use bfg in unbunto. Im a windows guy ready for a change.

Pretty sure a number of people use it on RedHat/CentOS.
It's my understanding they'll soon have a package in the official repositories.

Why is not possible to Install it on CENTOS and REDHAT

it does work indeed. i`ve swtched back to .3 for the moment.  I also get a Error failed to wake notifier spam the window.  Like i said 3.3 works like a dream

Watch the miner logs - bfgminer display up to ica14 by default - not sure how to reset it.

It does sound like a power problem.
Take a read through this thread:-   https://bitcointalksearch.org/topic/m.2700634
Lots of hub information.

Doesn't need to be 9A if the PSU is outputting 12v.  Only needs to be a 4-5A 12v to provide 9A of 5v.

Hi Luke-Jr
So does this mean I need to specify all the com ports, if I am mixing Erupters and BlueFurys?

I use -S all for my erupters, when I added a Fury I used the :\\.\COMn. but the Fury was not found.
If I run the Fury on its own then it works ok.

This acts like you do not have a full 0.5 amps to each usb port.  I know Dyconn claims .900mA per port, that means it must have a 9 amp power supply.  I bet if you measured the amp out put it well be less than 9 amps.  A good Fluke meter can measure up to 10 amps dc with out a external shunt.

Just don't use -S :all
This tells BFGMiner to probe every port for the device.
Erupters can't handle BigPic probes, and BigPic can't handle Icarus probes.

I experienced this problem when UPS controller software would hi-jack random COM ports. I had to uninstall UPS monitor, but I am petitioning for Luke to include a delayed automatic re-scan of COM ports that failed to initialise.

Luke, can you comment on the following, regarding BlueFuries:

Unplug and re plug your USB hubs with the miners while the computer is on and without BFGMiner running and let them all light up before starting BFGMiner.

Then use -S erupter:all instead of all the Icarus options. 

I realized that the stats reply has the naming scheme I desired, but curiously, using DEVS+STATS in a customsummarypage on miner.php results in all chips from BSB2 being left out completely from the tables. It's the only device I have with 32 chips instead of 16.

So with just DEVS, I can see BSB0 (16 chips), BSB1 (16 chips), BSB2 (32 chips) & BSB3 (16 chips). If I change the DEVS to DEVS+STATS, for some reason BSB2 is skipped. Setting $per_proc to true or false makes no difference; either BSB2 or all chips from BSB2 are missing.

I'm thinking there might be something wrong with the join_get_field function's ProcID -> lowercase letter conversion, when there are two letters instead of one. Looks like the code just converts the ProcID to a letter, but that won't match the naming scheme with two letters. Doesn't look like it's easy to fix, because you just can't know whether ProcID 0 should be converted to a or aa, until you know how many procs there actually are in that device.

This is not supported, nor planned to be supported.
It wrecks havoc on the internals of the mining framework, so it wouldn't surprise me if it fried your CPU or caused your GPU to explode or anything.

As the README says:

I wasn't all that familiar with the quota system, but I played around with it a little, and it sort of does what I want, but it jumps around the pools too much; 5-10 hashes to one pool, then it switches to another pool...

I'm envisioning something where you could set the quota, and then tell it to mine at least xx minutes to one pool before switching, especially if you are running multiple pools that have different coin... when jumping from one coin to another, BFG seems to hang and have to re-tune itself to the other coin, which is time consuming lowering the hashing rate... if you could stay on one pool for xx minutes or longer, then this re-tuning to a different coin would be reduced.

For example, I would like to mine ASC, OSC, TGC, UNO, XJC and ZET together, but currently with the quota system it just jumps around too much and has to re-tune for each coin... the only viable options right now is to go with "rotate xx minutes" and you are stuck with the global time in minuted you set... if you could specify the pool mining time for each pool, then we would be closer to what I am looking for...

Anyway, just work on your high priority requirements and when the time comes and you can work on this, see what you can do with either the quota system or the rotate option.

Thanks.

P.S. Keep up the awesome work, your miner is the best in my opinion.