Bitcoin Forum
December 10, 2016, 07:22:00 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 »  All
  Print  
Author Topic: Block Erupter: Dedicated Mining ASIC Project (Open for Discussion)  (Read 55051 times)
novusordo
Sr. Member
****
Offline Offline

Activity: 337



View Profile
November 26, 2012, 10:17:36 PM
 #161

I came in late, is the project still going forward despite all the GLBSE hoo ha?

Check the ASICMINER thread. Everything is still going, friedcat is just waiting for Nefario to send the list of shareholders.

Time is more valuable than money. You can get more money, but you cannot get more time.
GPG | OTC
1481354520
Hero Member
*
Offline Offline

Posts: 1481354520

View Profile Personal Message (Offline)

Ignore
1481354520
Reply with quote  #2

1481354520
Report to moderator
1481354520
Hero Member
*
Offline Offline

Posts: 1481354520

View Profile Personal Message (Offline)

Ignore
1481354520
Reply with quote  #2

1481354520
Report to moderator
1481354520
Hero Member
*
Offline Offline

Posts: 1481354520

View Profile Personal Message (Offline)

Ignore
1481354520
Reply with quote  #2

1481354520
Report to moderator
The block chain is the main innovation of Bitcoin. It is the first distributed timestamping system.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481354520
Hero Member
*
Offline Offline

Posts: 1481354520

View Profile Personal Message (Offline)

Ignore
1481354520
Reply with quote  #2

1481354520
Report to moderator
1481354520
Hero Member
*
Offline Offline

Posts: 1481354520

View Profile Personal Message (Offline)

Ignore
1481354520
Reply with quote  #2

1481354520
Report to moderator
1481354520
Hero Member
*
Offline Offline

Posts: 1481354520

View Profile Personal Message (Offline)

Ignore
1481354520
Reply with quote  #2

1481354520
Report to moderator
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
November 27, 2012, 12:30:04 AM
 #162

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out Smiley
Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)

Edit: Also, there's actually a 5th optimization you can do that's very worthwhile in FPGAs - you can push part of the computation of T1 into the previous pipeline stage/clock cycle to the rest of the SHA-256 round, which doesn't affect the amount of logic but does shorten the length of the critical path and increase your maximum clock. I think there are a few tricks with the W computations too...

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
November 27, 2012, 12:44:40 AM
 #163

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out Smiley
Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)
OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ... Tongue

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN Smiley

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
memvola
Hero Member
*****
Offline Offline

Activity: 896


View Profile
November 27, 2012, 08:46:18 AM
 #164

So ... who's planning a better hardware interface Smiley

I had always imagined that if ASIC boards were produced at one point, we would connect them to PCI express x1 slots.
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
November 27, 2012, 05:59:27 PM
 #165

So ... who's planning a better hardware interface Smiley

I had always imagined that if ASIC boards were produced at one point, we would connect them to PCI express x1 slots.


No point in using a more expensive controller for the ASIC plus have more limited room and power availability.

Easier to just build large scale 2 or 4U boxes dedicated to the task.

Unacceptable
Legendary
*
Offline Offline

Activity: 1946



View Profile
December 13, 2012, 10:35:34 PM
 #166

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out Smiley
Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)
OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ... Tongue

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN Smiley

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface Smiley

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more  Cool

I know as of now its only for hardrives,but can a perephrial device work on SATA  Huh

"If you run into an asshole in the morning, you ran into an asshole. If you run into assholes all day long, you are the asshole."  -Raylan Givens
Got GOXXED ?? https://www.youtube.com/watch?v=9KiqRpPiJAU&feature=youtu.be
"An ASIC being late is perfectly normal, predictable, and legal..."Hashfast & BFL slogan Smiley
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
December 13, 2012, 10:38:22 PM
 #167

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out Smiley
Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)
OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ... Tongue

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN Smiley

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface Smiley

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more  Cool

Are you retarded, or just trolling?

LazyOtto
Sr. Member
****
Offline Offline

Activity: 476


View Profile
December 13, 2012, 10:40:23 PM
 #168

Are you retarded, or just trolling?
Are you doing an Inaba imitation?

He put out an idea. It might not be a good one.

Tell him the downsides of the idea rather than just be insulting.
Unacceptable
Legendary
*
Offline Offline

Activity: 1946



View Profile
December 13, 2012, 10:46:21 PM
 #169

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out Smiley
Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)
OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ... Tongue

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN Smiley

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface Smiley

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more  Cool

Are you retarded, or just trolling?

I guess I'm retarded...........just a thought  Roll Eyes

Why wouldn't it work  Huh

"If you run into an asshole in the morning, you ran into an asshole. If you run into assholes all day long, you are the asshole."  -Raylan Givens
Got GOXXED ?? https://www.youtube.com/watch?v=9KiqRpPiJAU&feature=youtu.be
"An ASIC being late is perfectly normal, predictable, and legal..."Hashfast & BFL slogan Smiley
meowmeowbrowncow
Sr. Member
****
Offline Offline

Activity: 322



View Profile
December 13, 2012, 11:06:23 PM
 #170

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out Smiley
Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)
OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ... Tongue

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN Smiley

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface Smiley

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more  Cool

Are you retarded, or just trolling?

I guess I'm retarded...........just a thought  Roll Eyes

Why wouldn't it work  Huh


You are not retarded.  D3 is being a little harsh. 

SATA phy would work, but a serial protocol is needed that does not incur contention present with a large number of bus nodes.  SATA data link is not appropriate since it's a ptp link.

A cascade/daisy chain linkage of sata phy ala the mini rig sc is a good example.  Still need a protocol.


"Bitcoin has been an amazing ride, but the most fascinating part to me is the seemingly universal tendency of libertarians to immediately become authoritarians the very moment they are given any measure of power to silence the dissent of others."  - The Bible
Jutarul
Donator
Legendary
*
Offline Offline

Activity: 994



View Profile
December 14, 2012, 01:56:11 AM
 #171

When it comes to connections, something which supports broadcasts may be good. You can feed data in one burst and collect only those data blocks (results) which are interesting - this can be done on a p2p basis. Broadcasts can also be emulated in node based system where the p2p connections are distributed as a tree. However, that requires the nodes to have an understanding of the global layout.

I'd like to review an expert opinion on ethernet vs. USB interface. Any good links?

The ASICMINER Project https://bitcointalk.org/index.php?topic=99497.0
"The way you solve things is by making it politically profitable for the wrong people to do the right thing.", Milton Friedman
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
December 14, 2012, 02:10:59 AM
 #172

When it comes to connections, something which supports broadcasts may be good. You can feed data in one burst and collect only those data blocks (results) which are interesting - this can be done on a p2p basis. Broadcasts can also be emulated in node based system where the p2p connections are distributed as a tree. However, that requires the nodes to have an understanding of the global layout.

I'd like to review an expert opinion on ethernet vs. USB interface. Any good links?

With Ethernet, the miners would just be emulating the miner interface itself (ie, directly connect to bitcoind).

Jutarul
Donator
Legendary
*
Offline Offline

Activity: 994



View Profile
December 14, 2012, 02:39:54 AM
 #173

When it comes to connections, something which supports broadcasts may be good. You can feed data in one burst and collect only those data blocks (results) which are interesting - this can be done on a p2p basis. Broadcasts can also be emulated in node based system where the p2p connections are distributed as a tree. However, that requires the nodes to have an understanding of the global layout.

I'd like to review an expert opinion on ethernet vs. USB interface. Any good links?

With Ethernet, the miners would just be emulating the miner interface itself (ie, directly connect to bitcoind).
Does it support UDP? Otherwise the handshake imposed by the TCP connection could be a problem in a scalable design.

The ASICMINER Project https://bitcointalk.org/index.php?topic=99497.0
"The way you solve things is by making it politically profitable for the wrong people to do the right thing.", Milton Friedman
Bogart
Hero Member
*****
Offline Offline

Activity: 868


View Profile
December 14, 2012, 04:49:05 AM
 #174

Why does a bitcoin miner need a high bandwidth interface again?

People mine on pools all the time on sub-megabit internet connections.  Why are USB's multiple megabits not fast enough?

Am I missing something here?

"All safe deposit boxes in banks or financial institutions have been sealed... and may only be opened in the presence of an agent of the I.R.S." - President F.D. Roosevelt, 1933
Jutarul
Donator
Legendary
*
Offline Offline

Activity: 994



View Profile
December 14, 2012, 05:37:09 AM
 #175

Why does a bitcoin miner need a high bandwidth interface again?

People mine on pools all the time on sub-megabit internet connections.  Why are USB's multiple megabits not fast enough?

Am I missing something here?
ASICs crunch the numbers much faster. That means that the time to sweep a full nonce range is significantly shorter. Dependent on how much chips feed from a single master, the time to establish a connection can become rate limiting. Thus a communication protocol which avoids unnecessary handshakes and delivers new work to the chips continuously can be beneficial.

In any event, you want your communication protocol to avoid down time for the chips. That means once the chip is thru with some data, the next data should already be loaded and ready. So I guess you want to plug a few chips behind a controller, which handles all the communication and pushes work into a on PBC board memory.

How did the pools do it? Did they add additional servers on demand? How many GH can work off one server?

The ASICMINER Project https://bitcointalk.org/index.php?topic=99497.0
"The way you solve things is by making it politically profitable for the wrong people to do the right thing.", Milton Friedman
Unacceptable
Legendary
*
Offline Offline

Activity: 1946



View Profile
December 14, 2012, 08:48:54 AM
 #176

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out Smiley
Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)
OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ... Tongue

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN Smiley

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface Smiley

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more  Cool

Are you retarded, or just trolling?

I guess I'm retarded...........just a thought  Roll Eyes

Why wouldn't it work  Huh


You are not retarded.  D3 is being a little harsh.  

SATA phy would work, but a serial protocol is needed that does not incur contention present with a large number of bus nodes.  SATA data link is not appropriate since it's a ptp link.

A cascade/daisy chain linkage of sata phy ala the mini rig sc is a good example.  Still need a protocol.



Tank ew berry mcchh 4 esplanin dis ta ma  Cheesy


"If you run into an asshole in the morning, you ran into an asshole. If you run into assholes all day long, you are the asshole."  -Raylan Givens
Got GOXXED ?? https://www.youtube.com/watch?v=9KiqRpPiJAU&feature=youtu.be
"An ASIC being late is perfectly normal, predictable, and legal..."Hashfast & BFL slogan Smiley
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
December 14, 2012, 10:13:40 AM
 #177

When it comes to connections, something which supports broadcasts may be good. You can feed data in one burst and collect only those data blocks (results) which are interesting - this can be done on a p2p basis. Broadcasts can also be emulated in node based system where the p2p connections are distributed as a tree. However, that requires the nodes to have an understanding of the global layout.

I'd like to review an expert opinion on ethernet vs. USB interface. Any good links?

With Ethernet, the miners would just be emulating the miner interface itself (ie, directly connect to bitcoind).
Does it support UDP? Otherwise the handshake imposed by the TCP connection could be a problem in a scalable design.

Bitcoin JSONRPC doesn't do TCP, and UDP isn't recommended for reliability reasons. Existing miners don't have issues with TCP because we keep the connection open over long periods. Plus, even if you don't, each mining box itself (no matter how many chips are on it) would have one controller. Modern machines can handle a million TCP connections concurrently without breaking (usually its the software handling the connections that fails to scale long before any OS's given kernel breaks).

I don't recommend machines implement their own miner though: leave it to the experts like me and ck.

memvola
Hero Member
*****
Offline Offline

Activity: 896


View Profile
December 14, 2012, 10:40:27 AM
 #178

Why does a bitcoin miner need a high bandwidth interface again?
ASICs crunch the numbers much faster. That means that the time to sweep a full nonce range is significantly shorter.

Okay, another dumb question then... Can't you tune the expected response time by picking a lower target?
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
December 14, 2012, 10:50:16 AM
 #179

Why does a bitcoin miner need a high bandwidth interface again?
ASICs crunch the numbers much faster. That means that the time to sweep a full nonce range is significantly shorter.

Okay, another dumb question then... Can't you tune the expected response time by picking a lower target?


No, because ASICs, just like any other miner, will be looking for diff 1 candidates (ie, H == 0).

DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
December 14, 2012, 11:10:14 AM
 #180

https://bitcointalk.org/index.php?topic=130795.0

Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!