1GH/s, 20w, $700 (was $500) — Butterflylabs, is it for real? (Part 2)

[Fefox]

Just got a email from BFL, looks like I will see a rig box by the end of April and a couple more weeks from now for the singles!!

4-6 weeks for the singles? There's a shocker.

I made two orders for singles, so one order will be  late and one will be on time. BFL is starting to catch up.

[1713430344]

1713430344

[1713430344]

1713430344

[1713430344]

1713430344

[SysRun]

Just got a email from BFL, looks like I will see a rig box by the end of April and a couple more weeks from now for the singles!!

4-6 weeks for the singles? There's a shocker.

I made two orders for singles, so one order will be  late and one will be on time. BFL is starting to catch up.

Starting to catch up? Does anyone but Inaba have one?

Great question. We've got 13 BTC for a tracking number and an unboxing video! If anyone else wants to add to the bounty, PM me.

[jddebug]

I'm wondering if the holdup is related to having problems with more than one box hooked up? Maybe they haven't gotten multiples working together yet? I'm wondering how it would work even. Would each one be given a slice of the pie to chew on or ?

[kano]

I'm wondering if the holdup is related to having problems with more than one box hooked up? Maybe they haven't gotten multiples working together yet? I'm wondering how it would work even. Would each one be given a slice of the pie to chew on or ?

Nope not an issue.

[Epoch]

I just ran some numbers for Inaba's Single @ https://eclipsemc.com/mw.php?key=196e69b1afe10927460b22a8de1c0d:

3:23pm CST: 65612 shares
12:08am CST: 70949 shares (8h45m later)

So the average hashrate during that 8h45m period was:

70949-65612 = 5337 shares in 31500 seconds (8h45m)
5337 shares * 2^32 hashes/share is 2.29e13 hashes
2.29e13 hashes / 31500s = 727Mhps

Not too bad, but still 13% lower than the advertised specs of 832Mhps. 

[kano]

I just ran some numbers for Inaba's Single @ https://eclipsemc.com/mw.php?key=196e69b1afe10927460b22a8de1c0d:

3:23pm CST: 65612 shares
12:08am CST: 70949 shares (8h45m later)

So the average hashrate during that 8h45m period was:

70949-65612 = 5337 shares in 31500 seconds (8h45m)
5337 shares * 2^32 hashes/share is 2.29e13 hashes
2.29e13 hashes / 31500s = 727Mhps

Not too bad, but still 13% lower than the advertised specs of 832Mhps.  

Didn't he have a "winblows crapdate" restart during that so the share count will be low? ...

[yochdog]

I just ran some numbers for Inaba's Single @ https://eclipsemc.com/mw.php?key=196e69b1afe10927460b22a8de1c0d:

3:23pm CST: 65612 shares
12:08am CST: 70949 shares (8h45m later)

So the average hashrate during that 8h45m period was:

70949-65612 = 5337 shares in 31500 seconds (8h45m)
5337 shares * 2^32 hashes/share is 2.29e13 hashes
2.29e13 hashes / 31500s = 727Mhps

Not too bad, but still 13% lower than the advertised specs of 832Mhps. 

Somewhat disappointing.  I figured the first SNAFU with promised specs would teach them to underpromise this time.  

[kano]

We've already seen 813MH/s anyway - https://bitcointalk.org/index.php?topic=53530.msg748164#msg748164
so obviously there was something that made this one lower ...

[RandyFolds]

I'm wondering if the holdup is related to having problems with more than one box hooked up? Maybe they haven't gotten multiples working together yet? I'm wondering how it would work even. Would each one be given a slice of the pie to chew on or ?

There is no such thing as 'working together' with simple brute-forcing. Everyone in the whole network is biting at the same slice of pie. Probability is the only thing preventing massive repetition of work.

[kano]

I'm wondering if the holdup is related to having problems with more than one box hooked up? Maybe they haven't gotten multiples working together yet? I'm wondering how it would work even. Would each one be given a slice of the pie to chew on or ?

There is no such thing as 'working together' with simple brute-forcing. Everyone in the whole network is biting at the same slice of pie. Probability is the only thing preventing massive repetition of work.

Nope.

Each bitcoind is passing out work for hashing a different 80 byte header.

The header is (bytes):
version(4), previous(32),merklroot(32),time(4),difficulty(4),nonce(4)
version,previous,difficulty are all the same for everyone.
time is the same for each person who happens to have the same second in their header
nonce is what you check 2^32 different values for (~4billion) for each getwork() request

So that leaves merklroot.
Every bitcoind will have a different merklroot because every bitcoind has it's own coinbase transaction with their own payment address.

So on a single pool (one bitcoind) everyone is working on hashing the same data but that is also resolved 2 ways:
Firstly of course with time each worker asks for work - some will be the same but of course not everyone will be.
For the ones that are the same there is a secondary way to have a different 80 bytes: by having a different merklroot:
The coinbase transaction can have any random string in the actual coinbase field - so they can resolve passing out the same work by giving each worker that asks for work within the same second, a different coinbase content.

So yeah basically what it all means is that EVERYONE who is hashing is actually hashing something different (unless the pool software is crap - then some people on the same pool may be hashing the same thing)
and everyone is trying to get an answer that is less than difficulty - but no two answers will likely EVER be exactly the same either.

Off-topic - how to use 100W on Icarus
https://bitcointalk.org/index.php?topic=51371.msg756349#msg756349

[Matthew N. Wright]

UPDATE: I asked Sunny when I could expect my shipment and in less than 15 minutes received a response back that since I am in Asia, I should expect it mid-March. I hope Vladimir gets a chance to try it out before I get mine. Worst case scenario, I'll do some basic review photography etc in Korea and let Vlad do the specs.

[dirtycat]

UPDATE: I asked Sunny when I could expect my shipment and in less than 15 minutes received a response back that since I am in Asia, I should expect it mid-March. I hope Vladimir gets a chance to try it out before I get mine. Worst case scenario, I'll do some basic review photography etc in Korea and let Vlad do the specs.

hang in there.. its only 4-6 weeks away!

[Inaba]

There are several issues with the unit I have at the moment.  The windows update, there appears to be a possible bug in cgminer that is sticking the throttled hashrate and not increasing speed once it throttles, and where I have it located might be causing some throttling due to heat.  In retrospect, I probably should have placed it in a slightly different spot, but I was in a rush and it's getting some backwash from one of my PSU exhaust fans. 

[jddebug]

There are several issues with the unit I have at the moment.  The windows update, there appears to be a possible bug in cgminer that is sticking the throttled hashrate and not increasing speed once it throttles, and where I have it located might be causing some throttling due to heat.  In retrospect, I probably should have placed it in a slightly different spot, but I was in a rush and it's getting some backwash from one of my PSU exhaust fans. 

So, there is some kind of thermal monitoring that throttles the miner when it gets too hot?

[Epoch]

I just ran some numbers for Inaba's Single @ https://eclipsemc.com/mw.php?key=196e69b1afe10927460b22a8de1c0d:

3:23pm CST: 65612 shares
12:08am CST: 70949 shares (8h45m later)

So the average hashrate during that 8h45m period was:

70949-65612 = 5337 shares in 31500 seconds (8h45m)
5337 shares * 2^32 hashes/share is 2.29e13 hashes
2.29e13 hashes / 31500s = 727Mhps

Not too bad, but still 13% lower than the advertised specs of 832Mhps.  

Here's another numbers run, for a 15 hour period to 15:06 CST today. Inaba mentioned there are some issues with his unit that are causing throttling.

@Inaba, have you had a chance to try the ufasoft miner to see if the unit behaves the same? It might provide clues on whether this is a cgminer-only issue, or if it is a fundamental issue with the unit.

@kano, you had mentioned earlier that you were doing some work on icarus support in cgminer; have you seen anything in the code that might suggest a reason for the observed throttling behavior?

start: 00:08CST, shares 70949
end: 15:06CST, shares 79630

So we have:
15:06 - 00:08 = 14h58m = 53880s
79630 - 70949 = 8681 shares
8681 shares * 2^32 hashes per share = 3.73e13 hashes
3.73e13 hashes / 53880s = 692Mhps

[bulanula]

I just ran some numbers for Inaba's Single @ https://eclipsemc.com/mw.php?key=196e69b1afe10927460b22a8de1c0d:

3:23pm CST: 65612 shares
12:08am CST: 70949 shares (8h45m later)

So the average hashrate during that 8h45m period was:

70949-65612 = 5337 shares in 31500 seconds (8h45m)
5337 shares * 2^32 hashes/share is 2.29e13 hashes
2.29e13 hashes / 31500s = 727Mhps

Not too bad, but still 13% lower than the advertised specs of 832Mhps.  

Here's another numbers run, for a 15 hour period to 15:06 CST today. Inaba mentioned there are some issues with his unit that are causing throttling.

@Inaba, have you had a chance to try the ufasoft miner to see if the unit behaves the same? It might provide clues on whether this is a cgminer-only issue, or if it is a fundamental issue with the unit.

@kano, you had mentioned earlier that you were doing some work on icarus support in cgminer; have you seen anything in the code that might suggest a reason for the observed throttling behavior?

start: 00:08CST, shares 70949
end: 15:06CST, shares 79630

So we have:
15:06 - 00:08 = 14h58m = 53880s
79630 - 70949 = 8681 shares
8681 shares * 2^32 hashes per share = 3.73e13 hashes
3.73e13 hashes / 53880s = 692Mhps

Thank you for these enlightening results.

Thus, it seems that the overclocked 7970 can get more than this unicorn BS.

I mean WTF

                                7970   |   BFL
 
Cost :                        550     |  599
Performance :                700   |  700
Warranty :                 3 years |  6 month
Resale value :                 50% | 0%

The ONLY advantage I see is the consumption of power but surely that is not worth it for some US guys that have 0.10 prices. Maybe this is for EU market but VAT and import duty kills that as well so it is LAME right now from the promised holy 1000 MHash/s, 20W, $500 figures ...

BFL deserves a medal for fail of the year.  

Thermal throttling due to bad design FTW !

[kano]

...
@kano, you had mentioned earlier that you were doing some work on icarus support in cgminer; have you seen anything in the code that might suggest a reason for the observed throttling behavior?
...

Nope, got it mostly all cleaned up and working last night.
(well I just found the problems and told him the fixes which he implement with other things he worked out)
But in this case, it was reporting random strange values and hashing at almost half the U: it should, but no they weren't related to the bitforce code that the icarus code is based off (fortunately for us, unfortunately for you)

Also, cgminer has gone through a lot of commits over the last couple of weeks while ckolivas works on getting his 7970 hashing as fast as possible ... including getting rid of an outstanding problem for the last 6 months (more ATI crap finally worked around) so maybe there's something in there? (2.2.7 was just released)

[Inaba]

@Inaba, have you had a chance to try the ufasoft miner to see if the unit behaves the same? It might provide clues on whether this is a cgminer-only issue, or if it is a fundamental issue with the unit.

Not yet, I will try to get Ufasoft running tonight.  Sonny said the code for Ufasoft is a lot farther along for the BFL Single units than the CGMiner code, so we'll see how that works out.

So, there is some kind of thermal monitoring that throttles the miner when it gets too hot?

Yes, if the unit overheats, it throttles itself down until the temp is safe.  Sonny said he would reflash my unit to give it a wider tolerance if needed as well, apparently the demo I have refused to give back is restricted on the ranges it will start throttling at.  I'm not sure what/how that code is different from production code/firmware (or even if it is?) .  I'm still traveling, so it's hard to keep up on top of things.  I will be back in town tomorrow.

[simonk83]

Thanks Inaba.  I'm glad things are getting a little more productive in this thread now.

[DeathAndTaxes]

Thank you for these enlightening results.

Thus, it seems that the overclocked 7970 can get more than this unicorn BS.

I mean WTF

                                7970   |   BFL
 
Cost :                        550     |  599
Performance :                700   |  700
Warranty :                 3 years |  6 month
Resale value :                 50% | 0%

Well to be fair 7970 is going to need a host system...

The ONLY advantage I see is the consumption of power but surely that is not worth it for some US guys that have 0.10 prices. Maybe this is for EU market but VAT and import duty kills that as well so it is LAME right now from the promised holy 1000 MHash/s, 20W, $500 figures ...

I am sure they never thought it could deliver 1.05 (remember it wasn't an estimate but 1.05 GH 2 digits of significant value) at 19.8W.  That was simply a tactic to freeze out any sales of competitor products.

Still if 700 MH/s is what is sustains and it pulls 80W at the wall we are looking at 8.75 MH/W.  I don't see a lot of value in higher energy prices.  Undervolted 5970 can get 5MH/W and best FPGA designs get 20 MH/W+.  So if you want cheap hardware and higher energy costs GPUs look good.  If you want expensive hardware and low energy costs other FPGA looks good.

At $1 per MH and <9MH/W the "single" is kinda in a no mans land in between.

Still to give them the benefit of the doubt it is early.  ztex boards were initially 180MH/s and now are 210 MH/s.