Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
I already know byond keeps track of how long it takes to send out client map updates (internally called sendmaps() iirc).

If we could get access to that number, our anti-lag measures could stop guessing that it needs to save n% of a tick for byond and know exactly how much to save (and our player limits could take this into account and auto scale the popcap based on load).

Right now one server has over 80 people, and the other has under 40 people. Having to manage missed or late byond ticks is a pain in the ass, atm 20% of the tick is left for byond, but that seems to be too much for the low pop server (as it has a backlog but a cpu of 88 and a tick drift of 5%), and not enough for the high pop server (that has a tick drift of 39%), and we don't really have a good way to calculate that.

I could try to make it scale per user, but that would only work for one cpu, another server (since we do have downstreams that use our code) wouldn't be able to use it as their cpu could take longer or shorter per client to do sendmaps(). so thats imperfect. (also, different mobs cost more because of things like sight and view differences)
Maybe log *all* the internal byond processes?
It'd be nice to have programmatic access to a lot of profiler information for creating intelligent allocators for ticktime.
There is only one internal byond process.


Almost all of the tick overruns we get (that players perceive as lag) is from misjudging how long it is going to take byond to do the client map stuff (and its other internal stuff).

We NEEEDS this.
If you're worried about tick overruns this is rather useless compared to adding a "peak" feature to the profiler so you can add delayers into or break up procs that are too long and cause lag spikes.
Clusterfack, I track missed ticks avgs as a stat panel all players can see.

At 20 pop its like ~3-7%

At 80 pop its like ~20-30%.

The fact it scales with pop count the way it does tells me it's more likely to be sendmaps()

It even is as high as it is with most of the station is destroyed (so no lights/atmos to process) and most of the players are dead (so its not as likely to be actions the players are performing)

Running micro profiles during these high tick_drift periods shows nothing obvious in game code that could be causing it (but i'll agree, it is impossible to know)

The primary point is that atm just about every ss13 codebase assumes that about 20% of the tick is enough for byond to do what it needs to do.

This assumption is a bad one, its too much at low pop and not enough at high pop, and this is ignoring that it isn't enough at higher tick rates because 20% of a tick becomes less time.

A way for code to know, for sure, without any tomfoolery would be super helpful.
It's only "impossible to know" because the profiler isn't giving you the information necessary to find lag spikes.
Listifying this for 512. Adding metrics in the past seems to have been a good thing for SS13 across the board, and this one would be helpful.
But how could one possibly use it?
Track how long SendMaps was over the last 20-30 ticks and reserve that much time into each tick.
Ya, What I would do is track a 1, 5, and 15 tick avg, and use the higher of the 3 to tweak the amount reserved at the end of each tick for byond. (the TICK_LIMIT_RUNNING define)
This would indeed be a nice improvement. And if it is already logged, it should be pretty straightforward adding it, right?
In response to Lummox JR
Lummox JR wrote:
Listifying this for 512. Adding metrics in the past seems to have been a good thing for SS13 across the board, and this one would be helpful.

Is this still a plan? It would be a nice asset to optimize game performance even more, especially for us