Diff 0? That looks wrong. Have you tried a different (working) pool?
Diff 0 is normal for scrypt. |
|
|
|
Well my order is for BJ #39 and I have not received a tracking number so they can not have sent many out. Also the ToS is a contract between you and HF. Just because they sent out one unit to a developer does not mean they met the 'guaranteed delivery' deadline. http://hashfast.com/order-chain/I am not intending to comment on whether HF has met their deadline or not. Also, my unit is not a developer sample. I paid for it (HashFast is probably the only business ASIC manufacturer so far which hasn't provided a sample unit for BFGMiner dev). The fact that only Luke-Jr confirms shipping does sound a lot like BFL. In order to win a bet that BFL would ship the first units before April 01 2013 they sent 1 unit to Luke-Jr. However it was never actually shipped because Luke decided to leave it at BFL. It took until July for day 1 customers to receive their units. https://bitcointalk.org/index.php?topic=163261.0I only say it how it is. Neither BFL's developer-friendliness nor HF's lack thereof are at all relevant to the fact that FedEx called me and (among other things) gave me a tracking number. |
|
|
|
We have internal test systems. A few of them, like the Baby Jet in our office that is part of the Eligius mining pool, are doing actual mining. This is to do a full, end to end, system test. A much better test would involve mining the entire historical blockchain. That is, setup a pool server that feeds jobs with known blocks, and make sure you find them all. This is no different than "real-world mining" except that you are doing it with historical data that miners would have gotten before each of those blocks. Unrelated to this, I see no reason manufacturers shouldn't be mining mainnet as they do burnin as long as they are honest with the customers. Where are our tracking numbers?  I have my tracking number, but not from HashFast (FedEx called me to confirm some details on the shipment). I presume this means they've begun shipping, even if they haven't given out the tracking numbers yet... |
|
|
|
bfgminer is streaming output rather than holding it in a block of text, but i think this might be bacuase i've ssh'd onto the ubuntu box.
Compiled without curses support. |
|
|
|
Since I'm not in the business of disclosing private datas, I'll simply point out that 1Nbq2XZaRsKknf5fcT2wTXvBS31PaUWSeX is NOT Hashfast. From a public key alone, you could not know for sure who any of your miners are. A pool operator could also state this based on IP address(es), fingerprinting the hardware, etc... or simply knowing who that address really is! |
|
|
|
They've been using gmail servers to send their @hashfast.com email.
For the recent emails, yes. The headers of this one, tough... Received: by 10.194.138.199 (10.x is a reserved block, can't be the correct ip) with SMTP id qs7csp90853wjb;
Fri, 16 Aug 2013 16:38:36 -0700 (PDT)
X-Received: by 10.236.45.102 (same here) with SMTP id o66mr196684yhb.13.1376696316262;
Fri, 16 Aug 2013 16:38:36 -0700 (PDT) 10.x is a local block, and probably is the correct IP... |
|
|
|
Hi Luke-Jr
Do you have any information yet, regarding the AntMiner u1 from BitMain?
They will be starting to ship in bulk, in the next few days.
I have a sample unit and some cgminer-specific code. I believe I have some documentation too, but not sure if it applies to these units or is up to date. There is a bitmain-asic.ko in the bundled OpenWrt firmware, which I do not see code for. Lately, I have been moving to my new house. Not 100% done yet, but I need to be able to claim it as my primary residence before 2014, so that is my top priority for now. That being said, I plan to spend time looking more into writing a BFGMiner driver for AntMiner in the next 48 hours. If I need to reverse engineer the protocol from cgminer code, it will probably take longer than that to have it working. If anyone wants to help me get this going faster, a PM with the most recent specs (if they exist) and/or bitmain-asic.ko source would be helpful. |
|
|
|
Where did that extra 25BTC come from? I thought based on CPPSRB, the pool would not have any reserved fund and all shelved shares will be paid for. Its essentially max at PPS.
If the same thing happened as last time, it will come out of wk's pocket. So the pool's wallet and his personal wallet is one? Because otherwise he would have noticed the double payout or the server wouldnt have made the double payout due to empty balance. Uh, you must be new here. Eligius generates payouts, they don't come out of a wallet except in rare cases. |
|
|
|
Did you even read the quote? The quote about BFGMiner was pulled directly from Google's first search result of BFGMiner. It's not a bitcointalk thread, it's directly from BFGMiner.org, and says so in the quote. It is BFGMiner.org's own advertisement. BFGMiner.org is a fan site and completely unofficial. Why would someone bother maintaining a 'Scrypt side' of BFGMiner instead of just building a pure Scrypt mining engine? Eh, you have that backward. Maintaining scrypt support for BFGMiner is far less work and more rational, than building a pure scrypt miner. Bitcoin may have the market share, but Scrypt coins are taking over. The GPU market is huge, and deserves it's own dedicated software. lolwut, this is just delusional. scrypt is a failed experiment, used only by scam "altcoins". |
|
|
|
So wk, you're saying the double payment has caused you to lose 25BTC?
Where did that extra 25BTC come from? I thought based on CPPSRB, the pool would not have any reserved fund and all shelved shares will be paid for. Its essentially max at PPS.
Since you're not honest about the problem, dont be offended if i dont trust your whole payout system. (I understand the payout method)
Obviously he's covering it out of pocket. I don't know what you're accusing him of being dishonest about...  |
|
|
|
Luke-jr, I see you are online, is 3.9 ready for the antminer U1? I've got a bunch of those showing up this coming week.
Please re-ask this somewhere it's on topic (BFGMiner or AntMiner threads) and point me to it... |
|
|
|
You will need to compile from source to get the most recent version
Hi, that i know but in the release info is written that i can direct install the latest version with pacman. Some distros take a while to update when new versions are released. I don't maintain those. |
|
|
|
What's the point to removing ASIC/FPGA/SHA2 support?
If someone wanted an enhanced scrypt miner, the logical move would be to join the BFGMiner team and improve it there...
What was the point in removing GPU support from CGMiner after 3.7.2? The point is to promote GPU mining software development, with a GPU specialized mining software tool. Who knows. cgminer isn't exactly a sensible choice in the first place. BFGMiner 3.9.0 still has CPU and GPU support. BFGMiner - a modular ASIC/FPGA Bitcoin miner
bfgminer.org/
BFGMiner. a modular ASIC/FPGA Bitcoin miner. Last version: 3.9.0. Windows 32bit - Windows 64bit. Ubuntu: PPA mantained by "unit3" Arch: pacman -S ... Why would the logical move for an individual, that uses GPUs for mining, to help support an application (BFGMiner) that bills itself as an ASIC/FPGA Miner? ASIC/FPGAs quite literally killed SHA256 GPU mining. Its a competition. Keep Scrypt GPU hash rates/watt high enough, FPGAs look much less attractive, slowing sales and development; keeping Scrypt GPU only, longer. That to me is the logical move. You're quoting from a Bitcoin forum post. scrypt is not Bitcoin. Someone who takes over maintaining the scrypt side for BFGMiner is welcome to advertise it differently. |
|
|
|
Luke-Jr, any idea if/when the Hashfast Micro boards will be back in stock?
Hashbuster, not HashFast! But no, I have no idea when/if they will produce more. |
|
|
|
BFGMiner is a great application for running multiple cubes in one easy interface. However, I have found that it comes with a slight decrease in performance on cubes and Blades. Evidence/explanation? Are you sure this isn't due to BFGMiner identifying/reporting HW errors (and slush's proxy does not do this AFAIK)? |
|
|
|
|
What's the point to removing ASIC/FPGA/SHA2 support?
If someone wanted an enhanced scrypt miner, the logical move would be to join the BFGMiner team and improve it there...
|
|
|
|
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. |
|
|
|
NEW VERSION 3.9.0, DECEMBER 25 2013Merry 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
|
|
|
|
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. |
|
|
|
|
I've seen documentation for the bitfury chip, bi*fury (not sure why it's mentioned here though..), and the mcp2210 chip in nanofury.
|
|
|
|
|
Show Posts
