Butterfly Labs - Bitforce Single and Mini Rig Box

[kano]

fred0 - those U figures vs the MH/s figure in the first screen are fine.
Nothing to think that there certainly is a problem somewhere.

If you had run it for a whole day I'd still say the U's look OK - the highest to the lowest is around ... 10%
On my one day figures (with lower hash rates - roughly half of that) I get up to about +/-10% (I can't remember ever seeing it more than +/-10%)

But the main point being - the U figure has variance exactly like finding a block does.
Since shares happen 1.5million times more often than blocks at the moment, the amount of time to get a reasonably close to expected U value is of course a lot less when mining 1-difficulty pool shares vs 1.5million difficulty blocks.

However, a few hours isn't very accurate even at 800Mh/s
On the other hand, if you have been watching the 5s MH/s figure, that would be all over the place
I'd actually consider the MH/s figures you've shown quite reliable.

Does cgminer show the hash rate correct for Bitforce? I'm not sure. The numbers do look OK though.
I still need to do some work on the Icarus code to make it more accurate ... and thus understand where problems with that number could be when I do that - then I guess I might look at Luke-jr's code also if I find issues with the Icarus code (and own a BFL to test it

[1714774794]

1714774794

[1714774794]

1714774794

[fred0]

You should check the validity of what you say first

However, your U: is only representative of your hash rate.
Yes it is SIMPLE maths to convert that random U: number to a random hash rate: U * 2^32 / 60
However, U: is directly related to the pseudo-random function of generating a block (it is the same thing)

Firstly what should be my usual comment on this: ask Meni to do an analysis if you want to work out it's variance over time.
However, after a day of hashing I usually find it is within 10% but it often jumps around up to 5% even after a day of hashing.

However ... in general ... as I have said a few times ... if you are hashing on P2Pool with a BFL ... DONT.
Coz then your hash rate will be all over the place and you will be throwing away a lot of work.

Yes, thanks for pointing that out.  I need to look into this further.  Yes, not mining at p2pool. Generally I don't place much importance on numbers less that 24 hours.

[simonk83]

Thanks for the info fred.

Second box should be arriving in the next few days.   I still often think something's wrong when I walk in the mining room and it's so quiet

[fred0]

fred0 - those U figures vs the MH/s figure in the first screen are fine.
Nothing to think that there certainly is a problem somewhere.

I know it's throttling because the front light flashes intermittently when the unit throttles. I observed this happening.
In spite of the throttling the numbers are good.

If you had run it for a whole day I'd still say the U's look OK - the highest to the lowest is around ... 10%
On my one day figures (with lower hash rates - roughly half of that) I get up to about +/-10% (I can't remember ever seeing it more than +/-10%)

But the main point being - the U figure has variance exactly like finding a block does.
Since shares happen 1.5million times more often than blocks at the moment, the amount of time to get a reasonably close to expected U value is of course a lot less when mining 1-difficulty pool shares vs 1.5million difficulty blocks.

However, a few hours isn't very accurate even at 800Mh/s
On the other hand, if you have been watching the 5s MH/s figure, that would be all over the place
I'd actually consider the MH/s figures you've shown quite reliable.

You feel better about the numbers, but I feel worse.  I guess what was bothering me was Sunday, the U was 5.5-6, but cgminer was showing the usual ~815 MH/s. People need to keep an eye on U

Does cgminer show the hash rate correct for Bitforce? I'm not sure. The numbers do look OK though.
I still need to do some work on the Icarus code to make it more accurate ... and thus understand where problems with that number could be when I do that - then I guess I might look at Luke-jr's code also if I find issues with the Icarus code (and own a BFL to test it

If you are looking at the detail screen, those numbers are pulled from average Mh using your api.  The summary screen is calculating MH/s using accepted shares for the full uptime period.

In future I'll keep in mind to give much more importance to the variance.

[fred0]

Thanks for the info fred.

Second box should be arriving in the next few days.   I still often think something's wrong when I walk in the mining room and it's so quiet

The butterfly singles are excellent. Quiet little hashing cubes making bitcoin. 

[BFL-Engineer]

Fred,

Can you give us more details on the throttling? Is it heat related?

Throttling is heat-related. Should the environment get hotter than the acceptable
measure for the chip, then throttling will occur. There can be a degree or two difference in
throttle-threshold among different units (For example one unit may throttle at 32 Degrees
while the other throttles at 33 Degrees (Celcius) ) .


EDIT: Good Luck

[Matthew N. Wright]

Regards,

Coordial greetings make me angry!

I COULD FLIP A DESK IN RAGE (ノಠ益ಠ)ノ彡┻━┻

[pieppiep]

Still waiting for someone in the EU / UK to let us know what the total cost was including duty and all that crap ( VAT ) etc.

Any news about a EU distributor or something like that to avoid all these silly taxes ?

Thanks !

I could do that, problem is i need to charge some profit. Also i need to charge VAT 23% when selling to EU resident.
So the price would end up being something like 850$

Yeah not sure where people get the idea that a distributor makes the VAT go away.

AFAIK (and granted euro tax law wasn't may major in college)

BFL -> Customer (pay VAT)
BFL -> Distributor (no VAT) .... Distributor -> Customer (pay VAT)

right?

I think it's a problem when this happens :
BFL (add VAT to the price) -> customs (add EU VAT to the price) -> customer (WTF!? 2 times VAT?!)
It is possible to get a refund done for some part of the VAT, but I have no idea how exactly it must be done. Some stupid paperwork.

[qualalol]

Still waiting for someone in the EU / UK to let us know what the total cost was including duty and all that crap ( VAT ) etc.

Any news about a EU distributor or something like that to avoid all these silly taxes ?

Thanks !

I could do that, problem is i need to charge some profit. Also i need to charge VAT 23% when selling to EU resident.
So the price would end up being something like 850$

Yeah not sure where people get the idea that a distributor makes the VAT go away.

AFAIK (and granted euro tax law wasn't may major in college)

BFL -> Customer (pay VAT)
BFL -> Distributor (no VAT) .... Distributor -> Customer (pay VAT)

right?

I think it's a problem when this happens :
BFL (add VAT to the price) -> customs (add EU VAT to the price) -> customer (WTF!? 2 times VAT?!)
It is possible to get a refund done for some part of the VAT, but I have no idea how exactly it must be done. Some stupid paperwork.

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.)

[PulsedMedia]

I think it's a problem when this happens :
BFL (add VAT to the price) -> customs (add EU VAT to the price) -> customer (WTF!? 2 times VAT?!)
It is possible to get a refund done for some part of the VAT, but I have no idea how exactly it must be done. Some stupid paperwork.

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.

[antirack]

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.

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.

[DeathAndTaxes]

I think it's a problem when this happens :
BFL (add VAT to the price) -> customs (add EU VAT to the price) -> customer (WTF!? 2 times VAT?!)
It is possible to get a refund done for some part of the VAT, but I have no idea how exactly it must be done. Some stupid paperwork.

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.

[PulsedMedia]

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.

Exactly my point

[pieppiep]

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

[trouserless]

I have 3 singles running now. 258 watts including the laptop. Averaging 2426 Mh/s after 10 minutes of mining using cgminer.

I've not really mined before so I don't know if this is common but my hash rate takes a hit when stale shares happen. I get a few rejects either just before or just after the stales and it saying something about a Long Poll detecting a new block or a new block detected before long poll.

Is this due to the way the Bitforce Single does its thing or ?

Can I change settings to reduce the stale shares and rejects?

Thanks

It is due to the way the Bitforce currently works.

The Bitforce replies with a list of shares after it has processed the full 2^32 nonce range.

Since it hashes at about 830MH/s then it will take approx 5 seconds to do a nonce range.
If you get an LP during that 5 seconds, then the work returned at the end of the 5 seconds for each Bitforce you have will of course be rejected if sent to the pool
(which also means this can happen: if it found the share before the LP but the 5 second reply is after the LP, then the share that could have been valid will of course be rejected)

5 seconds is 0.8% of an average 10 minute block on non P2Pool

IF however you mine P2Pool it will be 50% of an average 10 second block ... so don't mine P2Pool with a Bitforce.

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.

[DeathAndTaxes]

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.

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.

[jamesg]

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.

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.

The issue is that 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.  GPU work in smaller "chunks" and finish one chunk in a fraction of a second.  How long depends on intensity and even too high of an intensity (9 in cgminer on a 5970 is an interval of 0.0105 sec) can cause a high stale rate.  The single is working on an "intensity" 500x as high.

Making BFL single compatible w/ p2pool is 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 there is nothing Kano or any other miner developer can do.

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

[BFL-Engineer]

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.

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.

The issue is that 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.  GPU work in smaller "chunks" and finish one chunk in a fraction of a second.  How long depends on intensity and even too high of an intensity (9 in cgminer on a 5970 is an interval of 0.0105 sec) can cause a high stale rate.  The single is working on an "intensity" 500x as high.

Making BFL single compatible w/ p2pool is 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 there is nothing Kano or any other miner developer can do.

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

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



Regards,

[DeathAndTaxes]

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.

[jamesg]

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.

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?