novusordo
|
|
November 26, 2012, 10:17:36 PM |
|
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.
|
|
|
|
makomk
|
|
November 27, 2012, 12:30:04 AM |
|
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 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
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
November 27, 2012, 12:44:40 AM |
|
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 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 ... 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 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
|
|
|
|
memvola
|
|
November 27, 2012, 08:46:18 AM |
|
So ... who's planning a better hardware interface 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
Activity: 1162
Merit: 1000
DiabloMiner author
|
|
November 27, 2012, 05:59:27 PM |
|
So ... who's planning a better hardware interface 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
Activity: 2212
Merit: 1001
|
|
December 13, 2012, 10:35:34 PM |
|
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 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 ... 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 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 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 I know as of now its only for hardrives,but can a perephrial device work on SATA
|
"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
|
|
|
DiabloD3
Legendary
Offline
Activity: 1162
Merit: 1000
DiabloMiner author
|
|
December 13, 2012, 10:38:22 PM |
|
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 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 ... 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 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 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 Are you retarded, or just trolling?
|
|
|
|
LazyOtto
|
|
December 13, 2012, 10:40:23 PM |
|
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
Activity: 2212
Merit: 1001
|
|
December 13, 2012, 10:46:21 PM |
|
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 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 ... 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 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 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 Are you retarded, or just trolling? I guess I'm retarded...........just a thought Why wouldn't it work
|
"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
|
|
|
meowmeowbrowncow
|
|
December 13, 2012, 11:06:23 PM |
|
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 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 ... 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 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 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 Are you retarded, or just trolling? I guess I'm retarded...........just a thought Why wouldn't it work 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
Activity: 994
Merit: 1000
|
|
December 14, 2012, 01:56:11 AM |
|
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?
|
|
|
|
DiabloD3
Legendary
Offline
Activity: 1162
Merit: 1000
DiabloMiner author
|
|
December 14, 2012, 02:10:59 AM |
|
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
Activity: 994
Merit: 1000
|
|
December 14, 2012, 02:39:54 AM |
|
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.
|
|
|
|
Bogart
Legendary
Offline
Activity: 966
Merit: 1000
|
|
December 14, 2012, 04:49:05 AM |
|
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
Activity: 994
Merit: 1000
|
|
December 14, 2012, 05:37:09 AM |
|
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?
|
|
|
|
Unacceptable
Legendary
Offline
Activity: 2212
Merit: 1001
|
|
December 14, 2012, 08:48:54 AM |
|
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 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 ... 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 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 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 Are you retarded, or just trolling? I guess I'm retarded...........just a thought Why wouldn't it work 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
|
"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
|
|
|
DiabloD3
Legendary
Offline
Activity: 1162
Merit: 1000
DiabloMiner author
|
|
December 14, 2012, 10:13:40 AM |
|
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
|
|
December 14, 2012, 10:40:27 AM |
|
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
Activity: 1162
Merit: 1000
DiabloMiner author
|
|
December 14, 2012, 10:50:16 AM |
|
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
Activity: 1162
Merit: 1000
DiabloMiner author
|
|
December 14, 2012, 11:10:14 AM |
|
|
|
|
|
|