OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB

[inaltoasinistra]

I'm getting a lot of reject (30%) from eligius. I have a BFL SC 7GH/s, Arch Linux and bfgminer 3.8.1, What could be wrong? Thanks!

what kind of rejects?

R: X+Y

Y type. (Sorry, I don't know the meaning of the 2 numers :O) Now the situation is better

EDIT: not so much better: 15% D:

[asjfdlksfd]

Hi,

is it hard to add the ZlX command output after the ZLX output in the Manage device section for the Chily? It gives the internal temperatures of every chip.
Edit:

PROCESSOR 0: 39.75 C
PROCESSOR 1: 35.75 C
PROCESSOR 2: 35.75 C
PROCESSOR 3: 36.25 C
PROCESSOR 4: 42.50 C
PROCESSOR 5: 42.00 C
PROCESSOR 6: 40.50 C
PROCESSOR 7: 41.25 C

Also I found that ZcX command adds the temperatures to the end of the line from each chip:

PROCESSOR 0: 9 engines @ 137 MHz -- MAP: E07E 27 C
PROCESSOR 1: 14 engines @ 198 MHz -- MAP: DFF7 26 C
PROCESSOR 2: 7 engines @ 188 MHz -- MAP: 0BF0 27 C
PROCESSOR 3: 15 engines @ 201 MHz -- MAP: FF7F 29 C
PROCESSOR 4: 13 engines @ 159 MHz -- MAP: E7FE 27 C
PROCESSOR 5: 8 engines @ 168 MHz -- MAP: 0FF0 27 C
PROCESSOR 6: 8 engines @ 179 MHz -- MAP: 0FF0 26 C
PROCESSOR 7: 15 engines @ 179 MHz -- MAP: F7FF 32 C

I think it must be modified in bitforce.c but I'm really novice in c coding

Cheers...

[dE_logics]

bfgminer returns 100% hardware error on Linux doing CPU and/or GPU mining of scrypt based coins.

[HellDiverUK]

Now my Cube is working properly (new PSU fixed the issues I had), I can confirm that it hashes quicker through Slush's Proxy than it does through BFG's proxy.

Through BFG it never reports more than 30GH.  Even after an hour it was still stuck at around 30GH.  It's running a 37.5GH and still rising through Slush's proxy, and only been running through that for about 10 mins.

Both BFG and Slush's are running on the same machine (Celeron NUC running Windows 7 x86).

[Luke-Jr]

Now my Cube is working properly (new PSU fixed the issues I had), I can confirm that it hashes quicker through Slush's Proxy than it does through BFG's proxy.

Through BFG it never reports more than 30GH.  Even after an hour it was still stuck at around 30GH.  It's running a 37.5GH and still rising through Slush's proxy, and only been running through that for about 10 mins.

Both BFG and Slush's are running on the same machine (Celeron NUC running Windows 7 x86).

I'm curious if -q fixes this. Can you let me know?

[HellDiverUK]

Now my Cube is working properly (new PSU fixed the issues I had), I can confirm that it hashes quicker through Slush's Proxy than it does through BFG's proxy.

Through BFG it never reports more than 30GH.  Even after an hour it was still stuck at around 30GH.  It's running a 37.5GH and still rising through Slush's proxy, and only been running through that for about 10 mins.

Both BFG and Slush's are running on the same machine (Celeron NUC running Windows 7 x86).

I'm curious if -q fixes this. Can you let me know?

Sorry, forgot to mention - I've got -q on both my instances of BFG (both OpenWRT and Windows).  

There's no difference on the Windows machine (BFG is using less than 5% CPU while running proxy for 2 Blades, 1 Cube and 2 Jalapenos if -q is specified or not).  

There IS a difference on the OpenWRT machine, it's much faster at proxying with -q specified, but still not as fast as the PC.

Longpoll support seems to be the only difference I see.

[Amph]

this miner  last version, still support vga right?

how to start this miners with a gpu, i've tried in solo but the miner keep saying add devices, i have pressed m and the plus, but still nothing..

[jedimstr]

this miner  last version, still support vga right?

how to start this miners with a gpu, i've tried in solo but the miner keep saying add devices, i have pressed m and the plus, but still nothing..

After you put in M and the plus, opencl:auto

[Amph]

ok it work now, hashrate a little below cgminer, but it's ok

how to see my best share and my difficulty? i mean not the net difficulty, but the difficulty i need to surpass to find a block

[Taugeran]

ok it work now, hashrate a little below cgminer, but it's ok

how to see my best share and my difficulty? i mean not the net difficulty, but the difficulty i need to surpass to find a block

They are one and the same

[Amph]

in cgminer they were different, here they are the same?

[Taugeran]

in cgminer they were different, here they are the same?

i mean not the net difficulty, but the difficulty i need to surpass to find a block

Finding a block means your share meets or exceeds the network diff (currently 1.18B)

Finding a share just means find a valid solution that mets your pools diff

how to see my best share and my difficulty?

These can be seen in the top few lines of bfgminer
Your current pool diff is in :
Conected to XXX diff ### with stratum
Where ### is the share diff for your account

Best score is a line or two lower on the right

BS:###


Sorry for misleading coverall answer :/

Merry christmahanakwanzaka to all btw

[joeventura]

Just upgraded to 3.8.1 so my new Chili boards would work. Which it fixed perfectly!

commandline with -g -s all no longer works, and as soon as I remove those then the block erupters stop working.

How can I get BFL devices, Chilis and Block Erupter USBs to all work at the same time?

[Taugeran]

Just upgraded to 3.8.1 so my new Chili boards would work. Which it fixed perfectly!

commandline with -g -s all no longer works, and as soon as I remove those then the block erupters stop working.

How can I get BFL devices, Chilis and Block Erupter USBs to all work at the same time?

What is are you running on?

And are your chilies and bfls working. Just not the erupters

[Luke-Jr]

Just upgraded to 3.8.1 so my new Chili boards would work. Which it fixed perfectly!

commandline with -g -s all no longer works, and as soon as I remove those then the block erupters stop working.

How can I get BFL devices, Chilis and Block Erupter USBs to all work at the same time?

Spelling -S in the right case (uppercase) would help.
There is no -g option.

[Luke-Jr]

NEW VERSION 3.9.0, DECEMBER 25 2013

Merry Christmas!

Human readable changelog:

• hashbusterusb: Voltage/VRM controls, and support for identify function (5 second LED colour change).
• nanofury: Support for identify function by turning LED off for 5 seconds.
• twinfury: Support for voltage information/control.
• Linux: New udev rules file to automatically put supported (and autodetectable) mining devices in the "video" UNIX group.

Full changelog:

• Update official Win32 build compiler and library:
  • Upgrade GCC from 4.8.1 to 4.8.2
  • Upgrade libcurl from 7.28.1 to 7.34.0
• Update official Win64 build compiler and library:
  • Upgrade GCC from 4.7.3 to 4.8.2
  • Upgrade mingw64-runtime from 2.0.8 to 3.0.0
• Green-on-red title colours for Christmas release
• write_config: Include http-port and stratum-port options
• Interpret F1 as a request for Help
• Bugfix: SSM: Free old _ssm_notify before replacing it
• Bugfix: SSM: Clean _ssm_cur_job_work as needed to avoid memory leaks
• Support matching --scan with lowlevel devid
• cgpu_match: Unit test for USB device path matching
• Bugfix: cgpu_match: Handle digits in dname (x6500)
• cgpu_match: More unit tests (dname with digit)
• cgpu_match: More unit tests (dname and case insensitivity)
• Display "NO DEVICES FOUND" line in place of device list, when there are none
• bitfury: Use drv_set_defaults to enable setting baud before probe
• bitfury: Split out SPI port configuration option ("baud") to its own function
• drv_set_defaults wrapper function around cgpu_set_defaults for use with options that may need to be set during probe
• bitfury: Set poll interval to start iteration before responses are processed
• modminer: Check identification begins with "ModMiner" to avoid false detection
• Bugfix: hashbusterusb: Correct return value of hashbusterusb_vrm_unlock
• Support for installing a udev rules file for Linux
• twinfury: Remove unused variable to silence warning
• cgpu_request_control should be a noop when called from the main thread
• Bugfix: Handle errors creating a vcom devid more gracefully
• Bugfix: _wlog: Allocate enough space for complete copy of log line
• bfsb: Remove unused clock_gettime
• Bugfix: bfsb: Remove useless slot_on which was never properly initialised
• Bugfix: When QueryDosDevice fails, skip trying to parse its (undefined) results
• hashbusterusb: Voltage should be in volts (not millivolts) for RPC
• hashbusterusb: Provide access to VRM stuff from RPC
• hashbusterusb: Use cgpu_request_control interface to safely access device from outside main thread
• hashbusterusb: Include Voltage in RPC stats
• Bugfix: hashbusterusb: Ensure unlock code is always allocated, even if null
• hashbusterusb: Abstract code into hashbusterusb_vrm_lock
• hashbusterusb: Abstract code into hashbusterusb_vrm_unlock
• hashbusterusb: Abstract code into hashbusterusb_set_voltage
• Bugfix: hashbusterusb: Check for voltage change error correctly
• Abstract mutex_request code from X6500 driver into generic device API interface
• hashbusterusb: Use standard identification behaviour
• hashbusterusb: Abstract hashbusterusb_set_colour function
• hashbusterusb: Get voltage with temperature
• hashbusterusb: Clean up unused variable warnings
• hashbusterusb: Use bitfury_wlogprint_status for osc6_bits displaying in Manage TUI
• Bugfix: hashbusterusb: Remove ignored prompt for VRM lock
• hashbusterusb: Use Manage/osc6_bits code from main bitfury driver
• hashbusterusb: Provide access to VRM and identification in Manage TUI
• hashbusterusb: Shutdown PSU
• nanofury: Support identify function by turning off LED for 5 seconds
• nanofury: nanofury_state structure
• bitfury: Set poll interval to start iteration before responses are processed
• Twinfury: moved voltage reading to the thread init function
• Twinfury supply voltage initial reading: error log improved
• Twinfury: Reading supply voltage on startup
• Voltage scaling for twinfury implemented

[crazyearner]

problem starting new 3.9 after downloading zip

[Luke-Jr]

problem starting new 3.9 after downloading zip

Downgrade libcurl to the one 3.8.1 used for now.
Problem is actually due to GCC 4.8, but there is a semi-workaround...
I'll rebuild the Win32 ZIPs with it.

[chek2fire]

I have a problem with all the bfgminers versions in linux.


https://bitcointalk.org/index.php?topic=386074.new#new

 I use it because is the only miner programme that can handle nanofury usb erupter and i have one of them and the rest is simple asicminer 333. Bfgminer works perfect when i plugged usb erupters  direct to my desktop pc but when i plugged  them to a dlink hub then after a while most of them disconnect and failed to work.
The problem is only in linux system and only with bfgminer all versions. I have try it and to windows with the same version of bfgminer and there was not any problem there.
Also cgminer has no problem with hub in windows and linux but i cant use it because it didnt support nanofury.
Any idea why i have this this dc in hub under linux?

[Mudbankkeith]

I have a problem with all the bfgminers versions in linux.


https://bitcointalk.org/index.php?topic=386074.new#new

 I use it because is the only miner programme that can handle nanofury usb erupter and i have one of them and the rest is simple asicminer 333. Bfgminer works perfect when i plugged usb erupters  direct to my desktop pc but when i plugged  them to a dlink hub then after a while most of them disconnect and failed to work.
The problem is only in linux system and only with bfgminer all versions. I have try it and to windows with the same version of bfgminer and there was not any problem there.
Also cgminer has no problem with hub in windows and linux but i cant use it because it didnt support nanofury.
Any idea why i have this this dc in hub under linux?

do you have another hub?  if so its worth a try.