Topic: 1GH/s, 20w, $700 (was $500) — Butterflylabs, is it for real? (Part 2) - page 11. (Read 146936 times)

The first pre-orders were reportedly made some time before Oct 18...and even then the promised shipping was in 4-6 weeks from purchase date.

Wait, the first pre-order was made in November?  So you've only been delayed a month or two?  I don't think that's that horrible, especially if they catch up and deliver a good product.

The lack of communication isn't great.  I sent another e-mail last night trying to see if they have any planning for future deliveries.  No response yet, but I'm ok with a 24 hour response time.

Their previous response time was within an hour!

I'm no producer, but I wouldn't be surprised if making a video (editing it & making it worth putting your name on) took a good 8-20 hours for a good 5 minute video.

Sure someone could throw the first 5 minutes of themselves onto the internet, but that's "a lot to ask" if the person doesn't want crappy quality videos of themselves online.

So either way, it's a lot to ask...

I suggest you wait 4-6 weeks

They are waiting for Nvidia Kepler to be released before they ship these unicorns out.

Long con surely. STILL, nobody has a shipping number. Remeber 4-6 weeks last year in November ?

We don't need an Inaba unboxing, we need a shipped device, tracking number anyone?, and an unboxing video from a customer (someone who has an actual production unit).

We also need some kind of communication from BFL.

that would not be too long to ask.  what would it take?  like 5 min?

Thank you very much for your explanations, gentlemen. I misunderstood the definition of efficiency.
I now understand that this parameter isn't that important and pools are mostly interested in it in a statistical average way.

Run cgminer on EMC (with -g 1 and probably -I 11) - how much more will you now pay me over the 5 BTC I'm obviously not gonna get
Edit: Oh yeah you need SDK 2.6 and -k poclbm (but I think the latest version works out it's a 7970 and uses poclbm anyway when you have SDK 2.6)

As stated already but I will repeat - Efficiency makes no difference to how much BTC you get.
It is just the number shares you return vs the number of getworks you do.
It still takes the same amount of time to generate each share.
It's good for the pool if you only ask for a getwork on average every 5 shares rather than every 1 share.
It may be good for you also if your miner is ever waiting for work to do (i.e. is running below it's normal hash rate) but that should be rare if ever.

$120?

Icarus IS tangible and Goat wasn't talking shit ... as you said.

I simply stated that the person I've been chatting with is getting roughly 235 MH/s at 9W.
(and he is getting that with cgminer ... modified for the Icarus - the code may end up in cgminer soon but you can find it on github)
The power cost per MHash is definitely WAY lower than a BFL (almost 1/3)
Someone else can work out if that really matters or not.

The person is getting 50~60 Icarus devices soon ... apparently.

Agreed, Butterfly labs has the convenience of selling a nicely packaged pretty much "plug & play" option.

RPH has been building his own units for $1 per mhash and they have good voltage.  I think he's talking from experience rather than from theory...

And yes, the small time home grown solutions are charging a premium for their electrical efficiency they bring to the market place

That would significantly reduce efficiency not boost it.  Skipping nonces means you would on average find half the shares per getwork.

Efficiency isn't that important.

ALL efficiency means is (# of shares per get work). 
5.0 efficiency means you find 5 shares per getwork request. 
1.0 efficiency means you find 1 share per getwork request. 
0.5 efficiency means you find 1 share per 2 getwork requests.

Without ntime rolling efficiency > 100% is impossible (on any hardware).  Pool operators like high efficiency (and botnets that don't use a proxy have horrible efficiency) because per GH/s or TH/s the pool server needs to do less work with high efficiency miners.

You gain nothing from not checking all nonce values.
However if you only check one nonce per getwork, you're gonne be doing a LOT of getworks so slowing down your hash rate in a big way

The reality of it is that, with a standard 1 difficulty share pool, on average you will find 1 share per 2^32 nonces you check.
Skipping them makes no difference.
... and before anyone comes up with the stupid idea of stopping the nonce counter when they find a share, makes no difference either.
A nonce range can have no shares or could even have 2^32 shares.
It's all random statistics.

For those having difficulty understanding - consider this:
Say you have a coin and want heads when you flip it.
Once you flip heads you can either ignore the next one or include the next one.
Either way will make no difference to how many heads you are expected to find per the number of times you flip the coin.

The well known definition is actually Gambler's Fallacy http://en.wikipedia.org/wiki/Gambler%27s_Fallacy
Just coz you find an answer in a truly random event, it will not effect the next time you will find an answer.

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

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?

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.

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

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.

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 .

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.

  

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