Topic: OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 - page 27. (Read 308349 times)
July 08, 2014, 07:18:35 PM
July 08, 2014, 06:32:52 PM
Is there a current version of this for Ubuntu? The one from the repository is 3.*, but I'm using it with my Rockminer so it needs to be the latest version.
Edit: I misunderstood how to build it on Ubuntu. I'm still a newbie with Linux desktop (although I ran a server for years for my job, I was not compiling things). I'm all set now, thanks!
Edit: I misunderstood how to build it on Ubuntu. I'm still a newbie with Linux desktop (although I ran a server for years for my job, I was not compiling things). I'm all set now, thanks!
July 07, 2014, 01:21:04 PM
I would like Support for COINTERRA ASICS please.
See cointerra branch for a hack, or help develop cointerra_fresh (it doesn't get full hashrate, and haven't figured out why). July 07, 2014, 01:19:50 PM
I would like Support for COINTERRA ASICS please.
July 07, 2014, 01:05:58 PM
NEW VERSION 4.4.0, JULY 7 2014
Human readable changelog:
Full changelog:
Human readable changelog:
- getwork and stratum proxy drivers: Proxy-share difficulty is now adjustable using --set pxy:diff=N and/or --set pxy@username:diff=N
- Mac OS X: Support for automatic detection of capable devices at startup.
- jingtian: Support for this new platform. Must be compiled on the Raspberry Pi itself with --enable-jingtian
Full changelog:
- lowl-vcom: Added support for auto scanning (-S auto) on Mac OS X
- rockminer: implement --device-protocol-dump for debugging
- README: Update for commandline options
- README: Update configure options
- Bugfix: bfg_gpio_setpin_output: Clear alt-function bits via INP_GPIO macro
- jingtian: Explicitly configure SPI device while opening
- jingtian: Toggle ASIC reset GPIO at startup
- aan: Set defaults as soon as a proc is initialised
- aan: Allow specifying clock as xHEXX for a raw PLL register config
- aan: Include current frequency in RPC status
- aan: Implement --set jtn:clock=MHz
- aan: Logic to calculate PLL configurations for a given frequency
- jingtian: Use SPI enable GPIO to disconnect SPI during chipselect changes
- aan: Set PLL to 850 MHz
- aan: Simplify register buffer
- jingtian: Decode extra temperature bytes in read_reg
- aan: Add a read_reg hook
- aan: Enable configuring nonce diff with (eg) --set jtn:diff=32
- aan: Properly handle nonce_diff
- aan: Implement mining
- DevAPI: Some designs set the main thr tv_poll from secondary thrs, so check it after the loop
- aan: aan_spi_parse_rx implies spi_clear_buf
- jingtian: Do detection asynchronously across all possible chipselects so they complete in parallel
- aan: Refactor aan_spi_cmd a bit
- jingtian: Implement device protocol dump
- jingtian: Detection-only code for new driver
- lowl-spi: GPIO access functions
- lowl-spi: Move knc_spi_txrx to linux_spi_txrx
- SGW: Support for proxy-share difficulty preferences
- SSM: Propagate proxy-share difficulty changes to established connections
- SSM: Track stratum connections for each proxy user
- SSM: Track authorised users for each connection
- SSM: Initialise proxyshare difficulty from --set pxy:diff=N
- proxy: Accept --set pxy:diff=N to set preferred proxyshare difficulty
- proxy: Provide a place to store desired proxyshare difficulty on a per-username basis, and copy it to SSM connections when authorising them
- SSM: Track proxy share difficulties
- Expose target_diff function and add pdiff_to_bdiff macro
- util: double_find_precision function to identify ideal precision for a fp number
- work2d: Expose WORK2D_MAX_DIVISIONS in header
- add_local_gbt: Avoid adding servers already configured
- Bugfix: Avoid writing automatically configured local GBT servers to the config file unless they have been manually enabled
- add_local_gbt: Use rpcconnect when configured
- rockminer: Bugfix: must specify a baud rate (maximum of 115200) to get a read response
- Bugfix: Use atexit() to ensure a final \n is always printed at exit to work cleanly with new logging design
- Restore compatibility with old versions of libblkmaker
- Bugfix: probe for ZeusMiner before probing for DualMiner
- Wait until coinbase-addr is needed again, before updating it following a block change (always using getaccountaddress)
- Don't automatically use #getcbaddr for local bitcoind if the user provided their own
- Bugfix: refresh_bitcoind_address: Check for NULL json (which is not JSON "null")
- Bugfix: add_pool: If no current pool set, initialise it (otherwise pool testing may start a longpoll thread which tries to access currentpool uninitialised)
- devpath_to_devid: *nix: Reject anything that doesn't begin with a /
July 07, 2014, 01:41:53 AM
Awesome! That's exactly what I was looking for! Thanks Luke! 
July 07, 2014, 12:32:50 AM
Can someone give me an example of a bfgminer.conf file that has settings on per-device basis?
I have a few devices that achieve best results at different speeds. So, based on their serial number I want to configure them to start automatically at the desired speed.
(as opposed to me going and adjusting the speeds every time I start them).
Ideally I'd like to have one set of global settings with a few exceptions for this and that device. You can use NFY devices as an example - e.g. this is what I currently have:
I have a few devices that achieve best results at different speeds. So, based on their serial number I want to configure them to start automatically at the desired speed.
(as opposed to me going and adjusting the speeds every time I start them).
Ideally I'd like to have one set of global settings with a few exceptions for this and that device. You can use NFY devices as an example - e.g. this is what I currently have:
Code:
{
"set-device" : [
"NFY:baud=500000",
"NFY:osc6_bits=56"
]
}Code:
{
"set-device" : [
"NFY:baud=500000",
"NFY:osc6_bits=56",
"NFY@serial:osc6_bits=58"
]
} July 07, 2014, 12:17:23 AM
Can someone give me an example of a bfgminer.conf file that has settings on per-device basis?
I have a few devices that achieve best results at different speeds. So, based on their serial number I want to configure them to start automatically at the desired speed.
(as opposed to me going and adjusting the speeds every time I start them).
Ideally I'd like to have one set of global settings with a few exceptions for this and that device. You can use NFY devices as an example - e.g. this is what I currently have:
I have a few devices that achieve best results at different speeds. So, based on their serial number I want to configure them to start automatically at the desired speed.
(as opposed to me going and adjusting the speeds every time I start them).
Ideally I'd like to have one set of global settings with a few exceptions for this and that device. You can use NFY devices as an example - e.g. this is what I currently have:
Code:
{
"set-device" : [
"NFY:baud=500000",
"NFY:osc6_bits=56"
]
} July 05, 2014, 05:27:45 PM
I'm glad to hear you were able to find a working solution for your hardware. To answer your question, using BFGMiner (with or without MultiMiner) I get 2.84 Mh/s per board with 0% HW errors on one and 2% on another. The effective hashrate is about the same (2.79 Mh/s & 2.86 Mh/s).
I'm still not quite sure from your posts what issues you had with BFGMiner. Your last post indicated you were getting the same performance I am reporting, but then you struck through the text.
I'm still not quite sure from your posts what issues you had with BFGMiner. Your last post indicated you were getting the same performance I am reporting, but then you struck through the text.
The problem I encountered was - when I posted my first response, I was getting 2.85mH/s with 2-3 HW's - I left the blades to work whole night - but next day when I saw BFGM(I ran the manual miner through MM) was mining at 3.xxmH/s and there were like 50-70 HW's per blade(and they kept increasing). So I had no other option than to quit. Of course MM has nothing to do with this, but there was no other option available in MM to replace BFGM(I have been using MM since I got my first 280x and it works like a charm for me).
Anyway, thanks
and I hope you get an alternative in MM for these blades if possible.Make sure are looking at the HW %, not the number / count. Most of these numbers are not directly comparable between CGMiner and BFGMiner. It's comparing apples and oranges.
Thanks, I'll make a note of it. Moreover I'm trying to learn and then start using SeedManager as it's more stable and stronger performance-wise.
July 05, 2014, 05:03:39 PM
I'm glad to hear you were able to find a working solution for your hardware. To answer your question, using BFGMiner (with or without MultiMiner) I get 2.84 Mh/s per board with 0% HW errors on one and 2% on another. The effective hashrate is about the same (2.79 Mh/s & 2.86 Mh/s).
I'm still not quite sure from your posts what issues you had with BFGMiner. Your last post indicated you were getting the same performance I am reporting, but then you struck through the text.
I'm still not quite sure from your posts what issues you had with BFGMiner. Your last post indicated you were getting the same performance I am reporting, but then you struck through the text.
The problem I encountered was - when I posted my first response, I was getting 2.85mH/s with 2-3 HW's - I left the blades to work whole night - but next day when I saw BFGM(I ran the manual miner through MM) was mining at 3.xxmH/s and there were like 50-70 HW's per blade(and they kept increasing). So I had no other option than to quit. Of course MM has nothing to do with this, but there was no other option available in MM to replace BFGM(I have been using MM since I got my first 280x and it works like a charm for me).
Anyway, thanks
and I hope you get an alternative in MM for these blades if possible.Make sure are looking at the HW %, not the number / count. Most of these numbers are not directly comparable between CGMiner and BFGMiner. It's comparing apples and oranges.
July 05, 2014, 04:59:13 PM
Thanks for your reply, Nwoolls(you don't reply to pm's 
). I wanted to know MM displays which speed at the "bottom right" of the page? Five second hash-rate, all time average or the current hash-rate?
Thanks
). I wanted to know MM displays which speed at the "bottom right" of the page? Five second hash-rate, all time average or the current hash-rate?Thanks
Current hash rate is shown in the bottom-right.
Questions asked in public benefit other users. Thanks!
After failing to get my g-blades properly work with BFGM ad MM(due to no proper support and lack of interest from me{after 30+ tries also it didn't work for me, and moreover I think like this I'll destroy my equipment!}), I've decided to quit these two applications and hold hands of CGM 3.7.2(jmordica fork) - which has successfully worked for me, up to my expectations!
Now I get around 5.7mH/s(2.85mH/s per blade) on my g-blade, with hardly 1-2 HW's. Thanks to all those who gave a hand of help. I'm glad to hear you were able to find a working solution for your hardware. To answer your question, using BFGMiner (with or without MultiMiner) I get 2.84 Mh/s per board with 0% HW errors on one and 2% on another. The effective hashrate is about the same (2.79 Mh/s & 2.86 Mh/s).
I'm still not quite sure from your posts what issues you had with BFGMiner. Your last post indicated you were getting the same performance I am reporting, but then you struck through the text.
The problem I encountered was - when I posted my first response, I was getting 2.85mH/s with 2-3 HW's - I left the blades to work whole night - but next day when I saw BFGM(I ran the manual miner through MM) was mining at 3.xxmH/s and there were like 50-70 HW's per blade(and they kept increasing). So I had no other option than to quit. Of course MM has nothing to do with this, but there was no other option available in MM to replace BFGM(I have been using MM since I got my first 280x and it works like a charm for me).
Anyway, thanks
and I hope you get an alternative in MM for these blades if possible. July 05, 2014, 04:41:40 PM
In an earlier post, it was correctly stated that Gridseed blades DO NOT support BitCoin mining or Dual mining. Simply, they will overheat and self-destruct if they are instructed to mine BitCoin.
However, the GC3355 ASIC chips that the blades contain have the capability to mine BitCoin, and dual mine BitCoin and scrypt coins. JMordica's fork of CGminer TURNS OFF the BitCoin mining function of the GC3355 chips.
Single-chip GC3355 miners could dual mine without damage. The 80-chip Gridseed blade (containing GC3355 chips) cannot, as stated above.
Does BFGminer TURN OFF the BitCoin mining function of the Gridseed blade? As a previous poster stated, it may be possible to damage a Gridseed blade with BFGminer.
I'd like to use MinePeon with my Gridseed blades, and mine scrypt coin with BFGminer. -Scryptr
However, the GC3355 ASIC chips that the blades contain have the capability to mine BitCoin, and dual mine BitCoin and scrypt coins. JMordica's fork of CGminer TURNS OFF the BitCoin mining function of the GC3355 chips.
Single-chip GC3355 miners could dual mine without damage. The 80-chip Gridseed blade (containing GC3355 chips) cannot, as stated above.
Does BFGminer TURN OFF the BitCoin mining function of the Gridseed blade? As a previous poster stated, it may be possible to damage a Gridseed blade with BFGminer.
I'd like to use MinePeon with my Gridseed blades, and mine scrypt coin with BFGminer. -Scryptr
Yes, both the Orb and G-Blade are treated similarly to dbartle's CGMiner driver: the device is reset and then only the scrypt cores are initialized. When mining with a DualMiner and specifying dual-mode mining, the device is reset and both scrypt and SHA cores are initialized.
SHA cores are never initialized by BFGMiner for any device other than the DualMiner USB stick.
July 05, 2014, 03:43:23 PM
In an earlier post, it was correctly stated that Gridseed blades DO NOT support BitCoin mining or Dual mining. Simply, they will overheat and self-destruct if they are instructed to mine BitCoin.
However, the GC3355 ASIC chips that the blades contain have the capability to mine BitCoin, and dual mine BitCoin and scrypt coins. JMordica's fork of CGminer TURNS OFF the BitCoin mining function of the GC3355 chips.
Single-chip GC3355 miners could dual mine without damage. The 80-chip Gridseed blade (containing GC3355 chips) cannot, as stated above.
Does BFGminer TURN OFF the BitCoin mining function of the Gridseed blade? As a previous poster stated, it may be possible to damage a Gridseed blade with BFGminer.
I'd like to use MinePeon with my Gridseed blades, and mine scrypt coin with BFGminer. -Scryptr
However, the GC3355 ASIC chips that the blades contain have the capability to mine BitCoin, and dual mine BitCoin and scrypt coins. JMordica's fork of CGminer TURNS OFF the BitCoin mining function of the GC3355 chips.
Single-chip GC3355 miners could dual mine without damage. The 80-chip Gridseed blade (containing GC3355 chips) cannot, as stated above.
Does BFGminer TURN OFF the BitCoin mining function of the Gridseed blade? As a previous poster stated, it may be possible to damage a Gridseed blade with BFGminer.
I'd like to use MinePeon with my Gridseed blades, and mine scrypt coin with BFGminer. -Scryptr
July 05, 2014, 03:26:51 PM
Thanks for your reply, Nwoolls(you don't reply to pm's ). I wanted to know MM displays which speed at the "bottom right" of the page? Five second hash-rate, all time average or the current hash-rate?
Thanks
). I wanted to know MM displays which speed at the "bottom right" of the page? Five second hash-rate, all time average or the current hash-rate?Thanks
Current hash rate is shown in the bottom-right.
Questions asked in public benefit other users. Thanks!
After failing to get my g-blades properly work with BFGM ad MM(due to no proper support and lack of interest from me{after 30+ tries also it didn't work for me, and moreover I think like this I'll destroy my equipment!}), I've decided to quit these two applications and hold hands of CGM 3.7.2(jmordica fork) - which has successfully worked for me, up to my expectations!
Now I get around 5.7mH/s(2.85mH/s per blade) on my g-blade, with hardly 1-2 HW's. Thanks to all those who gave a hand of help. I'm glad to hear you were able to find a working solution for your hardware. To answer your question, using BFGMiner (with or without MultiMiner) I get 2.84 Mh/s per board with 0% HW errors on one and 2% on another. The effective hashrate is about the same (2.79 Mh/s & 2.86 Mh/s).
I'm still not quite sure from your posts what issues you had with BFGMiner. Your last post indicated you were getting the same performance I am reporting, but then you struck through the text.
July 05, 2014, 03:20:14 PM
Ty BTW, bout to run sudo make on 4.3 after configures done... will post images of 4.3 hasing my BTC sticks when done since I don't have a zeus yet.
Also, does 4.3 do the "out of box" over clocking to the zeus like it does to the 1.6U2's which is running for m now at 1.9 each.
Also, does 4.3 do the "out of box" over clocking to the zeus like it does to the 1.6U2's which is running for m now at 1.9 each.
July 05, 2014, 03:14:57 PM
Can I use BFGMiner for scryptoins / with the 1.2x Mh/s zeus blizzard devices ?
I have 4.2.0 compiled right now on my rPi with MinePeon. Minepeon I'm sure wont be an issue since it's more or less a pretty interface for bfgminer / cgminer.
I have 4.2.0 compiled right now on my rPi with MinePeon. Minepeon I'm sure wont be an issue since it's more or less a pretty interface for bfgminer / cgminer.
You'll need BFGMiner 4.3 in order to mine with the ZeusMiner ASICs. It works great on the RPi in my testing so should work once MinePeon is updated to 4.3.
July 05, 2014, 03:13:37 PM
Can I use BFGMiner for scryptoins / with the 1.2x Mh/s zeus blizzard devices ?
I have 4.2.0 compiled right now on my rPi with MinePeon. Minepeon I'm sure wont be an issue since it's more or less a pretty interface for bfgminer / cgminer.
I have 4.2.0 compiled right now on my rPi with MinePeon. Minepeon I'm sure wont be an issue since it's more or less a pretty interface for bfgminer / cgminer.
You'll need BFGMiner 4.3 in order to mine with the ZeusMiner ASICs. It works great on the RPi in my testing so should work once MinePeon is updated to 4.3.
July 05, 2014, 02:41:42 AM
Can I use BFGMiner for scryptoins / with the 1.2x Mh/s zeus blizzard devices ?
I have 4.2.0 compiled right now on my rPi with MinePeon. Minepeon I'm sure wont be an issue since it's more or less a pretty interface for bfgminer / cgminer.
I have 4.2.0 compiled right now on my rPi with MinePeon. Minepeon I'm sure wont be an issue since it's more or less a pretty interface for bfgminer / cgminer.
July 03, 2014, 07:56:58 PM
Thanks for your reply, Nwoolls(you don't reply to pm's ). I wanted to know MM displays which speed at the "bottom right" of the page? Five second hash-rate, all time average or the current hash-rate?
Thanks
). I wanted to know MM displays which speed at the "bottom right" of the page? Five second hash-rate, all time average or the current hash-rate?Thanks
Current hash rate is shown in the bottom-right.
Questions asked in public benefit other users. Thanks!
Thank you
After failing to get my g-blades properly work with BFGM ad MM(due to no proper support and lack of interest from me{after 30+ tries also it didn't work for me, and moreover I think like this I'll destroy my equipment!}), I've decided to quit these two applications and hold hands of CGM 3.7.2(jmordica fork) - which has successfully worked for me, up to my expectations!
Now I get around 5.7mH/s(2.85mH/s per blade) on my g-blade, with hardly 1-2 HW's. Thanks to all those who gave a hand of help. Thank you
July 03, 2014, 07:33:23 PM
Thanks for your reply, Nwoolls(you don't reply to pm's ). I wanted to know MM displays which speed at the "bottom right" of the page? Five second hash-rate, all time average or the current hash-rate?
Thanks
). I wanted to know MM displays which speed at the "bottom right" of the page? Five second hash-rate, all time average or the current hash-rate?Thanks
Current hash rate is shown in the bottom-right.
Questions asked in public benefit other users. Thanks!
Jump to: