Bitcoin Forum
April 25, 2024, 05:08:01 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
  Print  
Author Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150  (Read 161489 times)
fpgaminer
Hero Member
*****
Offline Offline

Activity: 560
Merit: 517



View Profile WWW
August 29, 2011, 11:54:35 PM
 #21

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello ztex,

I felt it best to bring this to the public forum.

August 29th, 2011

In your reply PM to me, you stated that none of your Verilog code is a derivative of my work. However, I am very concerned by many similarities between your newly released Verilog code, and my GPL3 code which has been around since May 20th, 2011. I hope these are just coincidences, but to express my concerns I have listed details below.

1) The use of the term golden_nonce is unique to me, and has not to my knowledge, nor the knowledge of Google, ever been used by anyone else. It appears several times in your code.

2) Your use of an appended _w is unique to my Verilog coding style.

3) Your use of a monolithic localparam named Ks in sha256_pipes.v, with the constants occurring in reverse order using the concat operator is unique to my project.

4) The use of a define named IDX is an exact duplicate of my usage, again unique to my coding style.

I am listing an exact copy of your code below, as of this date, and links to code belonging to my github repo. Please note that there are many variations of the code available on my repo, and also note that much of the code on my repo is contributed by myself, and various other wonderful developers.

miner128.v
Code:
/*!
   btcminer -- BTCMiner for ZTEX USB-FPGA Modules: HDL code: double hash miner
   Copyright (C) 2011 ZTEX GmbH
   http://www.ztex.de

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License version 3 as
   published by the Free Software Foundation.

   This program is distributed in the hope that it will be useful, but
   WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
   General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, see http://www.gnu.org/licenses/.
!*/

module miner128 (clk, reset,  midstate, data,  golden_nonce, nonce2, hash2);

parameter NONCE_OFFS = 32'd0;
parameter NONCE_INCR = 32'd1;
parameter NONCE2_OFFS = 32'd0;

input clk, reset;
input [255:0] midstate;
input [95:0] data;
output reg [31:0] golden_nonce, hash2, nonce2;

reg [31:0] nonce;
wire [255:0] hash;
wire [31:0] hash2_w;

sha256_pipe66 p1 (
.clk(clk),
.state(midstate),
.state2(midstate),
.data({384'h000002800000000000000000000000000000000000000000000000000000000000000000000000000000000080000000, nonce, data}),
.hash(hash)
);

sha256_pipe62 p2 (
.clk(clk),
.data({256'h0000010000000000000000000000000000000000000000000000000080000000, hash}),
.hash(hash2_w)
);

always @ (posedge clk)
begin
if ( reset )
begin
    nonce <= 32'd129 + NONCE_OFFS;
    nonce2 <= NONCE_OFFS + NONCE2_OFFS;
    golden_nonce <= 32'd0;
end else begin
    nonce <= nonce + NONCE_INCR;
    nonce2 <= nonce2 + NONCE_INCR;
    if ( hash2 == 32'ha41f32e7 )
    begin
golden_nonce <= nonce2;
    end
end

hash2 <= hash2_w;
end

endmodule
Similar to: https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/blob/master/src/fpgaminer_top.v

sha256_pipes.v
Code:

/*!
   btcminer -- BTCMiner for ZTEX USB-FPGA Modules: HDL code: hash pipelines
   Copyright (C) 2011 ZTEX GmbH
   http://www.ztex.de

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License version 3 as
   published by the Free Software Foundation.

   This program is distributed in the hope that it will be useful, but
   WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
   General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, see http://www.gnu.org/licenses/.
!*/

`define IDX(x) (((x)+1)*(32)-1):((x)*(32))
`define E0(x) ( {{x}[1:0],{x}[31:2]} ^ {{x}[12:0],{x}[31:13]} ^ {{x}[21:0],{x}[31:22]} )
`define E1(x) ( {{x}[5:0],{x}[31:6]} ^ {{x}[10:0],{x}[31:11]} ^ {{x}[24:0],{x}[31:25]} )
`define CH(x,y,z) ( (z) ^ ((x) & ((y) ^ (z))) )
`define MAJ(x,y,z) ( ((x) & (y)) | ((z) & ((x) | (y))) )
`define S0(x) ( { {x}[6:4] ^ {x}[17:15], {{x}[3:0], {x}[31:7]} ^ {{x}[14:0],{x}[31:18]} ^ {x}[31:3] } )
`define S1(x) ( { {x}[16:7] ^ {x}[18:9], {{x}[6:0], {x}[31:17]} ^ {{x}[8:0],{x}[31:19]} ^ {x}[31:10] } )

module sha256_pipe_base ( clk, state, data, out );

parameter STAGES = 64;

input clk;
input [255:0] state;
input [511:0] data;
output [255:0] out;

localparam Ks = {
32'h428a2f98, 32'h71374491, 32'hb5c0fbcf, 32'he9b5dba5,
32'h3956c25b, 32'h59f111f1, 32'h923f82a4, 32'hab1c5ed5,
32'hd807aa98, 32'h12835b01, 32'h243185be, 32'h550c7dc3,
32'h72be5d74, 32'h80deb1fe, 32'h9bdc06a7, 32'hc19bf174,
32'he49b69c1, 32'hefbe4786, 32'h0fc19dc6, 32'h240ca1cc,
32'h2de92c6f, 32'h4a7484aa, 32'h5cb0a9dc, 32'h76f988da,
32'h983e5152, 32'ha831c66d, 32'hb00327c8, 32'hbf597fc7,
32'hc6e00bf3, 32'hd5a79147, 32'h06ca6351, 32'h14292967,
32'h27b70a85, 32'h2e1b2138, 32'h4d2c6dfc, 32'h53380d13,
32'h650a7354, 32'h766a0abb, 32'h81c2c92e, 32'h92722c85,
32'ha2bfe8a1, 32'ha81a664b, 32'hc24b8b70, 32'hc76c51a3,
32'hd192e819, 32'hd6990624, 32'hf40e3585, 32'h106aa070,
32'h19a4c116, 32'h1e376c08, 32'h2748774c, 32'h34b0bcb5,
32'h391c0cb3, 32'h4ed8aa4a, 32'h5b9cca4f, 32'h682e6ff3,
32'h748f82ee, 32'h78a5636f, 32'h84c87814, 32'h8cc70208,
32'h90befffa, 32'ha4506ceb, 32'hbef9a3f7, 32'hc67178f2
};

genvar i;

generate

        for (i = 0; i <= STAGES; i = i + 1) begin : S
wire [479:0] w_data;
wire [223:0] w_state;
wire [31:0] w_t1, w_data14;

if(i == 0)
        sha256_stage0 #(
        .K_NEXT(Ks[`IDX(63)]),
    .STAGES(STAGES)
        ) I (
    .clk(clk),
    .i_data(data),
    .i_state(state),
    .o_data(w_data),
    .o_state(w_state),
    .o_t1(w_t1),
    .o_data14(w_data14)
    );
else
    sha256_stage #(
    .K_NEXT(Ks[`IDX((127-i) & 63)]),
    .STAGES(STAGES)
    ) I (
        .clk(clk),
    .i_data(S[i-1].w_data),
    .i_state(S[i-1].w_state),
    .i_t1(S[i-1].w_t1),
    .i_data14(S[i-1].w_data14),
    .o_data(w_data),
    .o_state(w_state),
    .o_t1(w_t1),
    .o_data14(w_data14)
    );
    end

endgenerate

reg [31:0] state7;

always @ (posedge clk)
begin
    state7 <= S[STAGES-1].w_state[`IDX(6)];
end

assign out[255:224] = state7;
assign out[223:0] = S[STAGES].w_state;

endmodule


module sha256_pipe66 ( clk, state, state2, data,  hash );

input clk;
input [255:0] state, state2;
input [511:0] data;
output reg [255:0] hash;

wire [255:0] out;

sha256_pipe_base #( .STAGES(64) ) P (
    .clk(clk),
    .state(state),
    .data(data),
    .out(out)
);

always @ (posedge clk)
begin
    hash[`IDX(0)] <= state2[`IDX(0)] + out[`IDX(0)];
    hash[`IDX(1)] <= state2[`IDX(1)] + out[`IDX(1)];
    hash[`IDX(2)] <= state2[`IDX(2)] + out[`IDX(2)];
    hash[`IDX(3)] <= state2[`IDX(3)] + out[`IDX(3)];
    hash[`IDX(4)] <= state2[`IDX(4)] + out[`IDX(4)];
    hash[`IDX(5)] <= state2[`IDX(5)] + out[`IDX(5)];
    hash[`IDX(6)] <= state2[`IDX(6)] + out[`IDX(6)];
    hash[`IDX(7)] <= state2[`IDX(7)] + out[`IDX(7)];
end

endmodule


module sha256_pipe62 ( clk, data,  hash );

parameter state = 256'h5be0cd191f83d9ab9b05688c510e527fa54ff53a3c6ef372bb67ae856a09e667;

input clk;
input [511:0] data;
output [31:0] hash;

wire [255:0] out;

sha256_pipe_base #( .STAGES(61) ) P (
    .clk(clk),
    .state(state),
    .data(data),
    .out(out)
);

assign hash = out[`IDX(4)];

endmodule


module sha256_pipe65 ( clk, state, data,  hash );

input clk;
input [255:0] state;
input [511:0] data;
output [255:0] hash;

wire [255:0] out;

sha256_pipe_base #( .STAGES(64) ) P (
    .clk(clk),
    .state(state),
    .data(data),
    .out(out)
);

assign hash = out;

endmodule


module sha256_stage0 ( clk, i_data, i_state, o_data, o_state, o_t1, o_data14 );

        parameter K_NEXT = 32'd0;
parameter STAGES = 64;

input clk;
input [511:0] i_data;
input [255:0] i_state;

output reg [479:0] o_data;
output reg [223:0] o_state;
output reg [31:0] o_t1, o_data14;

wire [31:0] s0;

always @ (posedge clk)
begin
    o_data <= i_data[511:32];
    o_state <= i_state[223:0];
    o_t1 <= i_state[`IDX(7)] + i_data[`IDX(0)] + K_NEXT;
    o_data14 <= `S0( i_data[`IDX(1)] ) + i_data[`IDX(0)];
end
endmodule


module sha256_stage ( clk, i_data, i_state, i_t1, i_data14, o_data, o_state, o_t1, o_data14 );

        parameter K_NEXT = 32'd0;
parameter STAGES = 64;

input clk;
input [31:0] i_t1, i_data14;
input [479:0] i_data;
input [223:0] i_state;

output reg [479:0] o_data;
output reg [223:0] o_state;
output reg [31:0] o_t1, o_data14;

wire [31:0] t1 = `E1( i_state[`IDX(4)] ) + `CH( i_state[`IDX(4)], i_state[`IDX(5)], i_state[`IDX(6)] ) + i_t1;
wire [31:0] t2 = `E0( i_state[`IDX(0)] ) + `MAJ( i_state[`IDX(0)], i_state[`IDX(1)], i_state[`IDX(2)] );
wire [31:0] data14 = `S1( i_data[`IDX(13)] ) + i_data[`IDX(8)] + i_data14;

always @ (posedge clk)
begin
o_data[447:0] <= i_data[479:32];
o_data[`IDX(14)] <= data14;

o_state[`IDX(0)] <= t1 + t2;
o_state[`IDX(1)] <= i_state[`IDX(0)];
o_state[`IDX(2)] <= i_state[`IDX(1)];
o_state[`IDX(3)] <= i_state[`IDX(2)];
o_state[`IDX(4)] <= i_state[`IDX(3)] + t1;
o_state[`IDX(5)] <= i_state[`IDX(4)];
o_state[`IDX(6)] <= i_state[`IDX(5)];

o_t1 <= i_state[`IDX(6)] + i_data[`IDX(0)] + K_NEXT;
o_data14 <= `S0( i_data[`IDX(1)] ) + i_data[`IDX(0)];
end

endmodule
Similar to: https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/blob/master/src/sha256_transform.v

Please do not interpret this as me calling you a liar. You have obviously put a lot of work into your code and made numerous enhancements. I honestly wish you the best success with it. These numerous similarities just set off a lot of alarm bells for me and I hope you understand that. Help me to figure out why my coding style has leaked into your code and I will feel a lot better.

Thank you,
~fpgaminer

NOTE: GPG signed based on a plain-text copy of the text above. Just copy-paste the plain-text as it appears on the forum, so that BBCODE formatting is not included, to perform GPG signature verification.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQIcBAEBAgAGBQJOXCZNAAoJEFFoGj2A5YKR1iYP/11I9Vo0FnxBrXdDGKfh68Ms
gsDsaJkYRsLXFvKHONy19wdVdgcN3T+UpliypTU8c0DXm/rUM0vYNQxBkd59gOv+
9cDPljLlu1oGz36hwgRwdrXKmEwodtlhcoKE7cFqnMFVCn72VSxJDu33pKMGlZPy
Ea/NNonjJfxgTjQMOYtNevGsEe0iDAilJZ93RCUK2qSzWo1xT9hP+kjt5jyGQTNe
k1tlz1YSPk+HWnOlb6LTx7Bf6MAaM8P7L0XI20JSRBvlEkieLgMYeBXFtKbgBtv5
4vy2Ws+BtzQyp8Yu7AmHFvx5n+b7iTnuGAP8D1iIUmvUHo1vroikvd8QoHAdGX+y
3hfHYcLfb6CN25lAhQsoY0PJVb5EWYm5KIaQiijJnzx8Ks2T85eN6LVQz26m9h9w
P/0Sd9ySHCfeufhNVBh1zE+/w7HrRvlk2f/sT8CkxmQtOIY1tUIWKEb7P2GDdOMz
2UFgczxinRkoqG5QUdGGhC0pAoy4BptIKvpZmIFlXL0A3Y22sGldhmsKR45Bic67
iDmG+fyPf7HJRrkjY0Khv2eG/KlmBl5wu+LHZXRn7K8xS2cGR6Jj1NvdZyKafiKW
zjIfqbu08tcr3ecghQGkRRpf9xr9SARjxqC9ACJFVxk+4ig/E9gYKhwUTpAnCgAt
IAZUr+6syZkOImPXgSBz
=X/vX
-----END PGP SIGNATURE-----

1714021681
Hero Member
*
Offline Offline

Posts: 1714021681

View Profile Personal Message (Offline)

Ignore
1714021681
Reply with quote  #2

1714021681
Report to moderator
1714021681
Hero Member
*
Offline Offline

Posts: 1714021681

View Profile Personal Message (Offline)

Ignore
1714021681
Reply with quote  #2

1714021681
Report to moderator
1714021681
Hero Member
*
Offline Offline

Posts: 1714021681

View Profile Personal Message (Offline)

Ignore
1714021681
Reply with quote  #2

1714021681
Report to moderator
You can see the statistics of your reports to moderators on the "Report to moderator" pages.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714021681
Hero Member
*
Offline Offline

Posts: 1714021681

View Profile Personal Message (Offline)

Ignore
1714021681
Reply with quote  #2

1714021681
Report to moderator
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
August 30, 2011, 01:16:47 AM
Last edit: August 30, 2011, 01:27:14 AM by ztex
 #22

As I wrote you in my PM, I started with some C code.  I computed using a constant input value (no counter) and verified the result with the result from the C code. After I got my first correct results I read about your project.

-----BEGIN PGP SIGNED MESSAGE-----
1) The use of the term golden_nonce is unique to me, and has not to my knowledge, nor the knowledge of Google, ever been used by anyone else. It appears several times in your code.

I implemented the counting stuff at a late state, after I read your code and code from other (non-FPGA) projects. If you say, you are the only one who uses this term, this name has been stolen from you.

Quote
2) Your use of an appended _w is unique to my Verilog coding style.
It is common to distunguish between wires and registers by prefixes or suffixes "w" and "r".  Are there other similarities between the register / signal names. If not, do you think I have renamed your registers bur just forgot the prefixes or suffixes?

Quote
3) Your use of a monolithic localparam named Ks in sha256_pipes.v, with the constants occurring in reverse order using the concat operator is unique to my project.
The k array is copied from C source code. I can give you several examples where this array occurs in exactly the same order. This array is definitely not your invention.

Quote
4) The use of a define named IDX is an exact duplicate of my usage, again unique to my coding style.
There is only this one way to implement the INDEX macro.

You searched for similarities. The only  non-trivail one you found is the term "golden_nonce". Did you also search for trivial differences i.e. differences that would not occur is my code is derived from yours?

You want me to add a reference to your project into my Copyright note. This requires that at least major parts of my code are derived from your project. This is not the case.  You also agreed to this in your PM:
Quote
Obviously the pieces of the code you have written belong to yourself

If I would add such a reference, I would have to start with the C Code I mentioned. And I'm sure, you would have to do the same, because this algorithm is not yours and you also copied parts of your implementation from other sources (namely the k array).






ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
August 30, 2011, 01:17:56 AM
 #23

Things are getting interesting for FPGA mining.
Are you open to sell me a couple of boards with a nice discount, and get a deep review on it ?
I'm a 25 ghps experienced miner.
Development of FPGA boards (and selling them) is my business.

There are no restrictions (pre-orders, reservations). If the boards are on stock (http://shop.ztex.de) you can purchase them.

1.15d boards are an stock. The cost optimized version (1.15x) is scheduled for later half of September.

The single unit and 25 unit prices are stated in the intro. For other amounts ask for a quotation: http://shop.ztex.dehttp://shop.ztex.de/contact_us.php.


ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
August 30, 2011, 01:20:46 AM
 #24

Hi,
BTCMiner supports dynamic overclocking based on error measurement, i.e. the software scales the frequency such that a maximum rate of valid hashes is generated.
Aha - I remember you mentioning this on IRC. Cunning! Didn't realise that you were the person behind the ZTEX FPGA boards though...

It was not me. I published my code on Friday at http://www.ztex.de/btcminer/. Maybe someone read it and posted it on IRC.

gusti
Legendary
*
Offline Offline

Activity: 1099
Merit: 1000


View Profile
August 30, 2011, 01:21:03 AM
 #25

quotation already asked, pls check the info ztex mailbox.

If you don't own the private keys, you don't own the coins.
inh
Full Member
***
Offline Offline

Activity: 155
Merit: 100


View Profile
August 30, 2011, 02:54:55 AM
 #26

ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
August 30, 2011, 07:10:43 AM
Last edit: August 30, 2011, 09:23:07 AM by ztex
 #27

quotation already asked, pls check the info ztex mailbox.
I'm sorry, but I did not receive your request. I even checked the mail logs for failed attempts.

Please either use the contact form at http://shop.ztex.de/contact_us.php or the email address stated in the imprint http://shop.ztex.de/imprint.php

gusti
Legendary
*
Offline Offline

Activity: 1099
Merit: 1000


View Profile
August 30, 2011, 01:38:18 PM
 #28

quotation already asked, pls check the info ztex mailbox.
I'm sorry, but I did not receive your request. I even checked the mail logs for failed attempts.

Please either use the contact form at http://shop.ztex.de/contact_us.php or the email address stated in the imprint http://shop.ztex.de/imprint.php

done

If you don't own the private keys, you don't own the coins.
pusle
Member
**
Offline Offline

Activity: 89
Merit: 10


View Profile
August 31, 2011, 05:35:53 AM
 #29



Nice work Zetex!    Smiley
rph
Full Member
***
Offline Offline

Activity: 176
Merit: 100


View Profile
September 02, 2011, 05:03:26 AM
 #30

Would be a bit nicer if it didn't use java. At least it's not TCL though.  Tongue

Ultra-Low-Cost DIY FPGA Miner: https://bitcointalk.org/index.php?topic=44891
njloof
Member
**
Offline Offline

Activity: 73
Merit: 10


View Profile
September 02, 2011, 05:12:25 AM
 #31

Would be a bit nicer if it didn't use java. At least it's not TCL though.  Tongue

I appreciate the portability though.
Uhlbelk
Member
**
Offline Offline

Activity: 91
Merit: 10



View Profile WWW
September 04, 2011, 07:00:20 AM
 #32

Hardware:The FPGA Boards presented above is not optimal since it contains features which are not required for bitcoin mining. A cost optimized single board version with on-bord voltage regulators, but without DDR2 SDRAM, configuration booster CPLD, microSD and GPIO pins is scheduled for second half of September. The expected single unit price is 330 EUR (471 USD), expected 25 unit price is 260 EUR (370 USD).
Let's assume a best case scenario. $370 USD for 140 MH/s with $9 BTC/USD means it will take 1.5 years for this to pay for itself, assuming free electricity. If you have to pay for electricity, the time is even longer. Does this device come with a 2-year warranty?

Help me out here, How many USB-FPGA Module 1.15d (XC6SLX150, SG 3) $496.21 would I need to make the hashing power of say the AMD Radeon™ HD 6990 for around $720? And if you could sum up the difference saved in energy showing how the FPGAs are more efficient.

Also; How does this FPGA stand against the Dual FPGA X6500 $610

I am only assuming that this equipment can also fold for organizations like SETI and not just BitCoin specific. Cause even though the ฿TC may come and go the crypto currency genie has been released.

My main project is to put together a system for local communities to run their own time dollar system using BitCoin as the book keeper.  One of the main components would be a main server to kick start the system as other members start to connect etc.  And If I were to put a package together It would need to be the most bang for the ฿TC so to speak.

Thanks for your time.

Freedom with SciFi Coin
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
September 04, 2011, 10:11:42 AM
Last edit: September 04, 2011, 11:52:58 PM by ztex
 #33

Help me out here, How many USB-FPGA Module 1.15d (XC6SLX150, SG 3) $496.21 would I need to make the hashing power of say the AMD Radeon™ HD 6990 for around $720? And if you could sum up the difference saved in energy showing how the FPGAs are more efficient.

Please read the initial posts, there will be a cost optimized version (expected for end of September) and there are volume discounts.

Profitability calculations
Here are a some profitability calculations. The 25 cluster price bases on the 25 unit price of the cost optimized 1.15x version (as stated in the initial posting). The 100 cluster price bases on the costs if the boards are produced under license.  Both cluster prices contain approximate costs for a small PC (Atom is sufficient) + hubs+ cables + fans + self made case. The GPU prices are taken from https://en.bitcoin.it/wiki/Mining_hardware_comparison (I cannot find a "X6500" GPU's there)

The calculation bases on the current difficulty, 8.50 USD/BTC, 0.20 USD/kWh and a profitabilty reduction by a factor of 2 per year. This scenario is realistic if the bitcoin mining market is saturated (if difficulty becomes stable as now).

price in   current revenues   energy costs  revenues in   revenues in   revenues in   revenues in  
rigGH/s   USD   in USD/d   in USD/d  USD after 500d   USD after 570d   USD after 640d   USD after 710  
1 Board0.1354710.650.03272.45336.34402.96471.61
25-cluster3.3751000016.230.826767.528357.7910016.0911725.37
100-cluster13.52700064.923.3627030.0933385.5440013.1646844.67
6990x21.43618006.913.371370.861836.462331.032847.31

50BTC/block -> 25BTC/block
The BTC/block reduction at end of 2012 will squeeze out many GPU miners. IMHO, after the event the difficulty will be reduced until most efficient GPU's are just profitable. (But who knows, if there will be many FPGA (or even ASIC) miners only they will survive.)

EDIT -- forget the values from the table, see http://bitcointalk.org/index.php?topic=40047.msg505088#msg505088

defxor
Hero Member
*****
Offline Offline

Activity: 530
Merit: 500


View Profile
September 04, 2011, 01:12:19 PM
 #34

Here are a some profitability calculations

I just want to say thank you for taking the time to write up that post. There's a lot of back'n'forth currently on whether we're seeing a shift from GPU to FPGA (and ASIC) at all, sooner or later at the moment. More data always help.

(More calculations in this thread, but also a fair bit of harsh language: https://bitcointalk.org/index.php?topic=40865.20 )
Uhlbelk
Member
**
Offline Offline

Activity: 91
Merit: 10



View Profile WWW
September 04, 2011, 07:41:13 PM
 #35

Here are a some profitability calculations

I just want to say thank you for taking the time to write up that post. There's a lot of back'n'forth currently on whether we're seeing a shift from GPU to FPGA (and ASIC) at all, sooner or later at the moment. More data always help.

(More calculations in this thread, but also a fair bit of harsh language: https://bitcointalk.org/index.php?topic=40865.20 )


Indeed thank you Immensely. 

So roughly 10 Boards to equal two 6990s for GH/s

10*$500=$5,000.00
$720*2=$1,440.00
$5,000-$1,440=$3,560.00
So as of now it boils down to how much electricity the Boards will save and the ROI. How many years worth of electricity you could have purchased with that. Well till the $ comes down a bit....

I have much faith in the futures of this hardware. Especially for those enterprising bitminers seeking to use alt energies to run their rigs. It is much more feasible to run a solar rig now thanks to these.
Thank you for your work on this technology.

Freedom with SciFi Coin
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
September 04, 2011, 11:48:10 PM
 #36

Forget the values from the table of my previous post. They are obviously wrong (due to a typo in the formula I entered in the spread sheet program) : If the profitability (revenues in USD per day) is halved per year the reference 6990 GPU will become unprofitable after about one year. This is not reflected in the table. (No critical readers here?  Wink  )

With the correct calculation only the 100 board cluster would get the the money in and all LX150 FPGA boards would become unprofitable after about 4.3 years. In that case no one would invest in new hardware. But if no one invests in new hardware the profitability is not reduced -- at least not by a factor of 0.5/a ...

Obviously the model I used in the previous post is too simple. A more realistic scenario is that the profitability remains almost constant for a while (until the oldtimers are squeezed out which happens now). But at latest after the the BTC/block reduction end of 2012 the profitability is halved. After that event the profitability is reduced slowly until current GPU's are squeezed out either by FPGAs/ASIC's ore more efficient GPU's.

The following calculations are based on profitability reduction of 0.5/a for a little bit more than a year (until the 6990s become unprofitable) and than a profitability reduction by 0.8/a.
This is a bad case scenario and more pessimistic than the scenario described above.

price in   current revenues   energy costs  revenues in   revenues in   revenues in   revenues in  
rigGH/s   USD   in USD/d   in USD/d  USD after 378d   USD after 820d   USD after 1650d   USD after 2400  
1 Board0.1354710.650.03163.97273.52406.15471.29
25-cluster3.3751000016.230.824067.476771.4610024.1411597.58
100-cluster13.52700064.923.3616239.6427020.2339964.5546198.34
6990x21.43618006.913.37589.85405.86-716.63-2312.39

rph
Full Member
***
Offline Offline

Activity: 176
Merit: 100


View Profile
September 05, 2011, 12:37:45 AM
 #37

Another factor to consider is depreciation / resale value. You can mine with a GPU for 6 months and then sell it for nearly what you paid on eBay. FPGAs have much less of a secondary market.

Still, my money is on FPGAs having a better long term ROI, as they will be profitable operationally, as long as the difficulty factor is defined by GPUs.

-rph

Ultra-Low-Cost DIY FPGA Miner: https://bitcointalk.org/index.php?topic=44891
huayra.agera
Full Member
***
Offline Offline

Activity: 154
Merit: 100



View Profile
September 05, 2011, 01:37:51 AM
 #38

@ztex: I just want to ask, when we order the FPGA boards, would they be just "plug & play" / ready to run? Or will I need other parts? Basically what are the complete list of things I need to make this FPGA board run?

I know I sound like I don't know what I'm talking about but the uber low energy cost of operation is very enticing compared to GPU mining. It has been a great learning experience BTC has been. Smiley I hope you could answer my queries.

BTC: 1JMPScxohom4MXy9X1Vgj8AGwcHjT8XTuy
Uhlbelk
Member
**
Offline Offline

Activity: 91
Merit: 10



View Profile WWW
September 05, 2011, 02:52:11 AM
 #39

Another factor to consider is depreciation / resale value. You can mine with a GPU for 6 months and then sell it for nearly what you paid on eBay. FPGAs have much less of a secondary market.

Still, my money is on FPGAs having a better long term ROI, as they will be profitable operationally, as long as the difficulty factor is defined by GPUs.

-rph

Let's consider that we are keeping our rigs for the long haul and Not reselling the GPU (which is a great point btw). Say we are building these machines to not only mine Btc but any and all bitcoin forks and folding operations as need be.
I build two identical machines except in one I have a high end GPU and the latest FPGA (lets say X10 in order to hash the same amount per second.)
If I'm understanding this right, the GPU looses its worth because of the energy it takes to make a Btc becomes higher then the profit from the usd conversion (at current prices) due to increasing difficulty and decreasing reward (50 to 25 etc).

For my inquiry lets pretend I have a Time Dollar system set up and use a crypto currency like BitCoin to keep track of who has what. The BTD (bit time dollar if you will) always has a constant worth of one man hour and the difficulty will remain the same throughout the life time of the project (although the reward significantly lower.)

Keeping in mind this project is for closed communities and although there is still an incentive to Mine coins the major incentive is to be part of the project and not necessarily become resource rich off the process because they have no $ worth (maybe but not for the scope of this project)
This rig is to be built as the main / first mining server pool until the others get involved so having better then everyone else is not the goal.

So my question in this case would be how long until my FPGA machine becomes more cost efficient then the GPU Rig.  I can totally see the possibilities in cost efficiency if setting up home miners with just one card for the casual participant But when setting up the "backbone" which would be the better investment for the community.
Thanks for all your input.

Freedom with SciFi Coin
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
September 05, 2011, 07:58:11 AM
Last edit: September 05, 2011, 08:27:04 AM by ztex
 #40

@ztex: I just want to ask, when we order the FPGA boards, would they be just "plug & play" / ready to run? Or will I need other parts? Basically what are the complete list of things I need to make this FPGA board run?
Quote

In order to plug them to a PC you also need a PC (cheap Atom PC is sufficient), USB cables, hub(s) and a power supply. You can place all parts an a table an or in a shelf and let them mine. The cost optimized 1.15x variant is prepared for larger heat sinks (59mm hole distance, e.g. Zalman ZM-NB32K or Titan TTC-CSC03) such that no additional cooling is required.

The FPGA boards have standard DC connectors such that standard wall plug supplies (e.g. from the supermarket) can be used. But this inefficient. Instead of this I recommend using a 12V or 15V Notebook PSU (for up to 10 FPGA boards) or ATX power supplies. Cut the cables and connect DC cables (e.g. this ones: http://search.digikey.com/scripts/DkSearch/dksus.dll?&KeyWords=CP-2189-ND) to it.

If you want it to be beautiful you have to build your own case with material from the DIY store (passive heat sinks and case fans).

Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!