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

[Taugeran]

curious why the NF6 needs an osc6 ramp up

[Luke-Jr]

curious why the NF6 needs an osc6 ramp up

Apparently some USB hosts/hubs (I couldn't reproduce it myself) have trouble powering them when Chip A uses significantly more power than Chip B.
The gradual ramp up keeps the chips on similar power usage requirements.

[Taugeran]

curious why the NF6 needs an osc6 ramp up

Apparently some USB hosts/hubs (I couldn't reproduce it myself) have trouble powering them when Chip A uses significantly more power than Chip B.
The gradual ramp up keeps the chips on similar power usage requirements.

ah. just wanted to make a note that on win7x64, bfgminer 32-bit the ramp up never occured. they stayed at 5 bits untill i manually changed them to 56.

maybe make this a polled thing and somehow only affecting the NF6, since it did this on a NF1 i was resoldering a version 2 chip onto.




another question, does the /webisect.php?dobuild=bfgminer

have any other parameters, maybe a commit parameter? just curious

[Luke-Jr]

curious why the NF6 needs an osc6 ramp up

Apparently some USB hosts/hubs (I couldn't reproduce it myself) have trouble powering them when Chip A uses significantly more power than Chip B.
The gradual ramp up keeps the chips on similar power usage requirements.

ah. just wanted to make a note that on win7x64, bfgminer 32-bit the ramp up never occured. they stayed at 5 bits untill i manually changed them to 56.

I don't see how this is possible.

maybe make this a polled thing and somehow only affecting the NF6, since it did this on a NF1 i was resoldering a version 2 chip onto.

It should be harmless on NF1...

another question, does the /webisect.php?dobuild=bfgminer

have any other parameters, maybe a commit parameter? just curious

dobuild is the commit parameter.
"bfgminer" is the name of the main branch, in this case.

[vs3]

curious why the NF6 needs an osc6 ramp up

I guess I can better explain that one -

with any chained/strings versions (such as the NF6) the voltage between each chip is determined based on the amount of current that goes through the chip.
So with 6 chips that's about 0.81V per chip. And here is the catch - 0.81V but only when chips use roughly equal amount of power.

However, if half of the chips are using a lot more power then this will make voltage distribution quite disproportional - the power-hungry chips will use so much power that the voltage drop at each of them may go down to 0.5V, which leaves for the other 3 chips 1.2V per chip. As a result communication between chips might get disrupted as voltages ("0" and "1" levels) go way beyond the acceptable tolerances.
And that's the situation that the "gradual ramp up" option is preventing.

With the gradual ramp-up all chips start at a slow speed (but most importantly - they all still use equal amount of power, resulting in roughly equal voltage distribution between each of the chips), and then gradually increase the speed but in a way that keeps all chips in sync.

Edit: forgot to add that this effect is significantly more pronounced with Bitfury Gen1 chips. Gen2 chips seem to be almost immune to this issue. However since the gradual start doesn't have any downsides (at least none worth considering) it's safer to just do it for both generations.

[Taugeran]

curious why the NF6 needs an osc6 ramp up

Apparently some USB hosts/hubs (I couldn't reproduce it myself) have trouble powering them when Chip A uses significantly more power than Chip B.
The gradual ramp up keeps the chips on similar power usage requirements.

ah. just wanted to make a note that on win7x64, bfgminer 32-bit the ramp up never occured. they stayed at 5 bits untill i manually changed them to 56.

I don't see how this is possible.

maybe make this a polled thing and somehow only affecting the NF6, since it did this on a NF1 i was resoldering a version 2 chip onto.

It should be harmless on NF1...

another question, does the /webisect.php?dobuild=bfgminer

have any other parameters, maybe a commit parameter? just curious

dobuild is the commit parameter.
"bfgminer" is the name of the main branch, in this case.

Ah so do build will accept a commit ID as well? Cool

[BRADLEYPLOOF]

I'm sure it's here somewhere, but which version of this runs a gridseed 5 chip on raspbian and how do i clone the git, ./configure it, make it and install it?  I'm having trouble trying to get a version of any program to run right on my pi.  I've checked all over google, downloaded cgminer-gc3355 from dtbartle (to no avail) tried bfgminer 3.99...what do i do?!

[Cassey]

Hi Bradley...

I ended up building a Gentoo Linux distribution for my PI, its running 3.99.0 without problems driving Antminers.  Awaiting my Gridseeds... they are late, but support is in 3.99.

Your welcome to snag it, the 16 GB SDHC card compressed down to a bit over 1GB.  I'm new at hosting torrents, but look for GentooPIimage080513.

Cassey

[nwoolls]

I need help from those who have experienced any performance issues with the GridSeed drivers. I know several folks have mentioned using my older branches as they seemed to work better. What I need is hard numbers and potentially access to these systems that perform differently.

I have deleted my old branches and created a new branch, gridseed-scanhash-loop, that is based on the older code folks were using. However I am unable to find any appreciable performance difference between this and the current GridSeed driver in the BFGMiner repo across any of the systems I've tested (OS X, Windows, Raspberry Pi).

GridSeed Queue miner loop: https://github.com/luke-jr/bfgminer
GridSeed Scanhash miner loop: https://github.com/nwoolls/bfgminer/tree/feature/gridseed-scanhash-loop

Thanks in advance.

[BRADLEYPLOOF]

I need help from those who have experienced any performance issues with the GridSeed drivers. I know several folks have mentioned using my older branches as they seemed to work better. What I need is hard numbers and potentially access to these systems that perform differently.

I have deleted my old branches and created a new branch, gridseed-scanhash-loop, that is based on the older code folks were using. However I am unable to find any appreciable performance difference between this and the current GridSeed driver in the BFGMiner repo across any of the systems I've tested (OS X, Windows, Raspberry Pi).

GridSeed Queue miner loop: https://github.com/luke-jr/bfgminer
GridSeed Scanhash miner loop: https://github.com/nwoolls/bfgminer/tree/feature/gridseed-scanhash-loop

Thanks in advance.

NWools, I'd be happy to lend you my computer running Debain Wheezy with the gridseed attached.  You can do whatever you need to on it, reformat it, load new everything...not a big deal.  I've got a CD image of Wheezy in case something breaks...

Edit: If you have a preferred version of Linux, I can put that on there too...

[nwoolls]

NWools, I'd be happy to lend you my computer running Debain Wheezy with the gridseed attached.  You can do whatever you need to on it, reformat it, load new everything...not a big deal.  I've got a CD image of Wheezy in case something breaks...

Edit: If you have a preferred version of Linux, I can put that on there too...

If you can confirm to me that the above two branches perform differently I'm not picky about the OS. I just need something that reproduces the issue reliably. Thanks!

[BRADLEYPLOOF]

NWools, I'd be happy to lend you my computer running Debain Wheezy with the gridseed attached.  You can do whatever you need to on it, reformat it, load new everything...not a big deal.  I've got a CD image of Wheezy in case something breaks...

Edit: If you have a preferred version of Linux, I can put that on there too...

If you can confirm to me that the above two branches perform differently I'm not picky about the OS. I just need something that reproduces the issue reliably. Thanks!

I'll clone them from GIT and try an install as soon as I get home.  It's currently 2:15PM my time, and I won't be home until 4PM or so, but when I get there, I'll play "Spot the Differences" between the two.

[Taugeran]

just making an observation, and asking for thoughts.

System: Raspberry Pi
OS: Raspian Wheezy HF Kernel 3.10.25+

Hardware: Bitfury M-Board V1.0 (all chips are a single large string), so this is recognized with the generic BFY_GPIO driver

previous absolutely solid, stable build was from commit: a355ac63b5671abd7a373151b683cd4e6be9ae2d

just recently did what i call a -next compile, from git source HEAD.

the TLS support would NOT allow connecting to stratum.btcguild.com:3333

performed

Code:

git revert 6520d158eba3bcff1b6e0343951ff38437ffea80 -m 1

to revert the merge

then rebuilt. This allowed connection to the pool and hashing commenced.

however, i noticed: out of the 64 chips total, 64 were recognized however only 60 were hashing/returning nonces.

to rule out hardware state, i power cycled and tried again. same thing.

to see if the Gen 2 detection was the culprit or something in between i did the following.

Code:

git clone https://github.com/luke-jr/bfgminer bfgminer-nxt-2 && cd bfgminer-nxt-2

git checkout a355ac63b5671abd7a373151b683cd4e6be9ae2d //known solid, been running for months

git cherry-pick 9d647767620ef121452db7f1ebf1d6be524ea4d8 //added Rev.2 detection/

git cherry-pick 61a2b9aacb4ff779d8c5cd29c9eab3e346aeb8be //fixed hashrate reporting for Rev.2 chips

./autogen.sh

CFLAGS="-O2" ./configure --without-libusb --without-hidapi

make -j2

sudo ./bfgminer -o stratum.btcguild.com:3333 -O user:pass --set BFY:osc6_bits=55 --set BFY:baud=500000

this resulted in a version of my previous stable build with the addition of the Rev.2 detection and reporting. Lo and behold the same 4 chips that were not returning results before, were NOT returning results with this modified version of my stable.



All executions were allowed 10 minutes to run.


ill attempt to get chainminer working so i can get a .core.log for the chips in question. ( just have to wait for MBP Rpi img v1 to download)


Bonus: whats special about the new values in bitfury_init_chip payload? do they produce a hit on one of the additional cores in rev.2 chips?

[meelvanchris]

Slowly but surely starting to switch from windows to linux...
So i build bfgminer...  ./autogen. sh   follwed by ./configure --enable-scrypt  --enable-opencl
Seems to be working... Amd 6970 fyi...    ocl is showing  :  605/578/268kH/s
Looking at bfg.readme file... it says :
An all time average hash rate
An all time average hash rate based on actual nonces found, adjusted for pool
reject and stale rate..

So im correct to assume that my current hash rate is 268kh/s?
If so.. its half of what i got on windows... did i miss something while building?

edit... pretty sure i missed something... it causes systemfreeze from time 2 time.. but what?

[nwoolls]

If anyone has access to a G-Blade please PM me. I'd like to test driver support for it. Thanks!

[Harwood]

I don't know if this question has been asked before because I'm kinda new to the forums (not new to mining). I am using BFGMINER as a proxy for my 8 blades and 2 cubes and was wondering if its possible to use comma separated values in the username (-u) as in ... -u user1,user2,user3  and so on and would that also work in the password field ...the reason I am asking is that I want to be able to monitor each card or cube as separate workers in my mining pools dashboard so I don't have to keep the teamviewer window running all the time on my desktop. I also have 6 antminer S1s that I just watch from browser tabs (much cleaner) ...I am just trying to clear up some of my desktop clutter ...nothing like having to have 6 windows open all the time ...and that way I can stop relying on team viewer since it crashes like 5 times a day ...

Try MultiMiner (and  maybe MobileMiner) it will fun multiple instances of BFGMiner and give you stats on each 'Cube and 'Blade.  It does it for me.

[Luke-Jr]

just recently did what i call a -next compile, from git source HEAD.

the TLS support would NOT allow connecting to stratum.btcguild.com:3333

performed

Code:

git revert 6520d158eba3bcff1b6e0343951ff38437ffea80 -m 1

to revert the merge

then rebuilt. This allowed connection to the pool and hashing commenced.

Did you wait a bit? BTCGuild is just hanging on TLS attempts, so there's a 30 second timeout when initially connecting and then later following the redirect.
Eleuthria apparently does not plan to fix this, and I'm not sure whether it's worth removing (or requiring explicit enabling of) TLS just to workaround it.

however, i noticed: out of the 64 chips total, 64 were recognized however only 60 were hashing/returning nonces.

to rule out hardware state, i power cycled and tried again. same thing.

to see if the Gen 2 detection was the culprit or something in between i did the following.

Code:

git clone https://github.com/luke-jr/bfgminer bfgminer-nxt-2 && cd bfgminer-nxt-2

git checkout a355ac63b5671abd7a373151b683cd4e6be9ae2d //known solid, been running for months

git cherry-pick 9d647767620ef121452db7f1ebf1d6be524ea4d8 //added Rev.2 detection/

git cherry-pick 61a2b9aacb4ff779d8c5cd29c9eab3e346aeb8be //fixed hashrate reporting for Rev.2 chips

./autogen.sh

CFLAGS="-O2" ./configure --without-libusb --without-hidapi

make -j2

sudo ./bfgminer -o stratum.btcguild.com:3333 -O user:pass --set BFY:osc6_bits=55 --set BFY:baud=500000

this resulted in a version of my previous stable build with the addition of the Rev.2 detection and reporting. Lo and behold the same 4 chips that were not returning results before, were NOT returning results with this modified version of my stable.

Can you get me a debuglog with --device-protocol-dump of this?

Bonus: whats special about the new values in bitfury_init_chip payload? do they produce a hit on one of the additional cores in rev.2 chips?

The new payload has 8 nonces in it, a few of which are never found by gen1 chips.

ah. just wanted to make a note that on win7x64, bfgminer 32-bit the ramp up never occured. they stayed at 5 bits untill i manually changed them to 56.

FWIW, I found the bug causing this.

Code:

while (bitfury->osc6_bits < 50)

On the first iteration, bitfury points to data beyond the array.

[vs3]

Lately I've been having weird issues with bfgminer mostly when the connection with eligius drops - if at some point the pool disconnects then after the reconnect or switch to another pool my miners just never start hashing again.

Saw this in the log today:

Code:

 [2014-05-10 20:55:08] Accepted 04f7b06f NFY 1c pool 3 Diff 51/16
 [2014-05-10 20:55:08] Accepted 0d3bef9f NFY 1a pool 3 Diff 19/16
 [2014-05-10 20:55:08] Accepted 00380c0c NFY 1a pool 3 Diff 1.17k/16
 [2014-05-10 20:55:08] Accepted 054b4b91 NFY 1d pool 3 Diff 48/16
 [2014-05-10 20:56:08] Stratum connection to pool 3 interrupted
 [2014-05-10 20:56:08] Pool 3 http://stratum.mining.eligius.st:3334 not responding!
 [2014-05-10 20:56:08] Switching to pool 1 stratum+tcp://mint.bitminter.com:3333
 [2014-05-10 20:56:08] pool 1 JSON stratum auth failed: [
   20,
   "Unknown method 'mining.get_transactions'",
   null
]
 [2014-05-10 20:56:08] Pool 1 stratum+tcp://mint.bitminter.com:3333 not responding!
 [2014-05-10 20:56:08] Switching to pool 2 stratum+tcp://stratum.mining.eligius.st:3334
 [2014-05-10 20:56:08] pool 1 JSON stratum auth failed: [
   20,
   "Unknown method 'mining.get_transactions'",
   null
]
 [2014-05-10 20:56:31] Pool 2 stratum+tcp://stratum.mining.eligius.st:3334 not responding!
 [2014-05-10 20:56:39] Pool 1 stratum+tcp://mint.bitminter.com:3333 alive, testing stability
 [2014-05-10 20:56:46] Switching to pool 1 stratum+tcp://mint.bitminter.com:3333
 [2014-05-10 21:06:14] Stratum from pool 1 detected new block
 [2014-05-10 21:17:22] Stratum from pool 1 detected new block
 [2014-05-10 21:35:19] Stratum from pool 1 detected new block
 [2014-05-10 21:36:36] Stratum from pool 1 detected new block
 [2014-05-10 21:46:19] Stratum from pool 1 detected new block
 [2014-05-10 21:59:46] Stratum from pool 1 detected new block
 [2014-05-10 22:07:13] Stratum from pool 1 detected new block

for the record - I have the following pools: 0,2,3 - eligius, 1 - bitminter

this was when running build: 3177195928193c7f744eee45885a3c3e1f8df49e-win32-gradual but it's been happening for a while (maybe last 1-2 months)

Am I doing something possibly wrong? Or in the alternative - which debug logs/options should I turn on to get more details for further troubleshooting?

[Luke-Jr]

Lately I've been having weird issues with bfgminer mostly when the connection with eligius drops - if at some point the pool disconnects then after the reconnect or switch to another pool my miners just never start hashing again.

Saw this in the log today:

Code:

 [2014-05-10 20:55:08] Accepted 04f7b06f NFY 1c pool 3 Diff 51/16
 [2014-05-10 20:55:08] Accepted 0d3bef9f NFY 1a pool 3 Diff 19/16
 [2014-05-10 20:55:08] Accepted 00380c0c NFY 1a pool 3 Diff 1.17k/16
 [2014-05-10 20:55:08] Accepted 054b4b91 NFY 1d pool 3 Diff 48/16
 [2014-05-10 20:56:08] Stratum connection to pool 3 interrupted
 [2014-05-10 20:56:08] Pool 3 http://stratum.mining.eligius.st:3334 not responding!
 [2014-05-10 20:56:08] Switching to pool 1 stratum+tcp://mint.bitminter.com:3333
 [2014-05-10 20:56:08] pool 1 JSON stratum auth failed: [
   20,
   "Unknown method 'mining.get_transactions'",
   null
]
 [2014-05-10 20:56:08] Pool 1 stratum+tcp://mint.bitminter.com:3333 not responding!
 [2014-05-10 20:56:08] Switching to pool 2 stratum+tcp://stratum.mining.eligius.st:3334
 [2014-05-10 20:56:08] pool 1 JSON stratum auth failed: [
   20,
   "Unknown method 'mining.get_transactions'",
   null
]
 [2014-05-10 20:56:31] Pool 2 stratum+tcp://stratum.mining.eligius.st:3334 not responding!
 [2014-05-10 20:56:39] Pool 1 stratum+tcp://mint.bitminter.com:3333 alive, testing stability
 [2014-05-10 20:56:46] Switching to pool 1 stratum+tcp://mint.bitminter.com:3333
 [2014-05-10 21:06:14] Stratum from pool 1 detected new block
 [2014-05-10 21:17:22] Stratum from pool 1 detected new block
 [2014-05-10 21:35:19] Stratum from pool 1 detected new block
 [2014-05-10 21:36:36] Stratum from pool 1 detected new block
 [2014-05-10 21:46:19] Stratum from pool 1 detected new block
 [2014-05-10 21:59:46] Stratum from pool 1 detected new block
 [2014-05-10 22:07:13] Stratum from pool 1 detected new block

for the record - I have the following pools: 0,2,3 - eligius, 1 - bitminter

this was when running build: 3177195928193c7f744eee45885a3c3e1f8df49e-win32-gradual but it's been happening for a while (maybe last 1-2 months)

Am I doing something possibly wrong? Or in the alternative - which debug logs/options should I turn on to get more details for further troubleshooting?

Try updating from git. I believe I just fixed this earlier tonight.

[leptar]

With BFGminer in win7 how can i see the associated devices assigned com ports?


I found the info 3 months ago and bookmarked it but that link is dead...

This was done via the command line..

TIA.