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

[uck]

The video could show general sound level, and could show how easy it was to get it to start hashing. 

[kjlimo]

Video of the device?  What do you want the video to show?  A box with a red light? heh

Even though it could be doctored, maybe a video of the box hooked up to a computer with a display on the screen of mhash/s.

Also, a walk through from opening the box, hooking it up and getting the software running.

I realize that's a lot to ask, but it's certainly something I'd be watching right now if it was available.

[rph]

Far outpacing any other FPGA offering.

Give me a break.

Its performance per watt is less than half of a 6s150 FPGA design.

It's very likely that these BFL units will become unprofitable later this year,
as more power-efficient technologies start to drive the network difficulty.

-rph

[cuz0882]

 

[kano]

WTF is that?

[bulanula]

Yeah. Typical sketchy behaviour from BFL.

STILL no information about that chip under the heatsink.

STILL no shipping information.

STILL no proof they have more than 3 devices anywhere at all.

STILL 4-6 weeks delivery.

How lazy or incompetent can you get if this is not a long con ? 

Buy them up folks ! Magic in a box for sure. Efficiency 500% : what more do you need ?

[kano]

OK so pay me now please

Efficiency is the number of shares per getwork.
In normal mining with 1 difficulty shares, you'd expect on average one share per getwork.
(if you mine fast enough)

If you use rollntime, you can then hash a full nonce range again each time you change the time in the block header.

If you do it 4 times you can expect to get 5 shares per getwork ... = 500% efficiency.

Edit: and to be complete ...

Also what you hash is 80 bytes =
version(4) previous hash(32) merklroot(32) time(4) difficulty(4) nonce(4)
(where (x) is the size in bytes)

When you roll the time, you change the time(4) and then hash another nonce range

A nonce range is when you try different values for 'nonce' so a full nonce range is 0x00000000 to 0xffffffff or 2^32 different values

A pool will say if it allows rollntime - coz if it doesn't allow it, then any shares you return with rolled time will not match what they expect.

[kjlimo]

OK so pay me now please

Efficiency is the number of shares per getwork.
In normal mining with 1 difficulty shares, you'd expect on average one share per getwork.
(if you mine fast enough)

If you use rollntime, you can then hash a full nonce range again each time you change the time in the block header.

If you do it 4 times you can expect to get 5 shares per getwork ... = 500% efficiency.

Edit: and to be complete ...

Also what you hash is 80 bytes =
version(4) previous hash(32) merklroot(32) time(4) difficulty(4) nonce(4)
(where (x) is the size in bytes)

When you roll the time, you change the time(4) and then hash another nonce range

A nonce range is when you try different values for 'nonce' so a full nonce range is 0x00000000 to 0xffffffff or 2^32 different values

A pool will say if it allows rollntime - coz if it doesn't allow it, then any shares you return with rolled time will not match what they expect.

I wish I understood this, but I'm happy there are people who do...

[kano]

i should have been more clear. i mean why can the two chips do it and my 7970s cant.

Your miner must implement rollntime and so also must your pool.
Both or it doesn't happen.

cgminer does

Edit: or look at it this way:
It has nothing to do with your 7970 vs the BFL FPGA.

Inaba was using cgminer on his pool.
That means his pool allows rollntime (and cgminer of course does also)

ckolivas has his 7970 doing 717 Mh/s with cgminer ... ... ...

[Inaba]

Far outpacing any other FPGA offering.

Give me a break.

Its performance per watt is less than half of a 6s150 FPGA design.

It's very likely that these BFL units will become unprofitable later this year,
as more power-efficient technologies start to drive the network difficulty.

-rph

Give me a break.  Show me one shipping unit that comes anywhere even CLOSE to BFL's offering.  Go on... send me a link.  Don't give me your theoretical bullshit you just spewed out in the quote.  Show me something tangible.  You can't, because you're talking shit.

[kano]

Far outpacing any other FPGA offering.

Give me a break.

Its performance per watt is less than half of a 6s150 FPGA design.

It's very likely that these BFL units will become unprofitable later this year,
as more power-efficient technologies start to drive the network difficulty.

-rph

Give me a break.  Show me one shipping unit that comes anywhere even CLOSE to BFL's offering.  Go on... send me a link.  Don't give me your theoretical bullshit you just spewed out in the quote.  Show me something tangible.  You can't, because you're talking shit.

Wow that was a big edit just as I hit reply
(had to find the numbers in my IRC log )

Anyway - are BFL's actually shipping yet? ... No your one doesn't count

The guy with the Icarus that I keep chatting with (and helping) in IRC was getting a U: of 3.3/m with the testing we did last night (1 hour run)
(aside: with it connected to a router not a PC )
So that would imply 235Mh/s +/- something like 10%
And it was measuring 9W ...

[Inaba]

So where do I buy it?

[Raoul Duke]

So where do I buy it?

You don't! You only get to read the mofo's brag about how good they all are.

[Inaba]

Icarus is for sale, he is on batch 3... i don't know if I am helping or even if this is what you are talking about...

Icarus specs:

speed (MH/s): 380
$: 569

Costs as much or more than BFL, gets half the hashrate.  So, I want to know where I can buy 235 MH/s @ 9w for $120... I'm waiting for that info, not the advertised Icarus specs.

The 500% was explained by Kano, which was pretty much what I theorized.  Why is your 7970 not getting that? I dunno, I don't have one to test with, but I suspect it may have to do with the fact that you are using multiple threads on the 7970 and the BFL uses a single compute thread cranking at 832 MH/s, so it blasts through the entire work space at that speed, instead of splitting it between multiple workspaces.  Then it rolls the time and starts again, giving the efficiency seen. So when it's time to submit the work back, it's already rolled through 4 or so blocks on the single thread (and thus a single getwork), where your 7970 has rolled through 4 blocks on 4 threads with 4 getworks.

  

[DeathAndTaxes]

i should have been more clear. i mean why can the two chips do it and my 7970s cant.

Your miner must implement rollntime and so also must your pool.
Both or it doesn't happen.

cgminer does

Edit: or look at it this way:
It has nothing to do with your 7970 vs the BFL FPGA.

Inaba was using cgminer on his pool.
That means his pool allows rollntime (and cgminer of course does also)

ckolivas has his 7970 doing 717 Mh/s with cgminer ... ... ...

But how 500%?  I have never seen cgminer show 500% efficiency for anything.

Note: I am not saying 500% is amazing, awesome, or does anything useful for the end user it is just "interesting".

To complete 5 nonce ranges would require 2^32 * 5 = 21 billion hashes.  Even at 1 GH/s that is 21 seconds.  That is a very long n-time-rolling period.  At 700 MH/s it is 30 seconds.

On edit:  Ah single thread vs multiple threads.    Yeah a 7970 would be using 4+ threads so to acheive 50% efficiency would require each thread to complete ~21 billion hashes before the n-time-rolling expires.  650MH/s / 4 = 162 MH per thread.  At only 162 MH/s each thread would need the n-time-rolling expire time to be 132 seconds.

Thanks Inaba it was the single thread vs multi-thread which wasn't clicking.  To acheive high efficiency (which BTW really only helps pool operators you need:
a) a large per chip hashrate
b) single threaded miner (or single thread per chip)
c) ntime rolling support (both pool & miner)
c) a long n-time rolling expire time

Inaba just curious what is your pool's ntime rolling expire time?  It would have to be almost a minute right?  Most pools have much shorter ntime rolling expire time thus 500% efficiency is never possible (well not unless you have a 2GH/s per chip miner .

[DeathAndTaxes]

i should have been more clear. i mean why can the two chips do it and my 7970s cant.

Your miner must implement rollntime and so also must your pool.
Both or it doesn't happen.

cgminer does

Edit: or look at it this way:
It has nothing to do with your 7970 vs the BFL FPGA.

Inaba was using cgminer on his pool.
That means his pool allows rollntime (and cgminer of course does also)

ckolivas has his 7970 doing 717 Mh/s with cgminer ... ... ...

But how 500%?  I have never seen cgminer show 500% efficiency for anything.

Note: I am not saying 500% is amazing, awesome, or does anything useful for the end user it is just "interesting".

To complete 5 nonce ranges would require 2^32 * 5 = 21 billion hashes.  Even at 1 GH/s that is 21 seconds.  That is a very long n-time-rolling period.  At 700 MH/s it is 30 seconds.

yeah, it does not sink in with me either, i was just willing to accept i was stupid and move on... glad you jumped in on this...

I edited my post.  I suspect it is that Inaba pool has a very high ntime rolling expire time.  Technically you can use any time but most pools seem to use relatively short expire time (say 10 seconds or so).  If inaba pool has a 60 second expire time the math would make sense.

@ 800 MH/s each chip is running @ 400 MH/s.  Since the miner is using 1 thread per chip (not sure if that is intentional, accidental, or it doesn't matter) that means 400 MH/s per thread (which is what matters for efficiency).  
500% efficiency = 5 shares / getwork = 21 billion hashes per getwork.  @ 400 MH/s per thread to acheive 500% efficiency would require the miner to work on a single block header for ~52.5 seconds.    It is unusual for a pool to have an ntime-rolling expire that high but I don't see why you couldn't.  

On a GPU rig you are going to have multiple GPUs and each GPU likely has 2+ threads.  Thus for "efficiency" (shares per getwork) what matters is the per thread hashrate.   A 5970 running at 750MH/s is 375 MH/s per GPU.  Using 2 threads it is ~187 MH/s per thread.  Lets pretend Inaba pool does allow an average ntime rolling of 52.5 seconds.  A 5970 due to work being spread over 4 threads would "only" have (0.1875 GH/s * 52.5 seconds / 4.2 billion hashes per share)  234% efficiency.

Maybe I will point one of my 5970s at Inaba pool to test out my hypothesis.  Honestly I don't know why more pools don't use a higher n-time rolling expire time.  It would cut down on the # of getworks which need to be sent per GH/s especially for faster miners.

[Inaba]

Yeah, I have it set to 1 minute if I recall. I will have to look.  

The BFL device uses 1 thread, not 2.  If you look at the pictures of the screen (29?), you'll see there's only one thread cranking both chips.  I'm not an FPGA expert, so I don't know what's going on behind the scenes, but it seems to me that the workspace is being split evenly between the two FPGAs, thus you are getting the full 832 MH/s on a single nonce range.

BTW - efficiency seem to have stabilized at 480%.  U: 10.28/m

[btc_artist]

also ill pay 5 BTC to anyone who full helps me understand why this things gets 500% eff when my 7970 only gets 99%...

kano already explained it above.  It has to do with your mining software and the pool you're using, NOT the hardware you're using.  Now send him his 5 BTC.

[2112]

i really wonder about that 500% efficiency, i'm thinking about making a bounty to anyone who tells me wtf that's all about.

What I wonder is the following: can a pool detect that the device is checking not an every number in the nonce range but instead every n-th number in the nonce range?

Instead of doing hashing for 0,1,...,4294967294,4294967295 it would hash only (say) 1,3,...,4294967293,4294967295 or some other similar scheme of skipping through the nonce range?

[Inspector 2211]

Yeah, I have it set to 1 minute if I recall. I will have to look.  

The BFL device uses 1 thread, not 2.  If you look at the pictures of the screen (29?), you'll see there's only one thread cranking both chips.  I'm not an FPGA expert, so I don't know what's going on behind the scenes, but it seems to me that the workspace is being split evenly between the two FPGAs, thus you are getting the full 832 MH/s on a single nonce range.

BTW - efficiency seem to have stabilized at 480%.  U: 10.28/m

The Icarus board with two Spartan6-150 does the very same thing. Splits the search space between two FPGAs. No big surprise here.