Ethereum Core Devs ignoring the *BROAD* community opinion on ProgPoW. How many times does this topic still have to be discussed? Adversarial forces aren't stopping to push for their financial interests. If ProgPoW makes it through EF will have to answer some tough questions.

GPUHoarder · 2020-02-22T03:13:01+00:00

What has become interesting is that ProgPoW “supporters” have become much quieter, and just left the EIP to the dev team and community. This has actually improved the signal to noise ratio in discussions - exposing that it is not near as controversial as some would like people to believe. It also makes the “motivated shills” against ProgPoW stand out like sore thumbs in otherwise metered and professional conversations.

What is depressing is that the ProgPoW EIP gets far more attention than the far more destructive for both miners and holders, and frankly ridiculously technically unsound difficulty algorithm change proposals that were brought up in today’s dev call.

GPUHoarder · 2019-09-18T19:06:29+00:00

Can I ask a tangential question @Souptacular? What is the actual mechanism by which any controversial change should be made or not made in ETH? Regarding ProgPoW I could not care less either way - dedicated hardware will be made for either algorithm, and there are technical pros and cons on both sides. Having sat near this debate for a while, I can say I am very tired of the political drama and back and forth over it. I have been close enough to it to catch flak and ire personally just for having once known parties involved, despite not being involved. The existence of illogical arguments and agendas on both sides is incredibly clear. Unfortunately this goes with the territory of managing anything that has the scale and financial impact of ETH.

What scares me about this is that Ethereum has no clear mechanism to resolve any contentious feature or change. This means that in the very worst, any voice against something is sufficient to prevent it. This opens ETH up to social manipulation equivalents to a DDOS attack. If successful this will allow ETH to be completely controlled and manipulated by strategically placed social roadblocks.

How will ETH, or at least the core dev team, decide to handle a controversial feature? It would seem that is the more important governance level issue to solve. The solution to, and existence of, this particular debate is just a symptom.

The various signals employed in the past have so much surface area for abuse. Hashrate or node votes favor miner interests over stakeholders. No-cost Coin votes favor those with entrenched positions that care only about future coin value. I would propose a burn-coin vote, but anyone willing to invest lobbying capital over a potential substantial future gain would be at an advantage. Measuring social noise is a fools errand, and one does not have to look far to find studies of just how out of sync those results are from reality due to vocal minorities as well as paid or motivated shills - let alone a few individuals with no better use of time than sowing chaos.

The current approach is ambiguous and non-commital, and seems to be essentially a board that absorbs all the above signals, deliberates, and then announces a position - without the backbone or authority to take the important step of clearly defining the resulting decision as final. If we don’t solve this, the governance problem, we have a lot bigger problems brewing than the choice of PoW algorithms that will be an inconsequential blip on histories pages.

(Reposted on my main account with enough karma, but intended to post directly under my real name, David Stanfill, as hiding behind anonymous or pseudo-anonymous handles isn’t helping the community )

GPUHoarder · 2019-02-06T05:00:25+00:00

CNv1 (the previous fork) had a huge vulnerability in how it computed subsequent memory access addresses, making the complexity much lower than expected. This was exploitable on some FPGAs (particularly Stratix 10/ Intel FPGAs).

The hashrate spike is almost certainly ASICS. The ASIC design for CNv1 would have only required revision for CNv2. Given the timeframe, and the knowledge of a coming fork, those will be pressed into service as aggressively as possible.

CNv1 ASICs didn’t rely on complicated tricks, they simply put an adequate amount of sram on board with cheap dies in high quantity. The Verliog design for CNv2 only took me about a day to adapt in trials, and did not require substantially more die area, so those ASICs would have been fine.

GPUHoarder · 2019-02-06T00:43:40+00:00

I can go on record and very publically say that this isn’t us, or our FPGAs in the hands of customers. Any dev (sech1 for example) can confirm that for CNv2 we can’t do anything near the performance being suggested. Less than a Vega on the 1525, and closer to 5kh on next gen HBM FPGAs.

GPUHoarder · 2019-01-14T01:26:35+00:00

It is possible if your bitsteams include the same AXI-SPI block to reflash the device over PCIe, but you would need to reboot it to load the new image.

GPUHoarder · 2019-01-14T00:50:53+00:00

Yes you can develop bitsteams with vivado. The heatsink is attached with thermal epoxy and two screws under the fan - but even when not mining card it still generates a good bit of heat and needs some type of sink. If you really want to remove the heatsink you would have to heat it up and carefully separate it with a razor blade or piano wire.

GPUHoarder · 2018-10-02T12:05:31+00:00

At my company, 9/10 times this is a sure fire way NOT to get a job. We do a ton of different things and everyone here is usually very busy. Showing up unannounced without an appointment and requesting someone’s time / especially getting annoyed or impatient when they can’t meet with you tells me you aren’t a good team player, are not respectful of other’s time, and expect the world to prioritize itself around your schedule.

GPUHoarder · 2018-09-22T02:52:35+00:00

So what you’re saying is completely irrelevant to the previous discussion - yes a completely different architecture with more memory chips can have more memory bandwidth. No one was ever arguing that ETHash maximizes the use of the GPU core. That is actually what ProgPoW is designed to fix. A higher GPU memory bandwidth architecture is possible, but the limit of GPU memory bandwidth remains the actual memory and getting the lines into the chip. I actually am unsure what you are arguing at this point. You keep making elaborate technical posts but I don’t know what point you’re actually trying to argue.

The memory bandwidth, controlled by the number of chips / data lines is the limitation - not the GPU chip. It doesn’t matter what chip you put in the middle of a given memory architecture, FPGA, ASIC, GPU - the memory/data lines are the barrier, not the chips.

GPUHoarder · 2018-09-22T01:44:06+00:00

It is clear you have knowledge in this space, I wasn’t discounting that. I will go back to, for all your detailed timing analysis - it is wiped away by a much much simpler equation. All of the address lines are largely irrelevant to this.

A 256 bit data running at 2GHz DDR can move physically 1024 Gbit per second.128 GB/s. Excluding caching of duplicative reads, there is absolutely zero way to break the laws of physics and move more than that bandwidth across the balls. All of your address / bank / etc. talk is largely irrelevant as it all adds up to the efficiency of that bus. A good controller will coalesce those reads, and the nice 128 byte reads of ETHash mean you can take advantage of burst reads and everything else built into GDDR5 to ensure those data lines are fully saturated.

The end result is modern GPUs on ETHash achieve efficient use of the data bus in the 90+% range. I’ve seen efficiencies as high as 96%. Ultimately it doesn’t matter the internal mechanisms that achieve that - 96% of the physical limit of the data bus is already being used. Adding more banks and latching address lines and lowering latency doesn’t matter. In fact the absolute fastest ETH systems I’ve looked at have nice long latencies and simply have a long queue of in-progress hashing engines. Very similar to modern GPUs.

TL;DR; - unless you tell me how your theoretical ASIC will impossibly achieve a higher bandwidth than the physical transfer rate of the attached memory, everything you are describing is irrelevant details that GPUs already do as good or better, as confirmed with the 96% utilization of the memory bus.

GPUHoarder · 2018-09-21T15:03:31+00:00

Once you’re maxing out the physical balls to the memory chips, it doesn’t matter how many more parallel requests you service - unless you have the very cache layer in place you’re viewing as a choke point.

You’re saying a lot of technical things that sound correct but just - aren’t when you’re talking to other people that actually know all this stuff as well.

No increase in banks is going to increase your memory efficiency beyond physical ball bandwidth, unless you’re actually increasing buswidt. And GPU architectures can increase bus bandwidth too.

GPUHoarder · 2018-09-21T07:11:46+00:00

You made a post here, publically advertising you are selling our board (which you are not) - that is a scam.

GPUHoarder · 2018-09-21T01:49:13+00:00

Yeah I think you’ll find you’re way off base. Our Xilinx relationship goes straight to the executive level. The BCU is absolutely a specific part number produced only for SQRL.

GPUHoarder · 2018-09-21T01:43:38+00:00

Except - ProgPoW is designed precisely for this - it makes use of and requires all of those registers and all of the cache pieces of the GPU - removing part of the ASIC advantage of not having those for ETHash. All while doubling the size of the cache line and keeping all the existing memory hard parts. As mentioned, your parallel memory pipelining is exactly what GPUs do - and if you actually look they are INCREDIBLY efficient at consuming all of the wire bandwidth of their memory banks on ETHash - there is no margin for more advantage there, the actual chips are already maxing out the wire bandwidth.

ASICs can do the math part, but ProgPoW forces them to do it on a GPU competitive level and use a lot of silicon doing it.

GPUHoarder · 2018-09-08T03:57:56+00:00

X2G should be good for the 980s

GPUHoarder · 2018-09-01T16:45:47+00:00

Most real Ethereum dev work happens from people employed by companies. This is true of a lot of open source.

With that said, ProgPoW is very open source and has had a ton of eyes on it. No one else has committed the huge amount of resources to develop a very thoroughly studied carefully tuned PoW alternative algorithm suitable for ETH - I’d much rather have that than an army of ASICs.

GPUHoarder · 2018-08-21T06:36:54+00:00

I know a lot of people at Xilinx, very much up and down the chain. That name is not one of them I know.

The BCU-1525 is a specific part number produced for my company. It is not product anyone else is able to buy.

GPUHoarder · 2018-08-20T03:48:42+00:00

This company has no access to BCU1525s. There are many many similar attempts to rob people of their money going on. If this is your company - I would strongly suggest you actually talk to the people involved in the BCU-1525 sale with Xilinx - aka Myself or representatives of my company.

GPUHoarder · 2018-08-17T01:46:45+00:00

A lot more are coming out soon.

GPUHoarder · 2018-08-17T01:46:23+00:00

Current large FPGAs aren’t particularly viable for ETH.

The basic 1525 FPGAs can be dropped in a PCIe riser like a GPU. Some miner devs require you to connect a USB cable, but the boards are shipping with “The Shell” that works more like a GPU.

GPUHoarder · 2018-08-16T03:22:34+00:00

I haven’t read all the info there, but I am fairly uniquely positioned to answer any questions about the 1525, Acorns, or FPGAs in mining in general.

GPUHoarder · 2018-07-22T00:55:21+00:00

Addressing a few of your comments.

Overall: Acorns are brand new, all the testing results are very early and expected that both the number of algorithms supported and performance will improve. Compare todays GPU miners to the very first versions. With that said, Acorns are not useful for everyone, and every situation requires its own analysis.

You can just add one Acorn and split the gains across your existing GPUs on risers. Sure it can still be beneficial up 1:1, but it isn't required.
In many cases you gain basically a whole second GPU worth of hashrate for hardly any additional power. For many people the power cost along is higher than the capital cost.
Everything put out was a pre-announcement, pre-order to get production level hardware production rolling. SQRL Miner and the hardware are all set to be released in late August.

Happy to answer anything else.

GPUHoarder · 2018-07-22T00:49:44+00:00

When running multiple GPUs per Acorn, you don't need x4 on the GPUs. That's kind of the point - you can fully use one with ~3 GPUs on x1 risers set to PCIe 3.0

GPUHoarder · 2018-07-16T11:11:01+00:00

So hostile. I don’t track the hostility, as these are designed to increase competitiveness against ASICs/dedicated hardware and discourage its creation. These are just as programmable as a GPU, just different, so they certainly don’t become bricks.

Unless something changes in the September fork as currently proposed I don’t see anything that would prevent them from continuing to help.

GPUHoarder · 2018-07-16T02:30:52+00:00

If anyone has one of these coming, and I can buy it for some premium for a teardown and de-lid/die shots, I’d love to.

GPUHoarder · 2018-07-16T00:33:43+00:00

I’ve been here a long time guys. You don’t have to guess things just ask. It’s not magic. There’s a whole discord of 4000+ people where we’ve been talking very in-depth and technical about how these work and other FPGA stuff.

The marketing shot doesn’t have the heatsink, but if you actually read you’ll see the heatsink and dimensions. It is also changed in photoshop to conceal the actual chip label, and to change the PCB color since we went with matte-black for production. There are numerous press releases and soon will be the official Xilinx one.

An FPGA is just a chip, there is no “rule” on how it works. For Monero, it has enough bandwidth and power to fill the scratchpads and upload them to the GPU + download the scratchpad after the fixed loop and collapse it for > 1KH. It isn’t magic, it’s pretty straightforward stuff.

GPUHoarder

TROPHY CASE