It’s really frustrating that the HotOS paper itself has no details about the benchmarking, and the blog post just says “redis benchmark”. What was the system setup? Persistence options? What was ported to demikernel? The client writing, the server reading from the NIC? Based on the problem specified in the paper, I assume its reading from the NIC that was implemented in DemiOS
It’s really frustrating that the HotOS paper itself has no details about the benchmarking, and the blog post just says “redis benchmark”. What was the system setup? Persistence options? What was ported to demikernel? The client writing, the server reading from the NIC? Based on the problem specified in the paper, I assume its reading from the NIC that was implemented in DemiOS
This is a super cool idea, and it’s something that sounds fun to play with/try out.
Therefore, I eagerly await the inevitable influx of:
- “you don’t need it”
- “you’re not FAANG enough to justify it”,
-“seems overly complicated my Python-on-Ubuntu-is-good-enough and who needs more”
Style comments telling us why we shouldn’t have fun things like this.
Anyone got anymore comments to add to the bingo-card?
Preemptive cynicism is even worse than regular cynicism.
7-10us for what is a hashtable set/get is really, really bad
I can get a packet out to a switch and back to another machine and in 1-2us
Do you mean 1-2ms?
No, 1-2us is correct for that — in a datacenter, with cut-through switching.
That's really impressive. I need to update myself on this topic. Thanks.
In reality - with decent switches at 25g - and no fec - node to node is reliably under 300ns (0.3 us)
Out of curiosity, how is that measured across machines?
(The first thing that comes to my mind would be to use an oscilloscope with two probes, one to each machine, but I’m guessing that’s not it.)
This is great! I think that there are a lot of latency sensitive applications which really do need to spare the kernel latency.