PDA

View Full Version : Concept: dynamic updaterate > higher playercount.



Higor
08-25-2012, 02:30 PM
Running at higher framerates improves the quality of the server, players aren't as difficult to hit (making it similar to offline games) and most timers and events occur with proper timings, that will most likely match those of the clients.
It also reduces the latency between frame processing, turning it into a low ping server.

But there is a problem, and that is, the higher the server framerate, the more updates per second will most things get.
This happens because there are actors that have their NetUpdateFrequency value greater then 20, which is the default dedicated server framerate, therefore, increasing the framerate increases the updates per second.

In Siege specifically, players are always being updated, even if outside of the player's area (network relevancy) so in a server with 20 players all 20 players are being updated, spectators included.
With the public server settings as an example, which runs at 65 frames per second, the data output is huge.

The server actor I plan to build will adjust the individual actor's update frequency in runtime, depending on player count, this way, the server player count can increase with no lag at all.
There are limitations of course, when player are updated less than 22-25 times a second, their movements become odd, like in a typical low bandwidth server.

The table at which rates are specified will entirely depend on playercount and will affect players every 10-20 seconds.
It would also run customized loops for other types of actors (like buildings).

Example table:


Player rate
Spectator rate
Min Players
Max Players
Other rates (scaled down %)


100
80
0
3
100


80
60
4
8
90


60
40
9
13
70


40
20
14
20
35


24
8
21
30
15



Since spectators don't do anything other than appear on the player's scoreboard, their rate is kept very low.
This way, a server can increase the framerate or playercount and not suffer from lag spikes.

Also, to the time a ping takes to return, add the time a frame is processed on both ends:
My case:
Ping > 185 ms
My machine (75fps) > 13 ms
Default server framerate (20fps) > 50 ms
Siege public framerate (65fps) > 15 ms.
Add that, and you have the real ping, so increasing server framerate and decreasing actor's update rate isn't the same as keeping the server framerate low.

SAM
08-25-2012, 05:03 PM
This sounds like an excellent concept...I see how lowering spectator tickrate would have better affect on server while not affecting the client at all. If you are coding this I'd encourage you to finish and definitely test this on the server for you! It might even be possible to offer a higher tickrate with this and all the code optimisations. I really can't wait to see the positive impact on gameplay and server. SW PLEASE GET MOVING!

Higor
08-25-2012, 05:21 PM
On the new test version, 50 containers only increased server CPU processing time per frame from 0.3 to 0.8 milliseconds... (plus 0.4 for network *3 players*).
That leaves a full 16 milliseconds before the next tick happens on the 55 FPS test server, it is SUPER optimized now to the point of working on any low end computer at fullspeed.

--- Updated ---

Also, this would be a separate ServerActor, no need to replicate either.

SAM
08-25-2012, 06:28 PM
This should be good to use on any server then correct?

Higor
08-25-2012, 06:31 PM
It would simply iterate thru all players every X seconds and change Update rate properties, no need to send or anything.

I manually did the updaterate changes in a 100 fps setup and the results were impressive

Now about the table values... we need to study the maximum server Upload Bandwidth, and the maximun Client Rate and the MaxPlayers value in order to get an optimized table.

SAM
08-25-2012, 06:38 PM
The server is on a 1gbps port. Is there any way to set maxclientrate?

Higor
08-26-2012, 12:16 AM
Servers usually have the MaxClientRate on 20000, while MaxLanRate at 80000.

Btw, info collected so far:
12 players, 5 specs - 55 fps - 16kb/s
10 players, 4 specs - 55 fps - 12kb/s

The adjuster is finished, gonna do tests tomorrow and send it.

Feralidragon
08-26-2012, 10:01 AM
Hmm, it's a nice concept but I have sort of mixed feelings on this if I understood it correctly, reasons being:
1 - Players and siege buildings aren't the only actors replicating stuff, there are many other actors replicating stuff at the server tickrate (for actors with an update rate of 100) to the client.
Having that said, you may be creating a situation where the players are replicated less frequently than other actors which your mod does not affect, and that may lead to unexpected behavior on said actors, if we think on this in a global generic way and not siege alone. Personally, I can't think of a situation like that now, but changing player update rates over time is generally an unsafe operation, and in the end you will trade lower bandwidth usage with higher CPU usage (so the CPU will be more busy and the bandwidth less).

Reducing all the actors update rate is not a good option either, since in that case it's simply better to reduce the server tickrate (down to around its defaults, 20fps or 30fps) or reduce the update frequency of all the buildings in the siege gametype to a small constant enough value itself and perhaps make the actor itself change its own value if required, and in a more personal opinion, I wouldn't like to think having other mods around having their values forcefully tweaked for what your mod "thinks" it's best, as again, this may create "bugs" on said mods, bugs then reported to the original makers of the mods, and which they have no clue and may spend hours figuring out what's wrong.

2 - Sudden changes on update rate will have an impact on more sensitive players. A constant upkeep, be it lower or higher is generally best, since you also may create a situation where the player experience will degrade when more players join the game, although the server can perfectly keep the constant update rate and the same experience.

Anyway, interesting concept, but it's not the right way to make a more stable server or being able to add more players in my honest opinion. Still, I would like to see if this ends up working out or not, so keep it up. :)

SAM
08-26-2012, 11:52 AM
It's at the very least an interesting concept which should be tested though. The code optimisations were released yesterday on the PUG. When PUB is back the version is also ready for release. I'm looking forward to this release and the hopefully positive feedback which is credits to all your individual hard work efforts and time. Siege has been missing an active dev to push it forwards. Thanks for stepping up :)

.seVered.][
08-26-2012, 11:59 AM
Hmm, it's a nice concept but I have sort of mixed feelings on this if I understood it correctly, reasons being:
1 - Players and siege buildings aren't the only actors replicating stuff, there are many other actors replicating stuff at the server tickrate (for actors with an update rate of 100) to the client.
Having that said, you may be creating a situation where the players are replicated less frequently than other actors which your mod does not affect, and that may lead to unexpected behavior on said actors, if we think on this in a global generic way and not siege alone. Personally, I can't think of a situation like that now, but changing player update rates over time is generally an unsafe operation, and in the end you will trade lower bandwidth usage with higher CPU usage (so the CPU will be more busy and the bandwidth less).

Reducing all the actors update rate is not a good option either, since in that case it's simply better to reduce the server tickrate (down to around its defaults, 20fps or 30fps) or reduce the update frequency of all the buildings in the siege gametype to a small constant enough value itself and perhaps make the actor itself change its own value if required, and in a more personal opinion, I wouldn't like to think having other mods around having their values forcefully tweaked for what your mod "thinks" it's best, as again, this may create "bugs" on said mods, bugs then reported to the original makers of the mods, and which they have no clue and may spend hours figuring out what's wrong.

2 - Sudden changes on update rate will have an impact on more sensitive players. A constant upkeep, be it lower or higher is generally best, since you also may create a situation where the player experience will degrade when more players join the game, although the server can perfectly keep the constant update rate and the same experience.

Anyway, interesting concept, but it's not the right way to make a more stable server or being able to add more players in my honest opinion. Still, I would like to see if this ends up working out or not, so keep it up. :)

I love the way you VOLLEY with your posts, it keeps me going in the post to find out what you "really" think... "I have sort of mixed feelings" then.... "may lead to unexpected behavior", then... "...if this ends up working out or not, so keep it up."

I agree there may be some unexpected results. I'll explore this today while testing to monitor the actors and narrow down the possible side effects to a more detailed list. Perhaps we may get some 'Preferred' side effects too.

Higor
08-26-2012, 12:23 PM
It is an experiment after all, what happens here in Siege, is that all players have bAlwaysRelevant = True.
My best guess that was done is: Visor Support (on it's time), Camera support (also removed), Scoreboard support, Maps with lots of translucent glass, Name of builder support, making ZP more reliable, and some other things i may be missing.
At least half of them could be fixed without the need of having players being bAlwaysRelevant=True, but that will make players invisible through glasses in existing maps and give them the ability to camp without being seen (replication bug on CTF-Face for example).

ListenServers replicate stuff at the host player's variable framerate, I even tried changing the NetUpdateFrequency values a few times and didn't see anything weird, apparently the replication system is far more flexible than we expected.
I made the player count (netconnection players) checks to happen every 10 seconds just in case.

I am also aware of the existance of other actors replicating at higher rates...
- Inventory excluded (rate = 10 in most cases).
- Guided nukes, we better not touch these, we want to be able to kill those.
- Projectiles, excepting nukes and translocator targets, most are bNetTemporary=True.
- Info actors have a rate = 4, PRI's = 2.
- Effects are mostly bNetTemporary.
- Decorations are mostly bStatic.
Which leaves us with mostly pawns, there's an extra list with 8 pawn subclasses, that are affected by OtherRatePct.
Ill give an ini file with a default table and ScriptedPawn and StationaryPawn, this way monsters and buildings will be scaled down as well (So we get rid on the after-Neutron lag with this).

This will be a simple ServerActor which won't even need to be sent to clients, which makes it easier to review or remove if something happens.
I have no idea if this will make the server crash more often than the goddamn DDoSers make it do, but it will be a nice experiment.

Higor
08-26-2012, 01:47 PM
Ok, I tried opening 5 UT's and a server, thing is I can't move all 5 players at once to simulate a normal playing environment lol.
I would invite players for a 5 minute test, but my 50 kb/s upload stream would ruin the test, this is as far as I can go.

Link:
http://dl.dropbox.com/u/58384316/UT99/NetRateMod.zip

The default config includes monsters and buildings, the default tables are the ones posted in this thread.
Bear in mind, these values are arbitrary and support up to 30 players (counting specs).
Modify the tables as you wish depending on the server capabilities.

PD: Table supports up to 8 different cases, and upon map start the NetRateMod fixes its own config if some parameters are invalid.

Feralidragon
08-26-2012, 02:11 PM
[;37052']I love the way you VOLLEY with your posts, it keeps me going in the post to find out what you "really" think... "I have sort of mixed feelings" then.... "may lead to unexpected behavior", then... "...if this ends up working out or not, so keep it up."
That's what the "mixed feelings" expression means: in one hand I think this is a nice and interesting concept, in another there are a ton of possible bad outcomes from this which may happen now, or only with specific mods later on.


It is an experiment after all, what happens here in Siege, is that all players have bAlwaysRelevant = True.
My best guess that was done is: Visor Support (on it's time), Camera support (also removed), Scoreboard support, Maps with lots of translucent glass, Name of builder support, making ZP more reliable, and some other things i may be missing.
It was done solely because of the "Visor Support" back then. When Koala was doing those features, he asked me how he could make the players appear on the visor online, and I explained he could make either all players bAlwaysRelevant=True (easy but not so good way) or somewhat let the server do that job and replicate info without having to make the player relevant (harder way, but which avoided bAlwaysRelevant=True).
I warned him that bAlwaysRelevant=True could make the server laggier, he tried anyway. But I thought bAlwaysRelevant=True was removed from the players after the visor was also removed, so I wonder the same: why is it still on?

.seVered.][
08-26-2012, 02:30 PM
But I thought bAlwaysRelevant=True was removed from the players after the visor was also removed, so I wonder the same: why is it still on?

Footnote: the bAlwaysRelevant is still enabled... and the the VISOR was never "removed" it was only taken out of the sgConstructor. UNTIL NOW that is...Your welcome... and thank you Higor for your passing grade on 'integrity'. I give you an A or 5.0 or 4.0? what is that scale these days..sucks to be old.

Higor
08-26-2012, 03:41 PM
If zeroping wasn't running on these servers, I'd disable bAlwaysRelevant and add manual fixes for maps that do extensive uses of translucent glasses.
But since it isn't I vote against it, I've suffered enough against unkillable players due to ZP + non-relevant players, and believe me players here take a day or two to find exploits and use them.