ID:2197174
 
Resolved
world.map_cpu has been added to help track CPU usage for map-send operations. This is not a full profiler but it should help some games gauge how server performance is impacted by map complexity and player load.
Applies to:DM Language
Status: Resolved (514.1543)

This issue has been resolved.
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.

Sendmaps().
bump

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)
bump
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
Bump for 513.

Currently some ss13 servers have started trialing getting this info with a dll and call()() and memory offset reading, and its proving successful.

Turning it into an officially supported value for the sake of universal accessibility would be appreciated.
bump for 514?
oranges, now is when you are suppose to bump feature requests, after the beta has gone stable and work has begun on the new beta. =P
Re-posting as I am unable to locate the duplicate topic.

The addition of world.tick_usage was a big success of letting us measure how much of the current tick is used and to have specialized code implement that allows us to prevent the tick from overrunninng, thereby reducing perceived lag.

It'd be nice to have something similar for measuring the time of map updates getting sent to players.

This is already done, on SS13, with an external .dll called "extools", but being able to do this natively would be great as it'd allow us to better control for player perceived lag to players without dependency on an external .dll.
In response to Fox P McCloud
It's the most useful feature of extools as of right now, but being dependent on extools is a very slippery slope. This would be a very good addition.
Page: 1 2