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

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 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.


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?

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.

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!

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...

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.

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

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?!

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

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.

I don't see how this is possible.

It should be harmless on NF1...

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

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

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.

curious why the NF6 needs an osc6 ramp up

You also should keep in mind that even with pure 64-bit, programs use nearly 2x as much memory.
Loading 64-bit *and* 32-bit means nearly 3x.

Soo.. does this explain the jump in Ram percentage in use on my computer when I changed from Windows 8.1 preview 32-bit to Windows 8.1 pro 64-bit? Because it seems that most Metro Apps are 32-bit.

Not significantly. It runs on 64-bit OS and takes advantage of x86_64's larger and more numerous registers (so, a bit lower CPU usage).

Contrary to popular myth, 32-bit applications do not run on 64-bit OS; they require a compatibility layer (WoW64 on Windows) and loading into memory 32-bit versions of all the OS libraries - so basically you need to run a hybrid 32-bit/64-bit OS if you use both 32-bit and 64-bit applications.

Thanks!

I was always interested but till now never asked. Is there any advantage in 64 bit version over 32 bit one?

No, it's only in git so far. When 4.0 is released, it will be in there.
You can get Windows builds of the latest git from my webserver.

So if I download latest windows version it is included?

Maybe it has been discussed here before, but I couldnt find where.

Besides [D]isabling and [E]nabling an Antminer, is there a way for BFGMiner to restart or reset an AMU from scratch, thus expliciting the 0981 freq again?

Thanks