4 ms·

Their system works well on a RISC-V, which is a deeply pipelined but in-order architecture running at only 50MHz, with very fast memory relative to its clock sp

Their system works well on a RISC-V, which is a deeply pipelined but in-order architecture running at only 50MHz, with very fast memory relative to its clock speed. I'd like to see results compared to a more reasonable CPU implementation. For example they could have used a Xilinx Zynq, which includes hard Cortex A9 cores, which are out-of-order and superscalar. They also run at a much higher frequency relative to the memory speed. I think this paper vastly underestimates memory constraints of higher performance systems.

ms705 12y ago
Another comparison point (curiously not referenced in the above paper) is this similar effort: https://www.usenix.org/conference/hotcloud13/workshop-program/presentations/blott https://www.usenix.org/conference/hotcloud13/workshop-progra... [PDF/slides/video] From a quick skim, the Xilinx work synthesises the entire network stack (including TCP) in hardware, unlike the above study, which only supports UDP in the HW traffic manager. The numbers in the Xilinx paper are more attractive than what this study found and the paper also includes power measurements (since Joule/request is one metric on which FPGAs and hardware do quite well compared to software). That said, much of the latency gain likely comes from bypassing the OS kernel and its generalised network stack. There is plenty of existing work (unfortunately also not referenced in this paper) that does this and which achieves very low latency, albeit -- to be fair -- on x86 hardware. (Examples: Arrakis [1], IX [2] and MICA [3].) [1] -- https://www.usenix.org/conference/osdi14/technical-sessions/presentation/peter https://www.usenix.org/conference/osdi14/technical-sessions/... [2] -- https://www.usenix.org/conference/osdi14/technical-sessions/presentation/belay https://www.usenix.org/conference/osdi14/technical-sessions/... [3] -- https://www.usenix.org/conference/nsdi14/technical-sessions/presentation/lim https://www.usenix.org/conference/nsdi14/technical-sessions/...

ms705 12y ago

Another comparison point (curiously not referenced in the above paper) is this similar effort: https://www.usenix.org/conference/hotcloud13/workshop-program/presentations/blott https://www.usenix.org/conference/hotcloud13/workshop-progra... [PDF/slides/video] From a quick skim, the Xilinx work synthesises the entire network stack (including TCP) in hardware, unlike the above study, which only supports UDP in the HW traffic manager. The numbers in the Xilinx paper are more attractive than what this study found and the paper also includes power measurements (since Joule/request is one metric on which FPGAs and hardware do quite well compared to software). That said, much of the latency gain likely comes from bypassing the OS kernel and its generalised network stack. There is plenty of existing work (unfortunately also not referenced in this paper) that does this and which achieves very low latency, albeit -- to be fair -- on x86 hardware. (Examples: Arrakis [1], IX [2] and MICA [3].) [1] -- https://www.usenix.org/conference/osdi14/technical-sessions/presentation/peter https://www.usenix.org/conference/osdi14/technical-sessions/... [2] -- https://www.usenix.org/conference/osdi14/technical-sessions/presentation/belay https://www.usenix.org/conference/osdi14/technical-sessions/... [3] -- https://www.usenix.org/conference/nsdi14/technical-sessions/presentation/lim https://www.usenix.org/conference/nsdi14/technical-sessions/...