Topic: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! - page 45. (Read 176729 times)

Congratulations.  Great work.  I know how many hours you put into it.

Wow... Bitfury! 

I don't know you from Adam, but I must say I am impressed.

It seems integrity is in short supply in this forum, but you appear to have a surplus.

Godspeed good sir.

Can't write comments on bitbet.us site... It would be great if they're copy this as well in comments... Sent payouts:

http://bitbet.us/bet/450/bitfurys-asic-will-work-with-power-1/

DATE (2013-06-19 02:08:28) FOR BLOCKCHAIN LOOKUPS:

BET   OUTGOING WALLET                    PAID AMOUNT (WIN)

0.1   1CvadbWnVotoUhrrepxEGqESakmuqHtwnE 0.2
1.0   1NxPnXyN4XmxjysUxLXVXgNGFhYCEGFASV 1.9
10.0  19d6exSEyAPDXLLe3W3ucexpVXUABFeFsy 18.6
1.0   1HP9pTD9ueGYnkEA7Wj7D4SBCesTxXVsNb 1.9
0.044 1GnK5jZxzhFnKCu2yu89XP2JKvBME1em6A 0.1
5.0   16dQP7Nr1irruUTAbiiwYgNB7jQ8NpEVQ3 9.3
1.0   1DEVgggHwKngXf6YSn8ZNBvESTzCDiQWE2 1.9
0.002 1MoaWWXfSFWv6wYpKJEQiRjkmn8gHKBieK 0.1
0.052 19XHbghMRS9HhvWMoKhW8zKFYBSLVz69gB 0.1
4.0   1FzPgqnBrkBZanZwHaAmnd5wRxeDarwr9b 7.4
0.5   1CUanrri8gqXnU8e6bP2Tq8j2DSeBt5Tym 0.9
27.0  1MXf4cFD7EETFQEqD7QdLHbJeGVZfLnbaV 50.2
1.0   1DUv9KXp5CVaEdjvwg5GRUEZ5AhPVy8mnV 1.9
1.5   17xHzsvibCp9SKHParBaHVNZ5yykcjiRTk 2.8
0.05  13ZCqhVuvGL5RqF8WhUdiSFKDScZLZ7Jcz 0.1
0.01  1JCKtVk5W2LVsJiSHGXAcHeRMbZW6RXDAf 0.1
6     13X6T4iGWNHwPstvda7J1XDHbdiugio3j9 11.2

bitcoin course UP

if the Chinese do not delayed chips, bitbet would be win

Nice.

intron

Congratulations then!

As far as further testing you should measure hashing rate of the chip when immersion-cooled in champagne. At the same time you could test your own hashing rate while ingesting champagne.

Inaba, look, how should be solved lost bets.

First I would like to say that chip is working. Complete confirmation using test-vectors.

https://mega.co.nz/#!yVMTTCSA!SFsVTAWeMSnxwUeuRnwR0Wm_d74xVyOdxkL5LEI_LsQ

Here is SPI code to download and test code.

Then - measurements of error rates and real hash rates were performed using 100 first test vectors (as enabled in code), no board cooling (that's pretty impressive - it works on PASSIVE board made by Rene - great thanks BTW - you may use code I provided to perform same tests... Maybe just oscillator should be adjusted - on OUTCLK you'll see clock and you should bring INCLK and OUTMISO to ground while testing).

Results so far

0.596 V, 125 Mhz, 100 tasks sent, 122 solutions got, COP is 0.84 (122/145), Ideal 1.45 GH/s, Real 1.22 Gh/s
0.596 V, 150 Mhz, 100 tasks sent, 19 solutions got, COP is 0.13 (19/145), Ideal 1.74 Gh/s, Real 0.23 Gh/s
0.596 V, 78 Mhz, 0.6 Amps, 0.36 W, 100 tasks sent, 145 solutions got, COP is 1.0, Ideal 0.91 GH/s, Real 0.91 GH/s, 0.39 W/Gh/s
0.596 V, 45 Mhz, 0.39 Amps, 0.23 W, 100 tasks sent, 145 solutions got, COP is 1.0, Ideal 0.52 Gh/s, Real 0.52 Gh/s, 0.44 W / Gh/s
0.596 V, 96 Mhz, 0.725 Amps, 0.43 W, 100 tasks sent, 143 solutions got, COP is 0.986, Ideal 1.12 Gh/s, Real 1.1 Gh/s, 0.39 W / Gh/s

Please note that it seems that 96 Mhz is close to _BEST_ solution... Then I started to increase voltage, while not changing internal oscillator settings - it is not power-stabiized and its oscillation frequency
should follow and grow up. What is most interesting (and this should be confirmed later - this is INTENDED operation) - that oscillating frequency increases, while error rate remains the same as transistor strength in oscillator and interconnect variances within same die are less.

0.7 V 140 Mhz 1.2 Amps 0.84 W 100 tasks, 143 solutions got, COP is 0.986, Ideal 1.63 Gh/s, Real 1.6 Gh/s, 0.52 W / GH/s
0.8 V 180 Mhz 1.87 Amps 1.49 W 100 tasks, 139 solutions got, COP is 0.958, Ideal 2.093 Gh/s, Real 2 Gh/s, 0.75 W / GH/s
0.9 V 214 Mhz 2.62 Amps 2.36 W 100 tasks, 132 solutions got, COP is 0.91, Ideal 2.48 Gh/s, Real 2.26 Gh/s, 1.04 W / Gh/s.

Not tested more... And likely latter was worse due to not enough cooling.

We do not need more just confirmation testing that it works, but we need more extended testing like that. So I'll discuss tomorrow with Leszek and we'll send test chips, and will ask to perform tests and post your results. Also we likely will make some contest for say - best USB-stick (most of hashing power with smallest form-factor), highest hashing rate (real, not ideal, crunching clocks is not a problem), etc.

I would like to note that THIS design thanks to much effort spent in Monte-Carlo sims with flip-flops works really well at low voltages :-) Small error rates and no flip-flop losses like it may happen with logic cells unqualified for low voltages. It scales almost like it should in theory, not like it does in practice when cells are unsuitable and you simply can't go lower because frequency will drop DRAMATICALLY. This enables application of this chip for different kind of heating devices where voltage can be changed in dynamics to adjust produced heat to requirements, etc etc etc.

Also I am preparing to execute payments to all betters, because it is clearly our fault that we failed to meet deadlines. It is too cumbersome to calculate actual bet amount, so I would pay off using averaged multiplication value about 1.86 or so (I don't remember exactly have to look in my calculations).

Thanks that we ordered more wafer count - we now can fulfill say 100 Th/s operations, etc :-) So there's nothing to worry. And we can start planning for further testing and production.

OK, nobody funnier than me came forward...

Bitfury's saying that the "transmogrification" of the "winning nonces" will be doable all in software without having to implement the "decryption" in an auxiliary FPGA. From the quick glance at the code snippet it looks like bit order in bytes need to be swapped, amongst the other things. Remember that the bitfury's chip implements the sea-of-hasher-kernels design. The nonce is not a straight linear 32-bit counter. The 32-bit output nonce is a combination of the kernel number (there are several hundred of them in the chip) with the sub-nonce counter for each kernel. And the kernels don't all work in the round-lockstep, they work in the wavefront fashion such that the k_i round constants can use a distributed storage similar to a racetrack.

The true error rate of the chip under a full load is still to be measured.

Just a thought. To level shifting connect GND of uC to some negative voltage. Fast diodes in series to prevent voltage drop below GND of hashing chip an voila...

And it looks like there's a progress...
https://bitcointalksearch.org/topic/m.2512453

Got the bootloader to work on the ARM and soldered the
power switch between the 3V3 net and the input of the
1V8 regulator that generates IOVDD. Can now control
IOVDD from the command line:



intron

Somebody who has an experience in sportcasting should just keep refreshing the last posts of bitfury and narrate them, the tension is so palpable.

Apparently the output circuitry isn't working as expected. bitfuty had soldered a level shifter out of a discrete audio-frequency transistor BC817-40 and clocking the SPI circuitry down to 100kHz. The test vectors still didn't match. Leszek, the Polish coworker of bitfury has created a bit correlation matrix for the simulated and actual test vectors. Bitfury has referred to the process as "decryption".

It is hard to guess if the smiling emoticons are straightforward humour or gallows humour.

The whole thing reminds me of a stay in a mountain hostel during a sudden inclement weather. There was some high-level ice hockey match, e.g. Soviet Union vs. Canada or Czechoslovakia vs. Switzerland. The weather got worse and disabled the radio and tv relay station on the nearby mountain, cutting off all the regular mass media. So all the sports fans had to resort to the short-wave receivers with improvised antennas and the very spotty short-wave reception during the bad weather. The corridor in the hostel was a bedlam of screams as the listeners in the separate rooms tried to make sense of the few words that could be understood in each of the transmissions.

It's all BS bench racing until the results are shown.  You guys arguing back and forth isn't going to affect how the chip performs or doesn't perform.  So yeah, it is FUD. It serves no purpose until you actually have some real numbers to complain about.

Can we get back to talking about what the ACTUAL chips are doing here? Sheesh!

@jspielberg

Really? You think trying to shut me up will work? Produce credible information and you won't hear from me.
I am analyzing their work in a public forum. Maybe my analysis is not 100% correct, so I post it and see if someone can credibly refute it. There is noting wrong with that.

So the only people who can talk are 3 guy, one of each from BFL, Avalon and BitFury?
Oh, wait, Bitfury's chip still not known to work and perform as advertized... If and when it works I have no problem with that. I have problem with claims that it will defy math and physics.

Stop posting ridiculous clams and I will stop refuting them. Lets just wait and see what BitFury's chip will do, hopefully it's not that long.

Galaxy Asic -

I think it is a bit premature to be FUD-ing your "competition" when your asic isn't planned to be realized until 2014.  Produce your chip like Bitfury has and then we can discuss the different techs on their merits.

@punin
No one was arguing that chip can't run faster on more voltage.
did you forget what tytus said?


He implied that they only designing for this chip to run in certain power envelop that is supposedly less than 5W @ 0.5-0.6V doing 5GH
His argument was that it will cost more money to use components that will allow the same chip to run at standard voltage and 2-6 times the power to get only 2 times of performance vs running the chip at low voltage and just putting double of them in the system.

So, if you increase the voltage where it wasn't designed to run that fast and chip will overheat and ether burnout or clocks back down, depending on how it was designed. So, the point that you tried to make is irrelevant to this discussion.

I hate to reply to trolls, but this is where you're mistaken. The chip automatically clocks higher on higher voltage and consumes more and hashes faster. End of argument.

By the way, I would be happy to buy a device which gets more hashes for same price. Energy consumption is non issue for ASICs now.

I just don't see better options to buy than Bitfury ASIC now, so you would win this ... fight if you offer more hashes for lower price or earlier, but as for now even with "too low" power consumption on Bitfury ASIC they offer the best price.