bschn2
commented
5 years ago No it is not too low, it's pretty usable, even on a fast block coin like MBC. In one minute you can visit 6000 nonces, you just have to start with a low difficulty. I remember seeing cryptonight around 30 H/s or so some time ago and it had happy users at XMR.
Your idea of maxing out the write bandwidth is interesting. However it is mandatory that the visited locations cannot be predicted before the area is full. E.g. you read a location, it gives you a pointer. However, keep in mind that AES is trivial on hardware and that CRC32 is doable as well albeit takes a lot of place. 64MB of SRAM is possible (but expensive). You could design an ASIC capable of issuing a 512-bit block every 12ns and write to SRAM in parallel this fast. It would only take 87 microseconds to fill this area in an ASIC. So you need to add substantial operations to either fill or read this area. I'm inclined to think that writing very fast first then performing very expensive lookups might be a solution, but for an ASIC it could allow to design it in two parts using different technologies, such as ASIC for writes and FPGA/CPU for reads. The other option is to count the time it takes to write a 64B cache line on a target CPU and to put enough complex operations (rol/ror, bit reversal, 64-bit div, CRC, AES, etc) to keep the CPU busy during this time. In your example above you have 10ns available, or 15 cycles on small CPUs to 40 cycles on big ones. It seems possible to place a div,rot,crc,aes there and have them computed for free. Some of them are very problematic for ASICs (div) and will not be easily parallelized. Also using different operations for each word prevents pipelining of hardware units in ASICs. So it could be nice to cut each cache line into 8 64b words and perform different operations on each of them. It would be possible to exploit slightly unaligned accesses during the writes to make the filling process very hard to parallelize. Imagine the mux/demux dealing with 8-bit granularity out of a 512b memory bus! That would require 6 layers of 256 muxes each, and would be enough to ruin any hopes of 12ns accesses on SRAM.
wtarreau
This is the continuation of the discussion started at the end of #15.
@bschn2 you make a good point indeed. However then what can be done is to compute a pre-hash of the whole initial message used as an IV for AES transformations for example, and fill the whole RAM area with this. This guarantees you need to use that much writable memory. Then you can perform some random walks there and mix the data until you find a pattern that works. Then it will be the memory fill time which will be a bottleneck. It's actually nice as even on the A53, while the L1 cache data path is 64-bit for reads, it's still 128-bit for writes. So there is less of a bottleneck here for small CPUs. Just as an estimate, if we use 32-bit 1600 MT/s DDR3/4, that's 6.4 GB/s theorical peak, thus 10ms to fill 64 MB. You'd cap at 100 H/s on a small machine, is this too low ?