OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30

[lightfoot]

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

C

[Luke-Jr]

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

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

[lightfoot]

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

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

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

[Luke-Jr]

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

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

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.

Can you bisect that issue?

[lightfoot]

Can you bisect that issue?

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

[Luke-Jr]

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

[giveen]

What is the proper format to add chip count per Zeus device? I already have clock set, but how do I set chip count per device?


This is what I have so far. My usb0 is a 128 chip and the usb1 is a 64 chip
--set zus@/dev/ttyUSB0:clock=328 --set zus@/dev/ttyUSB1:clock=328

[nwoolls]

What is the proper format to add chip count per Zeus device? I already have clock set, but how do I set chip count per device?


This is what I have so far. My usb0 is a 128 chip and the usb1 is a 64 chip
--set zus@/dev/ttyUSB0:clock=328 --set zus@/dev/ttyUSB1:clock=328

If both clocks are the same you do not need to set them individually:

Code:

--set zus:clock=328 --set zus@/dev/ttyUSB0:chips=128 --set zus@/dev/ttyUSB1:chips=64

[bitdigger2013]

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

Did they not want to pay you to maintain a working version for the Titan, which is not running well and they can't seem to tell us why?

I understand and appreciate that you are not supporting that version. Could you chime in on if you think the version they have running is causing issues concerning coins with fast blocks and fast diff changes? or even merge mining seems to slow down the hashrate.

Also all these errors? Thanks for any help you wish to provide or insight on why KNC if screwing up

  [2014-10-02 14:46:35] Stratum from pool 1 detected new block
<bitdigger2013> [2014-10-02 14:46:35] KNC 2: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:46:37] KNC 3: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:46:37] KNC 0bgn: Got nonce for unknown work in slot 6 (asic 1)
<bitdigger2013> [2014-10-02 14:46:37] KNC 0bhh: Got nonce for unknown work in slot 6 (asic 1)
<bitdigger2013> [2014-10-02 14:46:37] KNC 0coj: Got nonce for unknown work in slot 6 (asic 1)
<bitdigger2013> [2014-10-02 14:46:37] Pool 1 stale share detected, submitting as user requested
<bitdigger2013> [2014-10-02 14:46:37] Rejected 00020a60 KNC 1atv pool 1 Diff 490m/125m (job not found)
<bitdigger2013> [2014-10-02 14:46:41] KNC 0: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:46:43] KNC 1: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:46:44] KNC 2: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:46:46] KNC 3: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:46:47] KNC 0bgo: Got nonce for unknown work in slot 8 (asic 1)
<bitdigger2013> [2014-10-02 14:46:47] KNC 0cok: Got nonce for unknown work in slot 8 (asic 1)
<bitdigger2013> [2014-10-02 14:46:50] Pool 1 stale share detected, submitting as user requested
<bitdigger2013> [2014-10-02 14:46:50] Accepted 00063259 KNC 2bdg pool 1 Diff 161m/125m
<bitdigger2013> [2014-10-02 14:46:50] KNC 2bgz: Got nonce for unknown work in slot 0 (asic 3)
<bitdigger2013> [2014-10-02 14:46:54] KNC 0: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:46:55] KNC 1: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:46:57] KNC 2: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:46:58] Network difficulty changed to 65 (472.0M)
<bitdigger2013> [2014-10-02 14:46:58] Stratum from pool 1 detected new block
<bitdigger2013> [2014-10-02 14:46:58] KNC 3: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:47:00] Pool 1 stale share detected, submitting as user requested
<bitdigger2013> [2014-10-02 14:47:00] Rejected 000160a1 KNC 2atz pool 1 Diff 725m/125m (job not found)
<bitdigger2013> [2014-10-02 14:47:00] Pool 1 stale share detected, submitting as user requested
<bitdigger2013> [2014-10-02 14:47:00] Rejected 0004e736 KNC 2bht pool 1 Diff 203m/125m (job not found)
<bitdigger2013> [2014-10-02 14:47:03] KNC 0: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:47:05] KNC 1: Flushing stale works (New work)
<bitdigger2013> [2014-10-02 14:47:06] Network difficulty changed to 65 (465.6M)

[Luke-Jr]

Did they not want to pay you to maintain a working version for the Titan, which is not running well and they can't seem to tell us why?

They didn't ask, and I didn't ask.

I understand and appreciate that you are not supporting that version. Could you chime in on if you think the version they have running is causing issues concerning coins with fast blocks and fast diff changes? or even merge mining seems to slow down the hashrate.

No idea, the whole "not supporting" is basically just making a note that I don't have one, don't know the platform at all, and cannot answer questions about it at all - it's not that I don't want to, just that I don't have anything to go on.
But maybe KnCMiner's engineers or other users can answer your questions here or elsewhere

[bitdigger2013]

Did they not want to pay you to maintain a working version for the Titan, which is not running well and they can't seem to tell us why?

They didn't ask, and I didn't ask.

They should have.

I understand and appreciate that you are not supporting that version. Could you chime in on if you think the version they have running is causing issues concerning coins with fast blocks and fast diff changes? or even merge mining seems to slow down the hashrate.

No idea, the whole "not supporting" is basically just making a note that I don't have one, don't know the platform at all, and cannot answer questions about it at all - it's not that I don't want to, just that I don't have anything to go on.
But maybe KnCMiner's engineers or other users can answer your questions here or elsewhere

Fair enough.

Unfortunately KNC doens't look like they know or want to fix the issue. They prefer to say that pools are the big problem. However this miner cannot mine anything other then straight LTC(no merge mine) with stability. Even just mining LTC gives the above mentioned errors.

 

[Ntrain2k]

Any idea what I can do to stop this from happening? The pools seem to be up just fine.

[ScriptProdigy]

Any idea what I can do to stop this from happening? The pools seem to be up just fine.

https://i.imgur.com/fFqhd0r.png

Any chance you can run a packet sniffer and see whats going on between the pool and miner?

[Ntrain2k]

Any idea what I can do to stop this from happening? The pools seem to be up just fine.

Any chance you can run a packet sniffer and see whats going on between the pool and miner?

Have a good recommendation for one that will run on windows?

[Ntrain2k]

Any idea what I can do to stop this from happening? The pools seem to be up just fine.

Any chance you can run a packet sniffer and see whats going on between the pool and miner?

Have a good recommendation for one that will run on windows?

Stepped back to 4.5.0 and it has no problems at all.

[nwoolls]

Any idea what I can do to stop this from happening? The pools seem to be up just fine.

Any chance you can run a packet sniffer and see whats going on between the pool and miner?

Have a good recommendation for one that will run on windows?

Stepped back to 4.5.0 and it has no problems at all.

Try disabling the Coinbase check by appending /#skipcbcheck to the pool URL.

[Ntrain2k]

Any idea what I can do to stop this from happening? The pools seem to be up just fine.

Any chance you can run a packet sniffer and see whats going on between the pool and miner?

Have a good recommendation for one that will run on windows?

Stepped back to 4.5.0 and it has no problems at all.

Try disabling the Coinbase check by appending /#skipcbcheck to the pool URL.

Add /#skipcbcheck at the end of the pool URL's like this?

   stratum+tcp://us-east.multipool.us:8888/#skipcbcheck

[nwoolls]

Stepped back to 4.5.0 and it has no problems at all.

Try disabling the Coinbase check by appending /#skipcbcheck to the pool URL.

Add /#skipcbcheck at the end of the pool URL's like this?

   stratum+tcp://us-east.multipool.us:8888/#skipcbcheck

Exactly.

[Ntrain2k]

Stepped back to 4.5.0 and it has no problems at all.

Try disabling the Coinbase check by appending /#skipcbcheck to the pool URL.

Add /#skipcbcheck at the end of the pool URL's like this?

   stratum+tcp://us-east.multipool.us:8888/#skipcbcheck

Exactly.

Thanks!

I'll have to keep an eye on it. It does it at random times.

[Ntrain2k]

Stepped back to 4.5.0 and it has no problems at all.

Try disabling the Coinbase check by appending /#skipcbcheck to the pool URL.

Add /#skipcbcheck at the end of the pool URL's like this?

   stratum+tcp://us-east.multipool.us:8888/#skipcbcheck

Exactly.

Thanks!

I'll have to keep an eye on it. It does it at random times.

Crap, now I'm getting a ton of this:



It jumps around all of the different miners.