OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 - page 8.

Ntrain2k

hero member

Activity: 527

Merit: 500

HiveNet - Distributed Cloud Computing

Quote from: Luke-Jr on October 09, 2014, 03:21:28 PM

Quote from: Ntrain2k on October 09, 2014, 03:19:56 PM

Can anyone tell me how to use the unsafe:N command?

I have some of the small rockminers running at 290 along with some of the 110 GH units. Due to the 290 clockspeed set they are only hashing around 81 each. When I try to go in and adjust them up to 350 it returns the dangerous clockspeed and use the unsafe:N to force.

Thanks.

--set rkm:clock=unsafe:350

You the man!

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Ntrain2k on October 09, 2014, 03:19:56 PM

Can anyone tell me how to use the unsafe:N command?

I have some of the small rockminers running at 290 along with some of the 110 GH units. Due to the 290 clockspeed set they are only hashing around 81 each. When I try to go in and adjust them up to 350 it returns the dangerous clockspeed and use the unsafe:N to force.

Thanks.

--set rkm:clock=unsafe:350

Ntrain2k

hero member

Activity: 527

Merit: 500

HiveNet - Distributed Cloud Computing

Can anyone tell me how to use the unsafe:N command?

I have some of the small rockminers running at 290 along with some of the 110 GH units. Due to the 290 clockspeed set they are only hashing around 81 each. When I try to go in and adjust them up to 350 it returns the dangerous clockspeed and use the unsafe:N to force.

Thanks.

Ntrain2k

hero member

Activity: 527

Merit: 500

HiveNet - Distributed Cloud Computing

Quote from: Ntrain2k on October 07, 2014, 06:54:57 PM

Quote from: Ntrain2k on October 07, 2014, 06:51:17 PM

Quote from: nwoolls on October 07, 2014, 06:42:22 PM

Quote from: Ntrain2k on October 07, 2014, 06:38:34 PM

Quote from: nwoolls on October 07, 2014, 06:27:42 PM

Quote from: Ntrain2k on October 07, 2014, 05:29:49 PM

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.

I switched back to 4.5.0 for now. Might try 4.6.0 or 4.7.0 later. 4.8.0 and 4.9.0 give the errors shown for some reason. None of them on 4.5.

lightfoot

legendary

Activity: 3164

Merit: 2258

I fix broken miners. And make holes in teeth :-)

FYI the latest version didn't fix the Monarch errors. Luke, if you're interested I'll do a quick post of what I found. I did have a hack where it tries to do an intelligent match on the replies back to BFGMiner to compare to the queue to find dropped bytes, but it's spectacularly ugly and that 4.2 custom code doesn't do that from what I can tell.

I think they just went back to single-reply responses and single work loads. Finding exactly where these happen in the BFL code is tough for me.

C

sdjernes

newbie

Activity: 49

Merit: 0

Quote from: Ntrain2k on October 07, 2014, 04:11:35 PM

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

Wireshark works great. At least it does on 2008 R2 and 7. I haven't tried it on 8.x or 2012 R?.

Ntrain2k

hero member

Activity: 527

Merit: 500

HiveNet - Distributed Cloud Computing

Quote from: Ntrain2k on October 07, 2014, 06:51:17 PM

Quote from: nwoolls on October 07, 2014, 06:42:22 PM

Quote from: Ntrain2k on October 07, 2014, 06:38:34 PM

Quote from: nwoolls on October 07, 2014, 06:27:42 PM

Quote from: Ntrain2k on October 07, 2014, 05:29:49 PM

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.

Ntrain2k

hero member

Activity: 527

Merit: 500

HiveNet - Distributed Cloud Computing

Quote from: nwoolls on October 07, 2014, 06:42:22 PM

Quote from: Ntrain2k on October 07, 2014, 06:38:34 PM

Quote from: nwoolls on October 07, 2014, 06:27:42 PM

Quote from: Ntrain2k on October 07, 2014, 05:29:49 PM

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.

nwoolls

hero member

Activity: 840

Merit: 1002

Quote from: Ntrain2k on October 07, 2014, 06:38:34 PM

Quote from: nwoolls on October 07, 2014, 06:27:42 PM

Quote from: Ntrain2k on October 07, 2014, 05:29:49 PM

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

hero member

Activity: 527

Merit: 500

HiveNet - Distributed Cloud Computing

Quote from: nwoolls on October 07, 2014, 06:27:42 PM

Quote from: Ntrain2k on October 07, 2014, 05:29:49 PM

Quote from: Ntrain2k on October 07, 2014, 04:11:35 PM

Quote from: ScriptProdigy on October 07, 2014, 04:08:53 PM

Quote from: Ntrain2k on October 07, 2014, 02:57:55 PM

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

hero member

Activity: 840

Merit: 1002

Quote from: Ntrain2k on October 07, 2014, 05:29:49 PM

Quote from: Ntrain2k on October 07, 2014, 04:11:35 PM

Quote from: ScriptProdigy on October 07, 2014, 04:08:53 PM

Quote from: Ntrain2k on October 07, 2014, 02:57:55 PM

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

hero member

Activity: 527

Merit: 500

HiveNet - Distributed Cloud Computing

Quote from: Ntrain2k on October 07, 2014, 04:11:35 PM

Quote from: ScriptProdigy on October 07, 2014, 04:08:53 PM

Quote from: Ntrain2k on October 07, 2014, 02:57:55 PM

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.

Ntrain2k

hero member

Activity: 527

Merit: 500

HiveNet - Distributed Cloud Computing

Quote from: ScriptProdigy on October 07, 2014, 04:08:53 PM

Quote from: Ntrain2k on October 07, 2014, 02:57:55 PM

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?

ScriptProdigy

newbie

Activity: 37

Merit: 0

Quote from: Ntrain2k on October 07, 2014, 02:57:55 PM

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

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

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

Ntrain2k

hero member

Activity: 527

Merit: 500

HiveNet - Distributed Cloud Computing

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

bitdigger2013

sr. member

Activity: 397

Merit: 250

Quote from: Luke-Jr on October 06, 2014, 03:26:54 PM

Quote from: bitdigger2013 on October 06, 2014, 03:15:51 PM

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.

Quote from: bitdigger2013 on October 06, 2014, 03:15:51 PM

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: bitdigger2013 on October 06, 2014, 03:15:51 PM

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.

Quote from: bitdigger2013 on October 06, 2014, 03:15:51 PM

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

sr. member

Activity: 397

Merit: 250

Quote from: Luke-Jr on October 05, 2014, 01:38:19 AM

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

nwoolls

hero member

Activity: 840

Merit: 1002

Quote from: giveen on October 06, 2014, 08:13:21 AM

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

giveen

hero member

Activity: 826

Merit: 1004

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

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