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

I'm glad he does that work too.  MultiMiner with BFG for the backend is great.  The only thing I have to run separate is MemoryCoin or Primecoin on the CPU.
 

In the meantime, thanks for your support of scyrpt Nwoolls!  It nice to use one mining software package for all my needs.

(well mostly, I hate to see a CPU sit idle, so CPU mine as well for Primecoins (on windows), and scyrpt on Linux.  If I didn't do that, the cpu's would be busy doing BOINC, so even if I'm losing money, I'm losing it slower )

I'm sure they will, and I think the initial crop is still very interesting.

Scrypt FPGA/ASICs are not widely available. Only samples are being sent out. And the ones that are being sent out are not as profitable (for Scrypt) as GPUs - yet.

I did not know that.
I have it running at 3.33gh/s with the pencil mod.
For some reason I thought I had overclocked it before in pure BFG using oscillator bits adjustments.  Maybe it was my BiFury.
I'm a bit fuzzy the last few days with no sleep.
I was thinking using the oscillator bits method might be more precise than the pencil mod.  When I push it above 3.33 with the pencil mod errors go through the roof.  3.33 seemed to be the sweet spot of low errors and good performance.
Thanks for the info. 

redfuries are closed source non software adjustable. the only way to make them hash faster is to hardware mod them to a higher voltage


if you mean nanofury/hitchhiker/yellowjacket, then it should be --set-device NFY:osc6_bits=XX in the extra arguments box

Does anyone know the correct arguments for MultiMiner for changing the oscillating bits for RedFuries overclocking??
I cannot figure it out.
nwools gave me all sorts of great info I just can't seem to execute it properly.

You mean like this:

 OCL 0: 29.0C |  31.3/ 29.1/  9.0kh/s | A: 2 R:2+0(none) HW:0/none
 OCL 1: 92.0C | 452.2/451.4/323.3kh/s | A:46 R:0+0(none) HW:0/none
 OCL 2: 85.0C | 465.8/466.4/355.6kh/s | A:49 R:1+2(none) HW:2/none

Where CL0 is the APU and CL1 & 2 are R9 270xs?

Thanks for the post, just cranked this guy up last night and hadn't noticed.  Still, acceptance level of CL0 is in line with its relative performance.

Hi,
  Anyone facing this situation in bfgminer where if you have slower devices like erupters with faster ones like furies, one or more slower devices would have lower accepted rates? I originally suspected it could be my erupters but when i moved the erupters to another machines, they progressed at the same (accepted) rates. btw, i am using bfgminer 3.10.0

Some of us think Bitcoin is useless, so we mine one of the other hundreds of coins that is not Bitcoin.

Here is the editor and instructions for editing the serial number on ANTS any USB device that uses CP210x SLLabs driver,
One caveat - - the editing must be done with only one device installed at a time, or it does not work right.

https://bitcointalksearch.org/topic/usb-block-erupter-repair-and-tricks-270367   - instructions

http://jau.cc/asic/CP210x_Manufacturing.zip  -- Bios editor

Just went to SLLabs site, and it seems this is now considered - "vintage"

SLLabs is starting to push winusb, for locked bios control USB 3.0 spec and windows 8.
Our current devices/chips will never fit it that spec. protocol is all wrong.

The serial number is the same for both. So no luck this way.

 AMU 0 :       |  2.05/ 2.05/ 2.01Gh/s | A: 632 R:1+14(2.3%) HW:4/.15%
  CP2102 USB to UART Bridge Controller from Silicon Labs
Serial: 0001

 AMU 1 :       |  2.01/ 2.05/ 1.99Gh/s | A: 688 R:1+13(2.0%) HW:1/.04%
  CP2102 USB to UART Bridge Controller from Silicon Labs
Serial: 0001

I have both on different USB serial ports, but can't determine from the serial reported.

crw-rw---- 1 root dialout 188,  1 Feb  1 11:10 /dev/ttyUSB1
crw-rw---- 1 root dialout 188,  0 Feb  1 11:10 /dev/ttyUSB0

Now that I have placed them both in a hub in front of the air intake of my computer, the HW errors are considerable down. Still would like to control it.
Is the serial then equivalent to the USBx ?

Running with -T -D I get this:
 [2014-02-01 12:33:19] lowlevel_scan: Found usb device at usb:001:009 (path=(null), vid=10c4, pid=ea60, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)                   
 [2014-02-01 12:33:19] lowlevel_scan: Found usb device at usb:001:008 (path=(null), vid=10c4, pid=ea60, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)                   
 [2014-02-01 12:33:19] lowlevel_scan: Found usb device at usb:005:001 (path=(null), vid=1d6b, pid=0001, manuf=(null), prod=(null), serial=(null))                   
 [2014-02-01 12:33:19] lowlevel_scan: Found usb device at usb:002:001 (path=(null), vid=1d6b, pid=0002, manuf=(null), prod=(null), serial=(null))                   
 [2014-02-01 12:33:19] lowlevel_scan: Found usb device at usb:006:001 (path=(null), vid=1d6b, pid=0001, manuf=(null), prod=(null), serial=(null))                   
 [2014-02-01 12:33:19] lowlevel_scan: Found usb device at usb:003:001 (path=(null), vid=1d6b, pid=0002, manuf=(null), prod=(null), serial=(null))                   
 [2014-02-01 12:33:19] lowlevel_scan: Found vcom device at dev_t:01bc000000000000 (path=/dev/ttyUSB1, vid=0000, pid=0000, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)                   
 [2014-02-01 12:33:19] lowlevel_scan: Found vcom device at dev_t:00bc000000000000 (path=/dev/ttyUSB0, vid=0000, pid=0000, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)                   
 [2014-02-01 12:33:19] Icarus Detect: Attempting to open /dev/ttyUSB1                   
 [2014-02-01 12:33:19] Icarus Detect: Attempting to open /dev/ttyUSB0                   
 [2014-02-01 12:33:19] Acquired exclusive advisory lock on /dev/ttyUSB0                   
 [2014-02-01 12:33:19] Acquired exclusive advisory lock on /dev/ttyUSB1                   
 [2014-02-01 12:33:19] Icarus Detect: Test succeeded at /dev/ttyUSB0: got 000187a2                   
 [2014-02-01 12:33:19] Found AMU 0 at /dev/ttyUSB0                   
 [2014-02-01 12:33:19] AMU 0: Init: baud=115200 work_division=0 fpga_count=0                   
 [2014-02-01 12:33:19] AMU 0: Init: mode=default read_count=19 limit=0ms Hs=4.761000e-10                   

....

What is the alternative to GPU mining when mining scrypt ?

Figure out which is which by serial number ([M]anage should tell you) and use:
--set-device antminer@serial:clock=x0881 --set-device antminer@otherserial:clock=x0981

I have one problem with my 2 ant miners. Both runs stable at x0881, and one is stable at x0981.

How can I run them at different speeds ?
Tried this without luck:
--set-device antminer:clock=x0881 --set-device antminer:clock=x0981

There's an interesting pedegree: cpuminer -> cgminer (GPU) -> BFGMiner (formerly released under the name cgminer) -> cgminer.

Only if it becomes troublesome to maintain.
At the moment, nwoolls is maintaining the scrypt part of the code, so it's not at risk of being removed.
We could always use more contributors, though - even non-programmers can help out with improving documentation

Hey Luke,

Are you going to stop supporting scrypt and GPU mining like the idiot that maintains cgminer?

I thought both you guys were forks of https://github.com/jgarzik/cpuminer

More or less, though at this point it might be more accurate to say they have common roots: since forking, the cgminer devs have rewritten most of the BFGMiner code (for the worse, though).

As I shift non-ASIC things over to Litecoins, I'm finding myself with a mix of GPUs in my system and wondering if there is a way to set parameters for each individually?

For instance, one poor machine has an APU, a 7870, and a R9-270x.

Note that I'm seriously impressed that it works as well as it does with just generic setting, but one is always trying to tweak a bit more out.

FYI using "-S opencl:auto --intensity 16 --temp-overheat 90 --temp-cutoff 100 --temp-target 80 --scrypt --gpu-fan 100 --auto-gpu" now.

Miner update:  Swapped cards around on another machine, running (2) XFX R9-270s at --intensity 20, rest left alone, and they are running at 465khs/ +/- 2.