@yosh Uh, uhm.

[skade@hachyderm.io]

@yosh Uh, uhm. I took a PhD course on how to model this and arrive roughly at that number (long story on how I was allowed to do this, even though I only hold a Masters). We did this on server-client systems, but what is a train but a request traveling through the internet.

Essentially, you can take timed petri-nets (a form of state machine with multiple states being active at once - think "trains on routes, in stations") and use a statistical function to model how long it takes for an token (train) in that net to go to the next state (every edge has a different function, runlength). You can then actually reason _locally_ about states at every node using markov chains. ("how many trains are at this station at any time with which probability") and then _back_-calculate that into delay probabilities.

Biggest learning: this isn't linear. It's almost linear, until the point it breaks, where delays grow rapidly and catastrophically over the network.

Which is also why 70% system load is about the moment where you should start thinking about upgrading your servers.

Sorry for the brain dump :).

[msfjarvis@androiddev.social]

@skade @yosh That's super fascinating! Do you have a recommended resource where I can read about this?

[skade@hachyderm.io]

@msfjarvis @yosh https://web.archive.org/web/20210425095523/https://www.cs.mun.ca/~wlodek/

Is the archived website of our professor back then.

At a quick glance, I think this paper seems to discuss most of it. https://scispace.com/pdf/modeling-and-performance-analysis-of-priority-queuing-3g6mmrdnxh.pdf

Like, this seriously informed my intuition for network applications, which was my career before Rust :).

[aeva@mastodon.gamedev.place]

@skade @msfjarvis @yosh as it happens dynamic resolution scaling and similar systems in video game rendering also work like that. 100% GPU load causes everything to go to hell (frame drops and worse) so we try to find setpoints that get us within some threshold below that. I don't remember what the magic % ended up being for the games I've worked on, but we try to run as close to the wire as we can and still have a stable cadence.