shanemhansen

I think they are really pulling a "no true Scotsman".

"No true normie would be dissatisfied with this unhelpful response, really it's exactly what a true normie wants"

Just an interesting observation I had about this once when I noticed that kernel quic implementations weren't very fast.

KTLS is mostly useful if paired with sendfile (I'm ignoring io_uring because I'm not as up to date on that). Otherwise you have to context switch back to userspace constantly.

They said bind mounts would still work. I didn't think those worked with remote engines.

Which also seems to imply the client software will expose your laptops filesystem to wherever docker is hosting the serverside piece of Offload.

I've thought of this quote a bunch and I came up with my own addon.

"Some people think that the magic of something wondrous is diminished when it's understood. I feel bad for those people." -- Shanemhansen

Going to write a real banger of a paper called "latency numbers considered harmful is all you need" and watch my academic cred go through the roof.

> AV1 streaming sessions achieve VMAF scores¹ that are 4.3 points higher than AVC and 0.9 points higher than HEVC sessions. At the same time, AV1 sessions use one-third less bandwidth than both AVC and HEVC, resulting in 45% fewer buffering interruptions.

Just thought I'd extract the part I found interesting as a performance engineer.

This actually seems like a simple example of memory request vs limit.

Request the amount of memory needed to be healthy, you can potentially set the limit higher to account for "reclaimable cache".

Another way to approach it if you find that there are too many limiting metrics to accurately model things: is you let the workers grab more segments until you determine that they are overloaded. Ideally for this to work though you have some idea that the node is approaching saturation. So for example: keep adding segments as long as the nth percentile response time is under some threshold.

The advantage of this approach is you don't necessarily have to know which resource (memory, filehandles, etc) is at capacity. You don't even necessarily have to have deep knowledge of linux memory management. You just have to be able to probe the system to determine if it's healthy.

I can even go backwards with a binary split mechanism. You sort of bring up a node that owns [A-H] (8 segments in this case). If that fails bring up 2 nodes that own [A-D],[E-H], if that fails, all the way down to one segment per node.

The unreasonable effectiveness of profiling and digging deep strikes again.

Tcl was my first "general purpose" programming language (after TI-basic and Matlab).

When I started that job I didn't know the difference between Tcl and TCP. I spent a couple months studying Phillip Greenspuns books. It also made me a better engineer because unlike PHP I couldn't just Google how to do basic web server stuff so I had to learn from first principles. That's how I ended up building my first asset minification pipeline that served the "$file.gz" if it existed with content-encoding: gzip.

Nearly 20 years later and I'm basically a http specialist (well, CDN/Ingress/mesh/proxy/web performance).

Tcl is still kind of neat in a hacky way (no other language I've run across regularly uses upvars so creatively).

Shout-out to ad_proc and aolserver.

The closeness of this syntax to graphviz dot is very interesting.

having dgsh output a graphvis file in dry-run mode would be a neat feature.

Fundamentally it's a programming language so all the normal ways of running it apply:

Use their library in your application to evaluate policies.

Run it from the cli.

Embed it in some service like nginx.

The language itself is pretty focused on some prolog-ish describing of what constitutes an allow/deny decision.

You are right but it's confusing because there are two different approaches. I guess you could say both approaches improve performance by eliminating context switches and system calls.

1. Kernel bypass combined with DMA and techniques like dedicating a CPU to packet processing improve performance.

2. What I think of as "removing userspace from the data plane" improves performance for things like sendfile and ktls.

To your point, Quic in the kernel seems to not have either advantage.

I had this for a reverse proxy I developed that did some transformations. At about two critical points if there was an error there was literally nothing we could do except 500 barf.