Hacker News Reader

Comment by atoav | Hacker News Reader

Okay, this is really cool. Basically a 10G network connected ultra low latency key-value-store that you talk to using a set of custom UDP commands (of course as a proof of concept).

I really like the idea of stripping away essentially everything that is not needed and being left with what is.

If this is done all the way, it would be an incredibly sturdy and reliable (but a bit small) key-value-store.

View on HN

To really optimize for latency, perform read lookup (and maybe write slot resolving) before the entire UDP packet is fully buffered and checksum verified.

this isn't 10Gbit.

Yes, but it would be if implemented on an FPGA with 10G capable transceivers. The hashtable is capable of looking up a key every clock cycle so it is actually capable of a fair bit more than 10G for lookups.

> The hashtable is capable of looking up a key every clock cycle

Does the SRAM latency still allow for single-cycle reads at 10G?

Yes. My comment above glosses over some details.

The SRAM clock and the Ethernet clock can be independent. The SRAM clock rate is what determines the rate of lookups for a single cuckoo hashtable.

On a modern FPGA, the SRAM clock can run up to about 500MHz. So, if you pipeline things, you can get 500 million lookups per second in the FPGA fabric. The maximum packet rate in 10G Ethernet is around 15 million/sec. So, no matter how you design the protocol you use to communicate with the FPGA, if you only request a single lookup per packet, you will be well below the maximum rate the RAMs can support.

Of course, I haven't actually built any of this. The clock rates in the blog post are much lower, and the chip is much smaller. So, this is all an educated guess.

For sure! 10G can be done on FPGA's at 312.5 Mhz using 32-bit words. BlockRAM on higher ended chips reaches 450Mhz+. If you wanted to it could even run at 156.25 Mhz with 64-bit words. This way it is even doable on lower ended FPGA's.

This is the 100Mbit PoC for an idea that clearly scales to 10G if you buy an expensive enough FPGA.

This write up seems to only refer to on fpga ram which is fast, but very limited. In fact the author seems to completely ignore using any ram external to the fpga. Certainly fpga have capacity to interface with DDR ram of various types, and the more expensive fpga the better, but that also impacts the performance quiet a lot, making performance more in line with a normal non specialized device; beacause memory access time dominates.

> making performance more in line with a normal non specialized device; because memory access time dominates.

Well, yes. With a short enough piece of network cable it's probably lower latency to query a different one of these devices a short way away than wait for DRAM to very slowly charge up a row.

Yes, this is about building a small hashtable in the RAMs internal to the FPGA. As you pointed out, things would slow down a bit if you had to go to external RAM.

However, if you are building a hashtable in external RAM that is accessed via Ethernet, I think there are still some performance gains to be had with an FPGA compared to a non-specialized device.

For one, you get to skip the PCIe bus with an FPGA, reducing latency, since the Ethernet transceivers go straight into the FPGA fabric. Also, while I don't know a lot about power consumption, I expect it would be a fair bit lower on a dedicated FPGA compared to a server performing the same work.

Reply on news.ycombinator.com