DiabloD3, as much as I dislike BFL, luke-jr actually postponed their shipping date from dec 2012 to jan 2013. He quoted ngazhang with Avalons shipping date. And I agree with him that as long as ASICMiner is not offering any consumer-products, it doesn't go on to that page.
I suggest you wear your mod-hat with ice inside it, as you must remain objective when moderating. Calling luke-jr a BFL shill in a pinned topic is a bit harsh, and just shows poor judgement as everyone know how much you loathe BFL.
Topic: Block Erupter: Dedicated Mining ASIC Project (Open for Discussion) - page 4. (Read 58619 times)
December 14, 2012, 06:43:19 AM
December 14, 2012, 05: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).
December 14, 2012, 05: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?
December 14, 2012, 05: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?
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).
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.
December 14, 2012, 03: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.)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
... 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
December 14, 2012, 12: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. 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?
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?
December 13, 2012, 11:49:05 PM
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?
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?
December 13, 2012, 09:39:54 PM
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?
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).
December 13, 2012, 09:10:59 PM
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?
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).
December 13, 2012, 08:56:11 PM
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?
I'd like to review an expert opinion on ethernet vs. USB interface. Any good links?
December 13, 2012, 06: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.)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
... 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.
December 13, 2012, 05: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.)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
... 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
December 13, 2012, 05: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.
December 13, 2012, 05: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.)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
... 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?
December 13, 2012, 05: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.)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
... 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
November 27, 2012, 12: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.
November 27, 2012, 03: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.
November 26, 2012, 07:44:40 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.)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
... 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
November 26, 2012, 07:30:04 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.)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
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...
Jump to: