[1] https://en.m.wikipedia.org/wiki/Rongorongo

DB2 BLU: https://researcher.watson.ibm.com/researcher/files/us-ipandi...

Wildfire "v0", the "failed" HTAP project: https://researcher.watson.ibm.com/researcher/files/us-ytian/...

Wildfire "v1", the shared-nothing architecture over cloud storage (EventStore 1.0?): http://cidrdb.org/cidr2017/papers/p123-barber-cidr17.pdf

DB2 EventStore (EventStore 2.0?): http://www.vldb.org/pvldb/vol13/p3299-garcia-arellano.pdf

Re: my “dilution” comment, i was not thinking about DEs. I was thinking about non-technical people (management, law, accounting, ...) that have been creeping up the Fellowship lately. Also the bluewashed executive that were given a fellowship package to seeeten the pot.

Both levels may reside in different pay bands, but they are both at the executive level. And DEs cannot become fellows, and vice versa (some exceptions to the rule may have existed).

[1] https://en.wikipedia.org/wiki/Ordinance_of_Villers-Cotter%C3... [2] https://en.wikipedia.org/wiki/Language_policy_in_France#Fren...

Then he woke up one morning wanting to reboot his life's work for his class and, undeterred by the fact the original targeted processor did not exist anymore, settled to write his own computer architecture on a Xilinx Spartan.

He then successfully ported the Oberon system and compiler to this architecture to demonstrate to his students.

Just wow.

It was UDP.

> Which is to say, you're saying "detrimental impact on performance" and yet this seems to be a significant win over BSD sockets.

The point I was trying to drive home is that, while 30% overhead reduction compared to BSD socket is nothing to laugh at, a fully user-space UDP/TCP network stack combined with memory-mapped buffer sharing usually gives performance improvement measured in the "x" and not in the "%".

Now, there is not much in terms of experiment protocol in their material so its very hard to tell. You mention uncompressed video so they could be sending humongous frames, which I doubt as no one ever would send raw frames over the network (that would be several MB per frame for a 720p front camera). But if that is the case then the data copy operation becomes the predominant bottleneck and getting rid of one may justify the improvement. But that is not a realistic scenario.

The more realistic scenario is that they sent compressed delta-frames across the network (H264 or HEIF), which would then considerably reduce the transferred payload size. In that scenario, data copy is not the predominant overhead anymore and 30% overhead reduction is underwhelming, telling me that they still are calling expensive operations like syscalls/uIPC on the critical data path.

I am not doubting they have some sort of user-space TCP implementation. I am trying to understand how much of TCP they moved out of the kernel. From what I can gather they still have enough of it in the kernel such that the related syscall/uIPC overhead does not allow more than the 30% performance improvement announced.