Topic: OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 - page 9. (Read 308659 times)

NEW VERSION 4.9.0, OCTOBER 5 2014

Please note that the new Titan driver is maintained by KnCMiner, and neither nwoolls nor myself can provide support for it.

Human readable changelog:

• titan: Driver for KnCMiner's scrypt ASIC machine.

Full changelog:

• Upgraded Windows libraries:
  • libcurl from 7.37.0 to 7.38.0
  • libusb from 1.0.18 to 1.0.19 (Win64 only)
  • mingw64-runtime from 3.1.0 to 3.2.0 (Win64 only)
  • uthash from 1.9.7 to 1.9.9
• Travis: Update for titan driver
• configure: Accept --enable-titan=CONTROLLER to select controller
• make-release: Remove unnecessary knc-asic/{*.rbf,*system,waas} from release source
• extra_work_queue so devices can influence their effect on the central work queue somewhat (titan needs less than 1-per-proc)
• Avoid adding include paths for titan driver
• Bugfix: titan: Add missing printf formatting for core busy status
• avalon: Drop custom hexdump logging
• Build titan driver independently from knc (Jupiter) driver
• titan: Do not fill up next slot immediately after urgent setwork
• titan: Pre-fill work queue so that all ASICs have fresh jobs after a flush
• Build instructions for KnC Titan
• Doesn't compile without explicitly included inttypes.h on some machines
• knc-asic: Updated to e5c986d3c44fde8c5b069508ef6979f2f2be92d6
• Fix Makefile.am to build bfgminer for titan
• titan: Subdivide full nonce range only between cores in one ASIC (because works are now distributed per-ASIC too)
• titan: DC/DCs does not like broadcast flushes (urgent setwork). Do not do it!
• titan: Preparation to setting threads-per-core externally, by user
• titan: Re-flush cores in case of slot number collision
• titan: Per-ASIC flush, per-ASIC work management
• titan: Start cores after flush individually, not by broadcast.
• titan: Default frequency is 275 MHz
• titan: Difficulty is offset by one in ASIC cores.
• titan: Fix first_proc pointer
• titan: Use 2 threads per core
• titan: Use setup_core from knc-asic library
• titan: Poll all enabled ASICs amd dies, not only one
• titan: Properly set work_accepted flag
• titan: Hint detection function about expected device type
• titan: Fix setup_core command
• titan: Use knc-asic library for transport layer
• Add knc-asic as submodule
• titan: Change spi device to spidev1.0
• titan: Add define to .h file
• titan: Increase workqueue size up to number of slots per core
• titan: Send data to hashmeter
• titan: Disregard stale reports after flush
• titan: Check for next asic/die switch when processing info results
• Bugfix: titan: Fix segfault
• titan: Set actual hardware nonce_diff for works in prepare_work
• titan: Do clean flush ("purge") on init
• titan: Store last_nonce right
• titan: First attempt to process nonce responses
• titan: Change 'scanhash' minerloop to 'queue'
• titan: Init all cores for their own nonce ranges
• titan: For RPi we use spidev0.1
• titan: Setup_core command implemented
• titan: New commands set_work & get_report
• titan: Move asic-specific functionality to the separate file (titan-asic.c)
• titan: First ugly detect of Titan chip over SPI
• knc-titan: Begin work on Titan (scrypt miner) driver
• libbase58: Use git URI for submodule to avoid failure on systems without HTTPS support
• Travis: Cross-compile a Win64 build
• RPC: Initialise json_config to silence false warning
• Make sure MOUSE_MOVED from wincon is ignored (it conflicts with curses)
• Travis: Perform full builds with libbase58's base58 tool (which is used for tests)
• Travis: Test many configuration variations
• Travis: Build with libsensors and VFIO
• Travis: Upgrading GCC triggers locale rebuild, so just do the one in use
• Travis: No need to upgrade GCC for LLVM build
• Travis build configuration
• Run BFGMiner's unit tests for 'make check', and have --unittest exit with failure if any problems occur
• libbase58: Update to pick up on LLVM fixes
• Bugfix: configure: Affect gridseed driver with --disable-other-drivers
• Bugfix: configure: minergate driver needs lowlevel for claiming sockets
• Bugfix: configure: --disable-other-drivers should not affect non-driver options
• Bugfix: configure: --with[out]-vfio needs $withval, not $enableval
• Bugfix: rockminer: Correct types for short read error message
• Bugfix: icarus: fix the STATS RPC API call crashes with a multi-proc device
• Bugfix: cointerra: Check lowlevel device is USB before trying to probe it (as USB)
• bitforce: Reinstate device work inprogress count sanity check for 28nm devices
• littlefury: Read uC temperature sensor
• littlefury: Keep track of enabled chips and power state explicitly in case of trouble
• Bugfix: async minerloop fix for devices disabled at start
• twinfury: Implement device protocol dump more low-level

There are two problems that seem to happen. Both I think are related to minor noise in the data stream and how a lot of data can go to the BFL chips' very high number of engines.

The biggest problem is the annoying "data mismatch". What happens is the BFGMiner queries the Monarch in a block mode for all queued results, and the Monarch sends back all the data with a unique serial number for the block in question, followed by the results. The problem is that can get garbled between the Atmel sending it on the parallel bus, the FTDI chip that converts to serial, and of course the computer running BFG.

If an entry is garbled, all the results are thrown out and now you have a case where the Monarch thinks its' queue is empty but BFGMiner has the requests outstanding and doesn't send any more data to those engines. Eventually it times out with a huge number of errors that can sometimes crash BFGMiner and it restarts.

The other problem is sending data *to* the Monarch. Because of all the engines you can send a whole crap-ton of requests at once, I think if one of those gets garbled the Monarch never works on the job but BFGMiner either thinks it's occupied or you get the "Failed to send queue".

Couple that with the fact that sometimes if I power my Monarch off and leave it off for an hour to cool off it works perfectly with BFG 4.8. No errors even after a week of running. But turn it off and on hot and it will drop in speed to 400-500gh with occasional massive streams of errors.

BFGMiner 4.2 on the BFL site does not have this problem AT ALL. Literally I can stop 4.8 with errors and crashes, plug in my 64 bit Windows 7 laptop, run the 4.2 code (it's compiled 64 bit. AARRGGHH!) and it works flawlessly. Never a burp, problem, or anything. So it's not really the hardware, or more to the point it can be fixed in software.

Why. Why why why why why why why? I'm thinking maybe the queueing features were disabled; in the GIT code repository I see that someone made a change to the code I was fiddling with that solves the first problem well but the Filed to send queue eventually jams up the Monarch and BFG. Thus the "it's a two part thing" I think.

It doesn't help much that I know how to program perfectly in Fortran-77 and my C abilities are more Objective C from NextStep. The C++ code in the Bitforce section is really kind of... tight...

C

Can you bisect that issue?

Ok. Banging on the code for the BFL Monarchs. Still need to fix the highly annoying error where it gets stuck, drives me nuts that the custom 4.2 64 bit code works perfectly but the 4.8 has queueing problems.

C

Yep, see --request-diff in README. Most (all?) pools ignore the request, though.

Quick question: Is it possible to request a higher difficulty by default in BFGMiner?

C

Thank you nwoolls - I will anxiously await your response.  - pokeytex

I've forwarded this question onto my contacts at GridSeed and X-Hash to see if they can answer.

Hello - Does anyone know if the Gridseed G-black will work with BFGMiner 4.8.0?  I am getting one soon and am running this version with my other Gridseed products.

Not sure if it helps, but someone posted the code modification they did to a driver in the CGMiner thread to make it work with it.

Can probably give you access to one if you need it.

S1 driver is somewhere on my todo list as free time permits. still waiting on "modified" hardware to arrive to allow easier dev time

Don't even have a S3 here...

Need drivers for AntMiner S3's bad.

I need help. It happens on some pools that i´ve been disconnected.. The miner mines a while ~3 minutes and my hashrate is goind down.
http://s9.postimg.org/mq59filsr/dif.jpg

I'm using bfgminer 4.2.2. for Zeusminer. ( Fury 1,3 MH )

What driver set would we use for the Avalon Nanos?
I am not sure as it does not seem to use the standard sets.

Run BFGMiner with --stratum-port 3333
Then point your T1 controller at the PC's IP and that port, with a unique username.

How can I use bfgminer with rockminer T1? It has a specific controller. How to connect it with other system, like PC or RpI.

Still waiting on word for possible support of AntMiner S3's. Anyone have an idea?

Thanks for taking the time to clarify, though I am not sure I can get my brain around it.
1. The intital query (not from me) had a proxy upstream diff of 1024 but the rig was submiting diff 1 shares - (I guess because the proxy did not ask for a diff which you suggested to set at 128, or any higher number)
2. If I set the proxy diff at that high number via commandline, my understanding (and this is where I could have got myself in a twist) is that the proxy will ask the rigs to submit ONLY shares above or equal to that diff. In which case, if I were to set it very high, then the rigs will discard anything not equal to or higher than that very high number, which high number could actually be a lot higher (by a magnitude if I set it to 1000000) than the diff requested by the pool, resulting in the rigs discarding and NOT submiting perfectly OK shares to the proxy.

That is where I believe there could be issues with dynamic diff setting pools, however, I'll give it a shot tomorow when I am fresh and see what I reap.