Bitmain published instructions for building firmware images somewhere (sorry, it's been too long; I don't have the link anymore), but I was unable to get them to work on my 32-bit Gentoo system (you may have better luck on a 64-bit Ubuntu).
I think i found it btw got BFG working on A s1 and S3 now using openDrt .  . Great news. What is the hashrate like? Same as the original firmware? Better? Worse? |
|
|
|
Well how i understand pps the pool accepts all the shares submitted by the miner and rewards them predetermined about based on the current network diff. no block confirms are attached to the payment and of course the pools fee for the risk of no block confirms
Thats straight PPS, yes. No pools do this anymore since there is just too much risk involved. There is essentially no reasonable fee that a pool could set to ensure they can pay a PPS rate. Apparently F2Pool is 4%-fee PPS, and AntPool offers 2.5%-fee PPS. I have not confirmed if they actually are straight PPS though. |
|
|
|
|
Bitmain published instructions for building firmware images somewhere (sorry, it's been too long; I don't have the link anymore), but I was unable to get them to work on my 32-bit Gentoo system (you may have better luck on a 64-bit Ubuntu).
|
|
|
|
The startup rejects are because they never difficulty for the first job, and don't send a new job for some seconds after you login. But then they reject shares that meet the initial difficulty (1). What cgminer does, is to apply the first set_difficulty retroactively to any jobs received without a known share difficulty. I considered making this change in BFGMiner also, but decided against it, because for a compliant stratum pool (where the initial difficulty is in fact valued as 1), this would result in losing credit for all the shares found against that first job. On the other hand, for CKPool-based servers, the only downside of BFGMiner's stratum-compliant behaviour is that it counts those shares as rejects. Unless your pool is penalising you for rejected shares, this shouldn't matter (and if they are, especially when they're at fault for those rejects as is the case here, I suggest using another pool!). As an aside, CKPool appears to have a bug in stratifier.c line 3112-3114: /* Accept the lower of new and old diffs until the next update */
if (id < client->diff_change_job_id && client->old_diff < client->diff)
diff = client->old_diff; This will cause miners which strictly comply with the stratum spec to have shares at the new difficulty valued only at the old one. So if the share difficulty adjusts from 1024 to 512 (for example), stratum says shares for the old job should continue to be submitted only if they meet difficulty 1024. However, CKPool will only "count" those shares as if they were difficulty 512, at half their proper value. This is a potential loss for miners, but probably insignificantly small. Given their history of ignoring and/or trolling bug reports from me, I have not bothered to report it. But please feel free to do so if it matters to you. |
|
|
|
|
FWIW, BFGMiner can theoretically go up beyond 1000 MHz now... try at your own risk :p
|
|
|
|
|
BTW, anyone want to go and update README with all these tips I've been dropping on the forum thread(s)? :p
|
|
|
|
--set bfl:voltage=<whatever> should work. You really don't want to set it on all devices though - they can be very different in what is sane there - so just use bfl.
This is actually what I would like to be able to do on my 2 AntMiner U3' as each of them does not behave the same on a single setting of frequency and voltage. How would I be able to set different frequency and voltage settings for each miner on a single BFGMiner process? I know that the workaround for this is to have 2 separate BFGMiner processes to manage the 2 miners individually. or --set antminer@/dev/ttyUSB1:voltage=xNNNNAnother option is to program the CP2102 chip so they have unique serial numbers; this method would avoid problems with the device showing up on different tty/COM locations after reboot/hotplug. ./cp210x-program -w -F eeprom-content.AntU3-custom.hex --set-product-string='Antminer U3' --set-serial-number=myveryown0001Then you can use --set antminer@myveryown0001:voltage=xNNNN |
|
|
|
I have a suspicion that some mining hardware out there may be software time bombed and have miners who are using the hardware unknowingly withholding blocks sometimes. Unfortunately there is next to zero chance of verifying this in our lifetimes. Given that luck has been crap across basically every pool with accessible stats I think it's a pretty plausible conspiracy theory. It also makes some logical sense given that some of the largest miners today are sellers of ASIC mining hardware. Basically would effectively cut into their customers' profits (withholding some of their blocks) and increase their own (by keeping the network difficulty increase lower than the amount of hardware sold, plus they could obviously disable any time-bomb code when using the hardware for themselves).
interesting allegation...it would be absolutely scandalous if true, to the point of no one in their sane mind would buy anything from that company again. Can any sophisticated coder explore the binaries to check for such potentially withholding code? Which standalone miners are we talking about? Spondoolies lacks motive - afaik they aren't self-mining. Also their minergate has been open source from the start. Bitmain recently released complete source code for at least the S5 controller. Their previously-closed kernel module is aware of blocks, but only writes to a log when it sees them - nothing seemed suspicious there. It's conceivably possible that it used to do something different before the code was published, but... Their self-mining operation is so large, they would need to have their admins install non-public firmware images, and someone I know who has such a position was never told not to use the public firmware. BFL's Monarchs are controlled by a PC, and the miner itself has no way to really do this. Avalon 2 and newer do most of the heavy lifting in FPGA, but that is open source and I didn't notice anything odd looking at it a while ago. |
|
|
|
Is there a way to put the voltage in the bfgminer.conf file now that bfgminer supports changing voltages? And if so what format? I set the cutoff temp like this "set-device" : [ "all:temp-cutoff=78"] and wonder if something similar for voltage? --set bfl:voltage=<whatever> should work. You really don't want to set it on all devices though - they can be very different in what is sane there - so just use bfl. |
|
|
|
|
Also, I don't know what version slush upgraded from, but there have been no noteworthy changes between 0.10.1 and 0.11.1 that would affect stale blocks (nor is it possible to affect luck).
|
|
|
|
So Slush's Pool posted a news update regarding recent orphaned blocks: https://mining.bitcoin.cz/news/recent-orphaned-blocks-explanation/I'd be very interested to hear from wizkid057 or Luke-Jr on whether we are also watching our pool; what version of bitcoind Eligius is based off, and whether block submission propagation times are being monitored at all. I'm not just asking because of our terrible luck as of late, which I understand is entirely by chance, but also because having more information on the internal operation of the pool and block submission/fast block relay statistics! The main bitcoind is running a 0.10.1-based bitcoind. (I don't know how to get info on the other bitcoinds.) Note that luck is not related to stale blocks (what slush erroneously calls orphaned/invalid). |
|
|
|
Has anyone noticed some "sweetspots"? My sticks runs @150 MHz with a few HW errors (about 3-5/day) but with the same setup @160 MHz with no errors for days!
I run at 275 MHz with <0.01% hw errors... |
|
|
|
I just compiled BFGMiner 5.4.0 and it works fine managing my 2 AntMiner U3'.  However, I actually only want to have antminer driver for connecting to stratum server. I tried to disable all drivers but icarus using the configure option below. CONFIGURE_ARGS += --disable-other-drivers
CONFIGURE_ARGS += --enable-icarus
But as we can see above, other drivers are still being included. How do I actually disable all drivers but only the ones for Antminer U3? cairnsmore, compac, erupter, and icarus are all tied in with antminer, so you won't be able to skip them. |
|
|
|
|
The KnCMiner Jupiter instructions in README.ASIC might work on the S5 (but change --enable-knc to --enable-bitmain)
|
|
|
|
NEW VERSION 5.4.0, OCTOBER 23 2015Human readable changelog:- RPC: Ability to change pool management strategy.
- Pool option #cksuggest to use CKPool-compatible mining.suggest_difficulty stratum extension.
- alchemist: New scrypt ASIC driver, written and maintained by jstefanop (requires custom FPGA reprogramming).
- antminer, avalon, compac, hashfast, and jingtian: Support for setting clock frequency from the TUI's device management interface.
- antminer & compac: Support for setting clock by frequency MHz.
- bitforce: Ability to change voltages from RPC and TUI.
- bitmain: New driver for Bitmain Antminer S-series units (up to S5).
Full changelog:- AUTHORS: Move jstefanop to current maintainers
- Disable alchemist by default, add Travis build, and document configure option in README
- alchemist: New scrypt ASIC driver
- hashfast: Support setting clock speed from TUI Manage
- avalon: Support setting clock speed from TUI Manage
- antminer: Support setting clock speed from TUI Manage (hidden for non-BM1382/4 devices)
- jingtian: Allow changing clock speed from TUI
- Debuglog for retrodiff being disabled
- Disable retrodiff when it was not explicitly enabled, and the pool doesn't seem to like it
- Bugfix: Only adjust work_difficulty on retrodiff submissions, so we can still detect them on rejection
- (Re-)enable retrodiff by default for stratum pools, since some servers implement mining.set_difficulty wrong in this way
- New pool option "retrodiff"
- If a share passes difficulty check for the updated pool target, record that target for correct accounting of diff_stale.
- DevAPI: Remove unused temporary variable from driver iteration
- README.ASIC: Expand Antminer S5 section to S1-S5 for completeness, since in theory they should work
- bitmain: Make reg_data optional for S4 and S5, calculating it from clock
- Document Bitmain Antminer S5 support
- bitmain: Remove poll_prio_threshold and just ensure we poll at a regular interval to avoid nonce buffer overruns
- bitmain: Remove dead per-device constants
- bitmain: Only have one set of actual maximums
- bitmain: Migrate BITMAIN_MAX_NONCE_NUM to runtime packet_max_nonce
- bitmain: Migrate BITMAIN_MAX_WORK_QUEUE_NUM/bitmain_work_poll_prio to runtime poll_prio_threshold
- bitmain: Migrate BITMAIN_MAX_WORK_NUM to runtime packet_max_work
- bitmain: Dummy model parameter
- bitmain: Remove baud/flush, as the fake VCOM kernel driver ignores (and complains about) both
- bitmain: Poll after queuing work, once enough is queued
- bitmain: Sleep a little between polling
- bitmain: Flush queues for work restarts
- bitmain: Queue multiple works at a time
- bitmain: Remove more dead code
- bitmain: Prune old work eventually
- Bugfix: bitmain: Properly count work-search failures as HW errors
- bitmain: Refactor to work with minerloop_queue (leaks work memory)
- bitmain: Avoid busy-looping on network devices
- bitmain: Support for talking to a device over the network
- bitmain: Use the hottest reading for device temperature
- Bugfix: bitmain: Actually use baud setting
- bitmain: Remove more dead code
- bitmain: Handle stale results normally
- bitmain: Simplify num2bit
- bitmain: Initial set-device based configuration
- bitmain: Use lowl-vcom abstractions
- Update copyrights
- Bugfix: bitmain: Type-safe printf-format usage
- Travis: Test bitmain-only build
- Build bitmain driver
- bitmain: Hardcode configuration for now
- bitmain: Rework nonce_diff handling
- bitmain: Update headers
- bitmain: Deal with unused variable warnings sanely
- bitmain: Explicitly de-const device_path for freeing
- Bugfix: bitmain: Correct type of cgpu->temp reference
- Bugfix: bitmain: Use uint8_t consistently for binary data
- Bugfix: bitmain: Clear opt_bitmain_dev string properly
- bitmain: Remove non-existent bitmain_detect parameter
- bitmain: Cleanup unnecessary code
- bitmain: Use uthash to find queued work
- bitmain: Implement inc_dev_status within record_temp_fan
- bitmain: Remove non-applicable limits
- bitmain: Remove obsolete get_statline_before function
- bitmain: Move g_miner_version to bitmain_info struct
- bitmain: Remove direct USB code
- bitmain: Update driver registration
- bitmain: Update symbol names
- bitmain: Remove dead code
- bitmain: Replace custom hexdump with normal bin2hex
- bitmain: Get network difficulty from first work task
- bitmain: No-op htole8
- bitmain: Simulate cgminer work_block somewhat
- bitmain: Update bin2hex usage for malloc-free version
- bitmain: Copy low-level code from Bitmain cgminer usbutils
- Copy working driver-bitmain.c from Bitmain's cgminer at commit 4ecf89341657ea7efecdf588586ca3f068ab17ab
- Add api_add_percent to miner.h
- Bugfix: DevAPI: Update includes from uthash to utlist and support older versions of uthash
- Bugfix: RPC: Need to include utlist.h for config file list
- Bugfix: antminer: Avoid NULL dereference for non-BM1382/4 devices
- README.ASIC: Update documentation for BM1382/4 clock calculation support
- antminer: Support for setting BM1382/4 clock by frequency MHz
- Bugfix: Keep JSON from getaccountaddress around long enough for debug messages
- Bugfix: Run gen-version.sh from source directory
- Fix to enable building into directory out of source tree
- Bugfix: Clean up JSON from getaccountaddress
- Bugfix: Do not use hash tables for driver lists, since they require unique keys
- Pool option #cksuggest to use CKPool-compatible mining.suggest_difficulty
- RPC: Add "Rotate Period" to config
- RPC: Extend setconfig to change strategy
- Allow setting strategy by name
- bitforce: Enable changing voltage from the Manage TUI
- avalonmm: Use proc_set_device_tui_wrapper instead of avalonmm_tui_wrapper
- DevAPI: Add generic proc_set_device_tui_wrapper
- bitforce: Add "voltage" setting to send V?X commands
- Bugfix: compac: Set dname so assignments match
- README.RPC: Add missing setconfig|stratum-port documentation
- README.RPC: Add missing setconfig|http-port documentation
- Bugfix: lowl-vcom: Check for tcgetattr/tcsetattr/tcflush failure
- configure: List compac driver in output
- Travis: Workaround Travis bug
- configure: Use AC_PROG_SED to find sed
|
|
|
|
As an aside, the RPC way of adjusting frequency is pretty darn cool since you can do it while they are running. Couple that with the adjustable voltage, also while running, and you've got real time feedback from a very customizable piece of hardware!
Don't forget bfgminer-rpc "zero|all,false" for that, too! I'm also adding the ability to change the clock frequency from the TUI interface directly. |
|
|
|
Note --set cbm:clock=xNNNN will also work; you just need to abbreviate it "cbm" and can't spell out "compac".
(That's what is being fixed in 5.4 - being able to spell it out)
I was unable to get --set cbm:clock=xNNNN to work. I believe you said you used it on the pre-production stick that was sent to you, but I cannot duplicate your success on the production stick. I assumed that your problem was the extra leading zero... no? :/ Can anyone else with a prod unit confirm/deny a problem? I can't imagine what would be different.. :| |
|
|
|
|
Note --set cbm:clock=xNNNN will also work; you just need to abbreviate it "cbm" and can't spell out "compac".
(That's what is being fixed in 5.4 - being able to spell it out)
|
|
|
|
I'm sure it's in here somewhere, but how do I run Gridseed 5 Chip miners on both SHA and Scrypt on 2 different pools through BFGMiner?
My understanding is that while the Gridseed ASIC supports both algorithms, the 5-chip orb is not designed to support SHA2 (due to heat). Regardless, BFGMiner does not support running it in SHA2 mode. |
|
|
|
Also note that BFGMiner 5.4 will support setting Compac clocks as the MHz number directly.
Nice, i have one customer that was running BFG and switched to cgminer because somehow he couldn't attain more than 12 GHs with these sticks. Is this a known issue, or should i debug it further? I have no problem getting 15 Gh/s myself. |
|
|
|
|
Show Posts
