Bitcoin Forum
September 26, 2021, 07:59:14 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12]
221  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 05, 2018, 06:37:36 PM
PCIe, even 4.0 for which backplanes are not yet available, is 8 or 16Gbps per transceiver vs 28 Gbps in the QSFP28s

I wasnt referring to 1525s though, I was speaking about other boards with 56+ transceivers exposed.
OK, so both Xilinx and Bittware boards have 16 xcvrs hooked to PCIe edge connector
...
Or maybe you just thought about PCIe 4.0 motherboards instead of passive backplanes?

I was thinking PCIe spec backplanes, but I see what youíre referring to. I would be surprised if the edge connectors electromechanical could support higher than 16 per transceiver, theyíre a pretty loose fit. Iíve seen how much engineering goes into things like sea-ray connectors but as you said BER may remain acceptable for losses crypto mining. I also forgot PCIe is bi-directional as well, so 16 TX + 16 RX pairs as much as ~400Gbps each way in a ring. still 1/16th of what would be available with a dedicated 128 transceiver design, and those parts are in the ballpark of a VCU1525 in quantity. Take a look at some of the ASIC verification setups based on 4+ VUP parts. HTG I believe has some.

222  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 05, 2018, 02:43:38 PM
GPUS with 3 year warranties have  a place in a low power operation.  My solar array deal with buysolar is 'free' power  So the gpus would earn for  as long as they last.

Does an fpga have a 36 month warranty?


not for mining use, its 30 days (or 90?) they reduced it from their standard warranty period. i believe they said you can buy extended warranties however. thier main concern was DIYers ignoring ESM precautions and abuse due to ignoring proper installation (heat, power quality, improper installation etc).

still these are industrial units with a proven reliability record, in wide use in industry (so bittmex says, and i have no reason to doubt them atm) , not bitmain trash. while i am a bit disappointing, i still would buy.

their monitoring software monitors a lot of sensors to keep it in the safe zone, which is the main reliability point imo.

This is why I bookmarked thread.  I want to see how this develops.

I can see some people have technical interest in it.

I can also see why op wants 4% fee not 2% or 1.5%  as  he fears  this won't last for him.

I respect that fear it is a healthy one.  Looks like this year will be an all out attack on gpus  via asics and fpgas  should be fun to watch it happen.

I wouldnít say an all out attack on GPUs by FPGAs. A good portion of my work has been on FPGA ďacceleratorsĒ that augment GPUs. GPUs still have way more memory bandwidth than FPGAs after the cache-sized blocks. I have developed some interesting FPGA coprocessor that replace inefficient GPU calculations with FPGA work but still do the memory hard loops on GPU, for overall hashrate and power gains. I expect that hardware to be ready midsummer. Remains to be seen if it will still be viable.
223  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 05, 2018, 02:16:50 PM

Still working on it, it ďrunsĒ 22kH but not completely convinced a good portion of that isnít spitting errors. Iím using a relaxed definition of correct to squeeze higher hashrate out while allowing some rare corner cases to be incorrect. Currently more hashes than expected are incorrect.

Well 22khs is pretty descent, the guy who claims VCU1525 gets 64khs is R0land

I wonít say itís impossible, but I would be really genuinely surprised. 32MB / hash of total bandwidth (read + write) is needed, and 2MB or so of stashes per hashcore.

You have 1280 URAM blocks of 288kb by 72 bit interface dual ported in the biggest configuration .Thatís an incredible amount of internal bandwidth but you can only store 23 or so simultaneous Cryptonight7 2MB blocks in that. The absolute biggest part (which isnít on the 1525 board) has 360Mbit URAM, 96Mbit BRAM, and 48Mbit Distributed RAM, holding a theoretical 63 MB of pipelines, assuming you didnít need a single bit of that for the rest of your logic (you do).

The external memory at say 4x64 DIMMs @2666 is only 85GB/s, or 2.6 KH worth of bandwidth with a perfect access pattern.

Even if you could imaginarily use all 2000+ balls on the FPGA for 2666 MT/s DDR style  speeds youíd still only clear 20KH against external memory and that isnít even real bandwidth.

 Even if you took the biggest part with 128x32 Gbps transceivers to SERDES memory youíd only have 16kH limit from bandwidth.

Unless you break the algorithm itself, thereís no where to find the bandwidth + storage space for 64khs on a single FPGA.
224  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 05, 2018, 01:51:47 PM
Thatís a pair of 6xQSFP28 adapter that connects to the FPGA transceivers, with 100Gbps Direct attach cables.

Aka as 6x100Gbps worth of interconnect between two more typical Virtex development boards.
So, is it better or worse than connecting those cards through the transceivers connected to the PCIe and plugged into a PCIe passive backplane? What are the trade-offs? According to the Xilinx docs that card has twice as many xcvs hooked to the PCIe edge than to the both of QSFPs.

PCIe, even 4.0 for which backplanes are not yet available, is 8 or 16Gbps per transceiver vs 28 Gbps in the QSFP28s

I wasnt referring to 1525s though, I was speaking about other boards with 56+ transceivers exposed.
225  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 04, 2018, 11:33:12 PM
And also what is it that we are looking at in that pic?

Thatís a pair of 6xQSFP28 adapter that connects to the FPGA transceivers, with 100Gbps Direct attach cables.

Aka as 6x100Gbps worth of interconnect between two more typical Virtex development boards.
226  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 04, 2018, 11:26:56 PM

Keccak @ 11 GH, ~500Mhz 22 full pipelines, but I wasnít strictly targeting Keccak directly so I didnít push it to the limit.

For CryptoNightV7 I do the finalizer off FPGA because itís hardly worth the area for the other SHA-3 candidates.


Thanks for the info, may I dare ask for your CryptoNightV7 hash rate?

Still working on it, it ďrunsĒ 22kH but not completely convinced a good portion of that isnít spitting errors. Iím using a relaxed definition of correct to squeeze higher hashrate out while allowing some rare corner cases to be incorrect. Currently more hashes than expected are incorrect.
227  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 04, 2018, 10:50:48 PM
@GPUHoarder

Great, have you ran any Secure Hash Algorithms on these devices, and if so, what was your throughput?

Keccak @ 11 GH, ~500Mhz 22 full pipelines, but I wasnít strictly targeting Keccak directly so I didnít push it to the limit.

For CryptoNightV7 I do the finalizer off FPGA because itís hardly worth the area for the other SHA-3 candidates.



228  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 04, 2018, 09:34:46 PM
Donít be afraid, GPUs are here to stay; even ASICs can be bricked as weíve seen with Monero (CryptoNightV7).

Also, there are many misconceptions about FPGAs for mining, and in most cases they turn out to be worst dollar for dollar vs modern day GPUs. FPGA programing require very long development cycles, maybe Xilinx will change that with their optimizing compiler (SDAccel).

Kramble summarizes it here and you can read his last comment:
https://github.com/kramble/FPGA-Blakecoin-Miner/issues/1

With that said, OP may have a breakthrough and we will know in less than a month if no credible evidence precedes it. Thereís no need to rush and purchase these cards now, MaxCoinís and SmartCashís (Keccak @17 GH/s even if true) profitability with these $4,500 cards dollar for dollar will match GPU profitability for some coins like Bismuth (SHA-224).

If the OP can pull this off, he will be my hero.   Grin

Kramble was trying to milk real power out of very tiny FPGAs and use lots of them. This isnít efficient any more, vs this which is using very high end FPGAs that are designed for this type of crunching. They work very well at it, Iíve been doing this for a while.
229  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 04, 2018, 09:26:59 PM
With x16r and x17 requiring 2 cards would that be 300mh/s for both cards? Or 300 each equalling 600mh for two cards daisy chained together?

Clarifying the projected hash rates
X17: 2 cards daisy chained get 600MH/s total
X16R: 2 cards daisy chained get 600MH/s total
Xevan: 4 Bittware cards daisy chained get 600MH/s total


so I'm guessing that the VCU1525 can be daisy chained to two cards max hence being able to hash on X17 and X16R?

VCU1525 has 2 x QSFP28 connectors, so you link 2 boards with 2 x 100 gigabit ethernet cables, and two boards is the max that can be daisy chained.  With the Bittware XUPP3R board, since it has 4 x QSFP28 connectors, there is no limit to the daisy chain length.  These specialized ethernet cables have nothing to do with internet, they are solely so data can flow from one FPGA board to the next board.  The cables are around $40 each.

Personally I think GPU mining will still be around for a while.  I believe the market is going to rise so dramatically this fall that all existing GPU rigs will be making a lot of money, even with rises in difficulty.




If youíre not constrained to the 1525 (though most non-FPGA devs will be), use something like this and you have 600Gbps between boards or 300Gbps chain.

230  Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.6: fastest Ethereum/Ethash miner with lowest devfee (Windows) on: March 01, 2018, 06:52:03 PM
[quote author=Wolf0 link=topic=2647654.msg31357143#msg31357143 date=
You can back up the accusation of being stolen from open source, I take it? I rewrote my Ethash over a dozen times. At least four of them was in pure GCN assembly without a starting template.
[/quote]

That was meant more anecdotally than accusitorily, in general I donít think code or binaries were copied directly so much as techniques. Ethash isnít that complicated so there are only so many ways to write it. I do believe Iíve seen higher level stratum and other code that very much looks like someone started with an ethminer fork though. I donít necessarily think this is wrong as much as standing on shoulders of existing work.
231  Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.6: fastest Ethereum/Ethash miner with lowest devfee (Windows) on: March 01, 2018, 05:58:44 PM
I may look into it, just to check. While they have only a Win version, where I'm less practiced, I don't need nor want to go through the logic itself - location and extraction of the binary GPU kernel will tell me. Even if they based it on yours and made modifications - certain things in it stand out, so it shouldn't be ambiguous at all.
While I *know* it's quite possible to do better than Claymore's kernels - recently, he's made improvements resulting in them being quite a bit better, which cuts some of my own advantage. The optimizations in regards to core computations I've done result in me requiring far lower core clocks for the same hashrates, so I'll take the power savings. Despite this, I don't see Claymore blatantly lying about something so easily proved.

It would be nice if you can confirm my words. No modifications at all, the kernels are the same, taken from v10. I know you dumped my binaries for v10 so you can compare them easily.

It is also quite wrong of you to assume these things:
  • That you can't be fooled by our anti-reversing measures (really do you think that we can't detect dll-injection attacks?).
  • And that, if you do succeed in extracting our real/current kernels and leak them in the open, we can't do the same with yours. "We know" a guy that was part of the driver development team of AMD and he is itching to test its kernel-level emulator by trying to extract your current kernels. Heck, if he's successful, we can even put your kernels in our miner and let the users select them explicitly and see for themselves how they compare with ours.  Grin

1. Yes you cannot detect my runtime attacks, at least not all, and 100% you cannot detect driver level attacks. In fact, your protection is really weak, I spent some more time and now have three different ways to get kernels and they all return same binary. Of course you will state that your super-protection even detects my system driver, it's ridiculous.
2. My dumped kernels are on this forum already in public, so I don't care about your "kernel guy", "a guy from AMD" etc. The only thing I care is to prove that you are the liar.



I am also very active in the low level side of this, and have also dumped both kernels at a mock hardware level and can absolutely confirm Claymoreís post. Private kernels developed to match specific hardware can be developed that are faster than Claymoreís, but significant work has gone into those kernels. They are absolutely rights  of Claymore and stolen in this case. Never mind all originally stole from open source...
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!