My single got the new bitstream, but doesn't seem to be going any faster. I dunno if cgminer has an indicator for the number of times it has throttled, but it is currently at 826/803 5s/avg speed. The test went through without a hitch, but it sure isn't going at 860+ mhash/s.
Certain older versions of the single need a power-cycle after firmware upload. Regards, BF Labs Inc.
|
|
|
[...] Professional users may use their miner of their choice. [...]
Regards, BF Labs Inc.
Not to claim I'm a professional user, but I'm a Linux only one. Any chance to also get the FW-upload command sequence documented? Would be great not to have a spare Windows machine available just to update the Single's firmware. Or would that work from within a VM? Firmware upload is a proprietary mechanism, which I'm afraid we cannot disclose. For your information, it will work flawlessly through a VM. Minimum requirement is Windows XP SP2. Regards, BF Labs Inc.
|
|
|
Any way to allow us to mine where we want,pools other than Eclipse??
Did BFL answer this or am I just blind? We must say that the Easyminer was designed to target novice and new users. Professional users may use their miner of their choice. This is our first release and in the future, other pools will be added to Easyminer. Regards, BF Labs Inc.
|
|
|
We've forgot to mention one small thing. The blink command for the units is 'ZMX'. Unit only accepts this command and does not reply to it. Once sent, the unit will blink for a small period of time.
Regards, BF Labs Inc.
|
|
|
We will provide you with different firmwares at different speeds. Once you upload a firmware to a unit, it will stay in the unit until you upload another firmware. So in other words, if you upload 768MH/s firmware, then your unit will perform 768MH/s (regardless of what miner you use or how many times the unit is switched on and off) until another firmware is uploaded.
Regarding the Eclpise pool, I must say that no forcing was ever intended. We may add more pools in the future, but at the time being, Eclpise is integrated due to technical reasons and ease of integration/coding.
Regards, BF Labs Inc.
When do you expect the different speed firmware to become available for download? In a few hours...
|
|
|
Do the speed changes done by Easyminer shown here: http://www.butterflylabs.com/drivers/ "stick"? In other words, can I use Easyminer to change the speed of the device and then go back to cgminer and run at that speed? Inaba has a reputation for being abusive and abrasive in these forums. I have no desire to being forced to mine on his pool. (He's called me stupid before just for voicing my opinions). We will provide you with different firmwares at different speeds. Once you upload a firmware to a unit, it will stay in the unit until you upload another firmware. So in other words, if you upload 768MH/s firmware, then your unit will perform 768MH/s (regardless of what miner you use or how many times the unit is switched on and off) until another firmware is uploaded. Regarding the Eclpise pool, I must say that no forcing was ever intended. We may add more pools in the future, but at the time being, Eclpise is integrated due to technical reasons and ease of integration/coding. Regards, BF Labs Inc.
|
|
|
When i download the EasyMIner i get virus a warning from Aviar Anti-virus business is one tricky business. They make most of their money by falsely claiming virus existance and the fact that they wiped it out, so now you are safe. Either way there is no virus in easyminer. It is fully written by Butterflylabs Inc. Not a single component, DLL, library or any other third party software has been used in easyminer. The code is a little more than 15,000 lines so far. Regards, BF Labs Inc.
|
|
|
I just looked at their site and downloaded their new EasyMiner. I'm on my playbook atm, so that's not going to do me much good. Has anyone started using it yet? I'd like to see some screenshots! Interesting. I forgot to shut off cgminer first, so it seems to have hung here. Not sure whether to abort or not. I hit the "run a test" button, and the small box popped up saying it was going to do a firmware update. EDIT: I hit "abort" and it changed the display to "aborting..." but still didn't close. I then closed cgminer and nothing changed. I started cgminer again, and it started mining as usual. I don't mind if these windows want to take their time closing, but they are modal on top of everything so they are annoying. EDIT EDIT: I hit "quit' in the main window, and it quit instantly. The $64,000 question is: Did they include new firmware that performs better than the typical 826 MH/s? If they had I'm sure there'd be a thread from BFL here stating they have a new feature available along with some CAD drawings or something Well there are two things I must point out: 1) This is a beta release, and the idea behind this release is to enable users to manually adjust the operating speed of the units. The slower the unit runs, the more resistant it will be to warmer environments (and as a result, unit will no longer throttle). Of course we have not officially announced it yet. An updated version will be available in about 12 hours, which will remove the dummy screen seen when 'Run a test' is clicked and will also have some other changes. 2) The unit runs at exactly 832MH/s. This means that it will always take the unit exactly 5160ms to complete the whole 4 billion nonce check. Any number that is provided by pools or different miners, will not be very accurate since it takes job-availability, network latencty and nonceless jobs into consideration. These factors do not affect the hash speed of the unit.
|
|
|
Polling over sychronous was chosen for several reasons:
1) Unit can respond to other commands while it's processing other data/tasks (e.g. Temperature-reading, new job request while the previous one hasn't finished, etc)
2) Polling is very easy to implement in opensource softwares. Synchronouse design will face all kinds of different challenges during development/debug cycle.
3) And most important of them all, designing multi-thread applications that can communicate with BFL units operating in an asychronous environment is a lot easier than designing the same system in a synchronous environment.
Please let me know if you have other questions.
Good Luck, BF Labs Inc.
Could you then add a "wait for end of work" command (with an optional timeout) that could be used alternatively to asking "are we there yet" repeatedly ? It is possible, but what will be the gain? The latency of a kernel-wait object (or read) can be several milliseconds. It won't be much different from the polling. However, I'm interested to know how it can help. Please give me a few examples. Regards, BF Labs Inc.
|
|
|
During throttle, the device does respond to temperature read, status read, etc. A new job, however, cannot be issued, as the unit will respond with 'BUSY'.
Good Luck,
What I mean is that: if I see a temp (ZLX) of 49C is that the same number tested by the throttling firmware that decides to throttle the BFL? So whatever the first throttling temperate is inside a BFL (when it first drops below 832MH/s), I should see (ZLX) close to that "throttling temperature" just before it decides to throttle? This is true. Should your unit for instance throttle at 67C, then that is usually the throttle threshold of your unit. Of course, the unit must be in the same condition as it was the first time (enclosure closed/open, number of fans active, etc). Should one factor change, the throttle temperature will change with it. Good Luck, BF Labs Inc.
|
|
|
My unit normally shows 52-62C. The absolute highest I have seen myself was 62C. I am not sure it is throttling. The LED never blinks. The grating on the side shows 69.4F. The only thing that makes me think something is wrong is a 24 hour average under speed. I have stared at the LED for more then an hour at a time. Would the throttling be short enough that if I blink I would miss it? It flashes the 2 internal LED's every about 10 seconds. The single rearward LED stay lit. The front only blinks on start up. I will move the unit to a location that I can check the lower heatsink tomorrow. I have already pushed both pins down to check their seating but both are fully down. Unless I missed some clips it is properly held down.
Thank You for the suggestions. I will post more when I know more.
Dear Askit, The internal LEDs blink every time a new job is about to be processed. This should happen exactly ever 5 seconds (5100 ms). Should the interval be higher than 5 seconds, then it indicates that the unit is not receiving job fast enough from the host. Of course at this point I think it does blink every 5 seconds, and the 10 seconds you mentioned was an estimation. The front LED is what counts. If it blink anytime after startup, it indicates a throttle. Usually the throttle lasts about 15 seconds. Good Luck, BF Labs Inc.
|
|
|
During throttle, the device does respond to temperature read, status read, etc. A new job, however, cannot be issued, as the unit will respond with 'BUSY'.
Good Luck,
|
|
|
As you may know, the BFL single, while being a great mining asset, cannot be used efficiently with P2Pool. The reason for this is that P2Pool has a share time of 10 seconds, on average, and the BFL single scans a whole 2^32 nonce range before reporting results. This means it constantly ends up doing stale work. Scanning a whole nonce range on a BFL single takes about 5 seconds. Here are the firmware modifications that would be required to use BFL singles on P2Pool: - Add a new "ZDX"-like command that accepts a nonce range to scan, this would add communication overhead, but would allow the mining software to control the maximum work change latency. This would work pretty much like the cgminer -I "intensity" to control the work batch size. This would also allow splitting a single getwork across multiple devices. While not perfect in isolation, this modification should be simple enough and would make mining on P2Pool at least possible.
- Make the new "do work" command abort and replace the current work. This would lower the reaction time to a longpoll significantly. Somewhat harder to implement than the previous change, but should still feasible with the current hardware (taking a guess here).
- Once a nonce that hashes to an acceptable value, report the finding to the host immediately instead of waiting for the end of the work batch. This change is much harder than the others, since it requires modifying the hashing inner-loop and would break the current protocol. This would reduce stales significantly.
I would greatly appreciate if someone from BFL can ring in on this and tell us if it is at all possible. These changes would preferably only require a firmware change, but I don't know if this is possible as the BFL hardware is a black box (pun intended). Any and all comments welcome. New commands (Including new job-issuing command and new status-read command) will be added to the future firmware. This will include nonce-range selection and other changes/improvements that we decide to present. Full specification of new commands will be published as soon as they are finalized. Good Luck, BF Labs Inc. Whatever you do, try to avoid having the host poll the BFL device like crazy, try to be somewhat asynchronous if you can. Polling over sychronous was chosen for several reasons: 1) Unit can respond to other commands while it's processing other data/tasks (e.g. Temperature-reading, new job request while the previous one hasn't finished, etc) 2) Polling is very easy to implement in opensource softwares. Synchronouse design will face all kinds of different challenges during development/debug cycle. 3) And most important of them all, designing multi-thread applications that can communicate with BFL units operating in an asychronous environment is a lot easier than designing the same system in a synchronous environment. Please let me know if you have other questions. Good Luck, BF Labs Inc.
|
|
|
As you may know, the BFL single, while being a great mining asset, cannot be used efficiently with P2Pool. The reason for this is that P2Pool has a share time of 10 seconds, on average, and the BFL single scans a whole 2^32 nonce range before reporting results. This means it constantly ends up doing stale work. Scanning a whole nonce range on a BFL single takes about 5 seconds. Here are the firmware modifications that would be required to use BFL singles on P2Pool: - Add a new "ZDX"-like command that accepts a nonce range to scan, this would add communication overhead, but would allow the mining software to control the maximum work change latency. This would work pretty much like the cgminer -I "intensity" to control the work batch size. This would also allow splitting a single getwork across multiple devices. While not perfect in isolation, this modification should be simple enough and would make mining on P2Pool at least possible.
- Make the new "do work" command abort and replace the current work. This would lower the reaction time to a longpoll significantly. Somewhat harder to implement than the previous change, but should still feasible with the current hardware (taking a guess here).
- Once a nonce that hashes to an acceptable value, report the finding to the host immediately instead of waiting for the end of the work batch. This change is much harder than the others, since it requires modifying the hashing inner-loop and would break the current protocol. This would reduce stales significantly.
I would greatly appreciate if someone from BFL can ring in on this and tell us if it is at all possible. These changes would preferably only require a firmware change, but I don't know if this is possible as the BFL hardware is a black box (pun intended). Any and all comments welcome. New commands (Including new job-issuing command and new status-read command) will be added to the future firmware. This will include nonce-range selection and other changes/improvements that we decide to present. Full specification of new commands will be published as soon as they are finalized. Good Luck, BF Labs Inc.
|
|
|
Still I agree the airflow seems .... inefficient (I am trying to be more nice).
Hi D&T, Can you arrange the boards within the enclosure to make the airflow more efficient and share it with BFL? Thanks, gigavps BFL can the boards function removed from the rig box and connected to a host PC via USB just like the single's do?The individual boards are fitted with functional USB & 5.5mm barrel Power jack. However, the in box connectivity & power are provided by a proprietary link system connecting to the Motherboard. If you remove a card, you can run it on it's own like a Single. Singles can also be run inside the Mini Rig enclosure, but only via USB. This hasn't been mentioned yet but the Mini Rig comes with a Raspberry Pi mounting rack for self hosting capability. This would also be used for running non Mini-Rig link enabled PCB's. Regarding the airflow, I appreciate your thoughts. I think it's a good idea. We came to a somewhat similar conclusion. The arrangement illustration isn't an accurate representation of the final design, it's just an an illustration of the modular design. The key difference is inverted trays with baffles to trap 2 levels of hot air in 2 powered air exhaust channels. So will a linuxcoin or bamt run on a ras pi(or does it need to be ported for arm arch.) and then we can run the mini rig off that? Is BFL going to release their own os for this including easy miner? This sounds awesome but i am curious. The only thing required to run cgminer/ufasoft is a linux kernel and some third-partie libraries installed. Since they are console applications, no special UI is needed. One can access it through SSH remotely. Should anyone be interested in BAMT or other linux distros, then they must be recompiled for ARM architecture. We haven't look into any of that yet, but we will at certain point in the future... Good Luck,
|
|
|
I really don't know if the singles will ever be 'In stock'. BFL what kind of power supply will this use? Can it be located in the chassis? It doesn't look like it, probably external. PSU will be included with the unit, and it will be inside the enclosure...
|
|
|
Has ANYONE in the UK received their unit ?
Anybody in the EU ?
What are the costs of import.
BFL, any news on that plan of yours to avoid duty for EU customers ?
Thank you !
We have some plans regarding that. Will apply it to the first shipment to EU. Good Luck, So nobody in the EU has ordered anything yet from you ? Or are you doing a sort of group EU buy / export without taxes ? Thanks ! Sorry for the confusion. What I meant was the first shipment from the Rev 3. Good Luck,
|
|
|
Has ANYONE in the UK received their unit ?
Anybody in the EU ?
What are the costs of import.
BFL, any news on that plan of yours to avoid duty for EU customers ?
Thank you !
We have some plans regarding that. Will apply it to the first shipment to EU. Good Luck,
|
|
|
I tend to agree with Inaba- hence "time is of the essence" and would love to see this be more real world with penalty clauses etc. for >12 week delivery (stick). Or on the other side, a bonus for each week less than 12 week delivery (carrot).
And yes, you can game it, but you get the gist of it...
If 'time is of the essence' as you seem to suggest, you would be better off going down the street and buying up a whackload of GPUs (setting up a few mining rigs takes a week) rather than waiting 2, 3, 4 months for a BFL product. That 2,3,4 months of time can be earning you BTC, and the GPUs will break even sooner than a delayed Single or Rig/Mini if you start the clock now. Different story long-term, but if you are concerned with maximizing your profit before December than GPUs may be the best way of achieving that. I have a different theory: when the reward is halved, I agree that it will have little impact on the BTC exchange rate. Most of that is buoyed by speculation, and speculators don't care (and/or are oblivious) about block reward or mining profitability. But miners are not; marginal miners (stealing DeathAndTaxes's terminology here) will become non-profitable and will stop mining. What we will see is not a BTC price increase, but rather a significant reduction in difficulty over the 2 or 3 months following the reward drop. Not a 50% reduction, but significant nonetheless. Marginal miners (those with inefficient GPU setups and/or high electricity costs) will be forced out, leaving the high-efficiency GPU miners and the FPGA crowd. I think the answer to this relies on one answer: How much of the Bitcoins traded daily in exchanges are fresh mined coins? Anybody has any figures regarding this subject? Regards,
|
|
|
My point is, to wait 8 weeks for two rig boxes does not bother me in the least because I am not delusional enough to think that BFL should be perfect or that it's a cake walk to get more GPUs running.
If we had faith in their lead times this would all be moot... Singles are taking 14-16 weeks now. They are saying NOTHING publicly about what has happened and why we SHOULD believe their current claims on delivery. As D&T said, they need a PR person in the worst way. Rig Box is 12-15 weeks per Sonny (according to e-mail this week). I fear it is closer to 20... EDIT - Sent e-mail to Sonny on this topic and asking for confirmation on mini-rig. Might as well ask these questions directly...Similar situation with wicked lasers. They released the arctic, people paid, and months went by without delivery. Eventually all were delivered and they're continuing to innovate and deliver great lasers. BFL never went into this saying "in stock ready to ship" they went in with calculated estimations, those estimations were definitely high, but the moment they figured that out, they announced it lowered the price, and made design adjustments to accommodate higher power requirements. Sonny has always been prompt to reply to my questions, my first order was delivered and I've already got my second order in. OK I'll risk joining this discussion before it turns into a brawl... I was one of the northern Europe customers who ordered a Wicked Lasers Arctic when they announced them. Now Wicked Lasers are rather good at marketing, and the hype was great. The emails reached the right people, the right forums went viral, etc. and WL stood looking at a monstrous number of orders - a hell of a lot of them from the USA. Of course, the original product was, IIRC, illegal in the USA for virtually any contrived reason. It looked like a light sabre toy but put out 1W of laser light - it was weapons grade and shipping with a nice set of goggles wasn't going to cut it. So a complete design respin was required to follow US weapons regs (which, for lasers, were being thought up on the fly). On top of that, the original production process (rip the diodes out of projectors and rebuild into fancy cases) wasn't scalable to the necessary level and the source of diodes wasn't enough. Product didn't ship, customers got angry, WL themselves lost control of their own order management system (I received three Arctics for some reason - and yes, I offered to pay in full for all unexpected, unordered product). But product eventually shipped. I still have an Arctic and it works well. Product quality didn't disintegrate (at least in my tiny sample). The difference with BFL is that time risk isn't a matter of 'I WANT MY PONY!' - this isn't a puerile desire to have the latest cool kit before everyone else has. If BFL were the only players in the market for orders-of-magnitude-superior-to-GPUs mining kit, then everyone would be in the same boat (apart from those leet enough to design their own bitstreams and commission their own FPGA big-boxes). But they're not. And there's a time limit before the block reward halves, and we don't have an historical analogue of *this* event (re: money supply singularity) so we can't easily predict how the BTC economy will respond to it, whether by raising BTC/xxx FX rates or wiping out mining capacity. So most miners are looking to ensure their investments pay off *before* this event. And I'll admit I've got a dog in this fight, as I'm an FPGA miner too, but not in the USA so not a BFL customer. So call me biased, I don't mind. I like their 'plug and play' approach, but you can be sure that I'm hoping they take their time as *long* as possible to 'get the product right' After all, if anyone with a few tens of thousands of dollars and a decent electrical supply can buy a box, plug it in and become a 'player' in the mining world, it removes the current technical barrier to entry, which is the only advantage people in high-power-cost locations (like both of mine) have right now. Mass mining centralisation to a few players with free power and unlimited capital is *not* good for the Bitcoin economy. (and I would normally say, 'BFL - get an EU distributor for your products FFS', and then be polite and say 'please'... but it very much sounds like they're far too overstretched as it is to accept MORE customers and orders. This is a USA thing, and I desperately hope they don't revisit the Wicked Lasers scenario and get quagmired by US customs / export regs - after all, IIRC, the US is touchy about cryptographic equipment being exported without limitations and full disclosure... and will BFL tell the government *exactly* how it works if they're not telling us?) Regarding the "EU Distributor", if the problem is the VAT, then opening an EU distributor won't help since the VAT will definitely exist in that case. There may be a way or two to get these units via post without incurring additional costs, however, with a distributor, there won't be any. Furthermore, an EU Distributor must pay social security charges, income taxes, professional taxes, VAT (paid by the customer), land tax, business tax, probably CO2 tax... There is a whole tax theme park behind it... Good luck,
|
|
|
|