Topic: Butterfly Labs - Bitforce Single and Mini Rig Box - page 64. (Read 186951 times)

http://www.butterflylabs.com/

Where can I get some real ones like you did. 

Has to be done atomically, I think it can't be easily on here.

The work over-write resolves the issue of working on something that has expired - which is roughly the same on both BFL and Icarus.

The Icarus does something that would seem bad but effectively resolves the problem of throwing away work:
It returns the first nonce that is found, when it is found, and then aborts the job.

What this means in reality is that on average the miner would process half of each nonce range (when it finds a nonce) and then go to the next one
Of course due to random probability that is not an issue, you don't gain or lose anything from processing on average half of each nonce range.
The pool however is required to supply twice as much work, of course (and the miner has the overhead to setup twice as many jobs - which may be negligible)
Also, in cgminer, you need to increase your queue size (I set it to 4) so that when there is a run of low nonce values, you don't run out of work easily.

The optimal solution of any FPGA would be 3 things:
1) allow processing of nonce ranges
2) return nonce's as soon as they are found
3) return a completion message at the end of processing the nonce range

I don't know if it is possible to return early and continue processing with an FPGA - but I would be surprised if it wasn't possible.
GPU's don't have 2) and with a GPU 1) is how intensity works in cgminer
All devices should have 3) but oddly Icarus doesn't so we work around it (and the work around resolves it)

There are different ways the different FPGA's implements this.

Item 2) (the only one that Icarus has) allows working around missing any other items - Icarus is missing both 1) and 3)

BFL only has 3) so the more LP's you get the larger the amount of wasted work (and since P2Pool has 10 seconds LP's ... well that's why I say DONT mine P2Pool with BFL)
The work wasted is (as mentioned before) the processing done that isn't reported when you abort a job.

Item 2) also means you have a better chance of getting your work to the pool in time since it means your miner knows about the results earlier.

Aside: since P2Pool is normally your own pool running, having extra work requests should not be an issue.

It's cold on that lower rack. Best place for the most highest hashers with lowest power draw to be.

>lower rack
>empty

WHAT SICK MAN SENDS BABIES TO FIGHT ME

*om nom nom*

I'll just leave these here. 

Yes theoretically it would be optimal to always return work as soon as it is found.  Still for efficiency IIRC even GPUs  run an entire "batch" and return all work at the end.  The batch just happens to be small.  Technically the larger batch size may be resulting in slightly higher lost work even in a "normal pool".  5 sec vs 600 sec means the amount lost is much smaller (~1%) and it is likely double that on pools which use merged mining (due to shorter average LP interval).  The very short LP interval of p2pool (10 s) just makes it much more noticeable. 

A smaller batch size should in theory improve efficiency even when used on a normal pool.  On the other hand if the BFL can return results immediately (or store them and make them available for polling immediately) then no batching is necessary.  It could simply process an entire nonce range returning or storing results as needed.  Not sure if that is possible based on the BFL board design though.  If it isn't working in a batch is still a good "workaround".  It is how GPU handle the issue of share latency and they do it pretty well.

There is no "free" lunch when working with a smaller nonce range though.  There is some latency and overhead in setting up work for the processor.  This can be seen on GPU with different intensities.  A 5970 w/ intensity 9 (2^24 hash batch size) is roughly optimal.  Lower intensity means less share latency but most wasted time setting up batches.  A higher intensity means less time setting up batches but longer share latency.

There likely is a similar optimal value for BFL Single. 

Maybe I am wrong, but isn't it always a good idea to return work as it is found even if you are not mining on p2pool? This way if a long poll happens in the middle of the BFL single processing work it could have already returned proper hashes for submission to the pool?

forrestv or meni likely could provide a more mathematical analysis, however anecdotally even a change in intensity from 9 to 8 on a 5970s (0.05 sec to 0.025 sec) shows improvement in stale rates (~7% vs ~3%).  I could try increasing intensity to 10 (2^25 hashes) to see how much worse that becomes.

That being said I would imagine it would be a case of diminishing returns.  i.e. 0.5 sec is 80% better than 5s but 0.1 sec is only 90% better and 0.05 is only 95% better, etc.  Average LP interval is 10 sec so unless results can be returned in <0.5 sec it likely isn't worth modifying.  1 sec may be better than 5 sec but both are likely so bad as to be ineffective.

What is the minimum latency that fits best for P2Pool? 1 Second? 0.5 second? 0.1 second?



Regards,

@BFL-Engineer: Has this been brought to your attention and are you working on a solution?

My understanding is that it would require a firmware/bitstream change on the BFL Single and since BFL hasn't opened up the bitstream source and/or provided any details on the chip used that will require BFL releasing a new one.  AFAIK BFL hasn't indicated if flashing units with new bitstream in the field is possible.

The incompatibility comes from the fact that the BFL single processes an entire nonce-range (2^32 nonces) in one big "chunk" before providing any results.  2^32 / 800 MH/s = ~5.4 seconds.  With LP interval of 10 seconds you will have roughly half the hashes stale between the time they are found and the time the Single finishes the nonce range.  GPUs work in smaller "chunks".  How long depends on intensity and too high of an intensity  can cause a high stale rate.  To put it into perspective an intensity of 9 in cgminer is 2^24 hashes.  On a 350MH/s GPU (1 thread) is 0.05 seconds. The single is working on an equivalent "intensity" 100x as long.

Making BFL single compatible w/ p2pool should be possible but it would require the single to handle work completion differently.  There are a couple of options but they all involved internal changes to how the single processes and reports found hashes.  As it stands right now AFAIK there is nothing Kano or any other miner developer can do.

On edit: fixed error (intensity 9 = 15+9 = 2^32 hashes) and made language neutral.

Kano (others?) is there any possibility of a miner change to make Bitforce more compatible with p2pool?  I personally have little desire to mine with the large pools again and am taking loooong looks at this platform as my next upgrade/purchase.

Good to hear that
I'm from the Netherlands, so I don't really know how things work in the USA.

Exactly my point

There is no reports of this happening with BFL (or any other Bitcoin related company).  It is almost unheard of for US company to collect VAT.  There is no legislation that can compel them to collect VAT so likely any company "collecting" it is simply stealing/scam.

You must be kidding. They charge US$ 34 shipping cost for an international courier, no matter if you order 1 or 10 pieces. Calling this insane shipping extra is a bit far fetched. Oops, just saw that they are actually charging $88 (and $34 is within the US/Canada), now that is indeed a steep price for shipping. My apologies for getting at you!

I just ordered a small Cooler Master PSU which has about the same weight and dimensions as a BFL single from Amazon USA to Asia - express shipping USD 53.05 (for a product that costs $39.99 but is urgently needed). That's insane.

It's illegal for BFL to collect VAT, but it's not unheard of that US company is collecting VAT to pad their profit margins, as going to court for that is quite rare. Linden Lab/Second Life does that .... California registered company collecting VAT .... Yeaaaaahhhhh riiiiiggghhhhttt..... (No wonder they went from the miracle service to the way of MySpace...)

BFL asks for insane shipping extra for international orders tho, that one is a joke, and i would have already ordered units if it were not so, but a sane shipping. When companies transfer too much of their profit margin to the shipping&handling that always puts me off from buying, no matter what.

To clear up VAT: if posting in the EU, you charge whatever VAT the country you are posting from charges, and the package does not go through customs if arriving in another EU country. Meaning you could save some money by having an EU distributor in whatever EU country charges the least VAT. If you are posting from the EU to a country outside the EU, you do not charge VAT, but usually the customs in the destination country will charge local VAT. If posting from outside the EU into the EU then the seller shouldn't charge VAT, and then customs in the destination country will charge VAT.

You can get VAT refunds if you buy something in person, and are then taking it to another country (whereby if you stay within the EU this doesn't happen since you are in a common Customs area) -- you can get a refund on exiting the country. You then still have to pay VAT on entering the country you are going to at customs. (Some people might say they end up paying no VAT this way: this is only because of exemptions, such as no customs paid on goods < £300 or similar if entering in person, or usually for goods at <£50 in person -- exact figures vary by country.)