Pages:
Author

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

legendary
Activity: 2576
Merit: 1186
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
legendary
Activity: 2576
Merit: 1186
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.
hero member
Activity: 658
Merit: 500
CCNA: There i fixed the internet.
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
hero member
Activity: 854
Merit: 500
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?

hero member
Activity: 658
Merit: 500
CCNA: There i fixed the internet.
in cgminer they were different, here they are the same?

Quote
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

Quote
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 Smiley
legendary
Activity: 3248
Merit: 1070
in cgminer they were different, here they are the same?
hero member
Activity: 658
Merit: 500
CCNA: There i fixed the internet.
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
legendary
Activity: 3248
Merit: 1070
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
hero member
Activity: 798
Merit: 1000
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
legendary
Activity: 3248
Merit: 1070
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..
hero member
Activity: 1246
Merit: 501
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.
legendary
Activity: 2576
Merit: 1186
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?
hero member
Activity: 1246
Merit: 501
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).
hero member
Activity: 686
Merit: 500
bfgminer returns 100% hardware error on Linux doing CPU and/or GPU mining of scrypt based coins.
full member
Activity: 128
Merit: 100
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 Tongue

Cheers...
full member
Activity: 142
Merit: 104
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:
hero member
Activity: 1246
Merit: 501
Previous Bitfountain (aka "ASICMiner") products did not support long polling, but it is certainly beneficial and perhaps worth adding to BFGMiner.

That would be great if you could - currently running the Cube through slush's proxy seems a little more efficient than through bfg's - but I'd rather use bfg.
legendary
Activity: 2576
Merit: 1186
Previous Bitfountain (aka "ASICMiner") products did not support long polling, but it is certainly beneficial and perhaps worth adding to BFGMiner.
hero member
Activity: 658
Merit: 500
CCNA: There i fixed the internet.
I'm using an ASICMiner Cube.  BFGMiner 3.8.1 32-bit on Windows and 3.8.1 on OpenWRT. 

The Cube is reporting no Longpoll support when using BFG's getwork proxy, but does say Longpoll is active when using Slush's proxy.

Is Longpoll important? 

Lp is used to gve updates on blocks for the getwork protocol aka new block on network.

It shouldn't make a difference since bfgminer is just man in the middle to a stratum/gbt pool or node and those protocols let bfgminer know of new blocks and all other data through a single comm channel

GW used more than 1 comm channel
Strtm/gbt use 1 comm channel

I don't believe bfgminer is presently coded to take upstream new blocks alerts and pass them down stream to proxies. No need really. The work bfgminer issues will always be current block as long as the pool is.

Slush maybe coded to do the above functionality?

@LJR care to correct any falsehoods in my logic?
legendary
Activity: 2576
Merit: 1186
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?
Pages:
Jump to: