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

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.

Fixed, thanks.

first post:

"For miners using ModMiner, X6500, or ZTEX devices, you will need to download bitstreams for BFGMiner 3+ to work with your device. Download links and instructions are included in the README.ASIC file."


shouldn't README.ASIC read README.FPGA 

I plan to rewrite all the work distribution code at some point to complete GBT support.

That's cool, if you can squeeze it in while working on the section of code that needs the modification when you find time.

This is not a pressing request, but it would be a nice thing to have.

No rush on my part, just an idea.

Thanks for listening

More likely I'd just make rotate based on the new quota system.
But there's so many higher-priority things right now, I don't think I'll be able to get to it for a while.

WISHLIST

Luke-Jr,

any chance you could modify BFG miner so we can put the

"rotate" : "15",

item in the conf file into the pool configuration so we can have various pools mined for different time lengths, i.e.

"pools" : [
   {
      "url" : "stratum+tcp://poolserver1:port",
      "user" : "UserName",
      "pass" : "Password",
      "rotate" : "15",
      "pool-priority" : "0"
   },
   {
      "url" : "stratum+tcp://poolserver2:port",
      "user" : "UserName",
      "pass" : "Password",
      "rotate" : "90",
      "pool-priority" : "1"
   }

I will be relegating my Erupters to coin other than BTC, and would like to rotate through several different coin, but I don't want to mine each one for 15 or 45 minutes each, since they all have different rewards and difficulty levels, so it would be nice to be able to adjust how long each pool gets mined.

Thanks

I've been having random problems where BFGMiner refuses to start mining on startup. It has happened with both BFL and BFSB hardware. Here's an example of what it looks like on BFL hardware: http://pastebin.com/ZixrFdrM

BFGMiner will just sit there doing nothing for minutes. If I manually command it to switch to some other pool, and then back to pool 0, it will start working right away. Sometimes pool 0 is detected as dead upon startup (I think this is a ghash.io specific issue), but then BFGMiner might get similarly stuck on pool 1.

happy to be of service

Ah, I see.  I was hoping by using --http-port it would take the getwork requests and translate them to stratum requests to the pool, like stratum_proxy.exe does.

I've changed to --stratum-port, and changed my minerd to point to stratum+tcp://bfgminer-pc instead of http://bfgminer-pc.  It's working now.  I had been using getwork because before today I never had good luck getting stratum to work with minerd.  But now it works like a charm!

Thanks!

--http-port is the getwork proxy  for stratum you need to use --stratum-port


also should add that each miner needs its own unique username and pass; doesn't matter what

Hello.  I'm hoping someone can help me find what I don't have set up correctly.

I've been CPU mining scrypt coins on a group of Windows machines funneled through stratum_proxy.exe, but I'm trying to get bfgminer working that proxy role instead.

I have a basic config:


And just to be sure, I start bfgminer with:  bfgminer --scrypt

But my test minerd doesn't seem to be generating any shares:


Am I missing something?

Does the old 3.3.0 bat file still work on version 3.3.0?

If so start version 3.4.0 with the old bat file.

Then if you want to change or add another pool, just work on a spare copy of the file.

I`ve tried switching from .3 to .4, carried over the bat file, and started 3.4, added a pool pressed enter and...it froze. did nothing for 10 mins.

Any ideas?

My bat file works perfectly on 3.3, and thats the only thing i`ve added.

Ok, installed 3.4 and it's apparently seeing the device but now declaring it sick. Debug output shows its stuck doing the following:
Re-initialize
Attempting to restart
Idle for more than 60 seconds, declaring SICK!

If you can provide any suggestions they would be much appreciated. Not particularly concerned about how high USB requirements are.

PM Sent to Steamboat      Thanks Luke

I sent LiquidSynDesigns a message, but it's probably more effective if existing or potential customers also request support.