User Tag List

Page 1 of 2 12 LastLast
Results 1 to 10 of 15
  1. #1
    Whicked Sick Higor's Avatar
    Join Date
    Apr 2012
    Location
    Full sail ahead!
    Posts
    3,676
    Country:

    Concept: dynamic updaterate > higher playercount.

    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.
    Last edited by Higor; 08-25-2012 at 02:34 PM.
    ------------------------------------- * -------------------------------------

  2. #2
    Administrator SAM's Avatar
    Join Date
    Jan 2011
    Posts
    8,296
    Country:
    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!

  3. #3
    Whicked Sick Higor's Avatar
    Join Date
    Apr 2012
    Location
    Full sail ahead!
    Posts
    3,676
    Country:
    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.
    Last edited by Higor; 08-25-2012 at 05:18 PM.
    ------------------------------------- * -------------------------------------

  4. #4
    Administrator SAM's Avatar
    Join Date
    Jan 2011
    Posts
    8,296
    Country:
    This should be good to use on any server then correct?

  5. #5
    Whicked Sick Higor's Avatar
    Join Date
    Apr 2012
    Location
    Full sail ahead!
    Posts
    3,676
    Country:
    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.
    ------------------------------------- * -------------------------------------

  6. #6
    Administrator SAM's Avatar
    Join Date
    Jan 2011
    Posts
    8,296
    Country:
    The server is on a 1gbps port. Is there any way to set maxclientrate?

  7. #7
    Whicked Sick Higor's Avatar
    Join Date
    Apr 2012
    Location
    Full sail ahead!
    Posts
    3,676
    Country:
    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.
    ------------------------------------- * -------------------------------------

  8. #8
    Rampage Feralidragon's Avatar
    Join Date
    Jan 2011
    Posts
    374
    Country:
    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.
    Last edited by Feralidragon; 08-26-2012 at 10:06 AM.

  9. #9
    Administrator SAM's Avatar
    Join Date
    Jan 2011
    Posts
    8,296
    Country:
    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

  10. #10
    Moderator .seVered.]['s Avatar
    Join Date
    Jun 2011
    Location
    Near a River and Under a Bridge
    Posts
    2,125
    Country:
    Quote Originally Posted by Feralidragon View Post
    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.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. 4Way Siege Concept for Pugs
    By SilverWing in forum Code Reviews
    Replies: 16
    Last Post: 06-12-2013, 03:15 PM
  2. Concept: The concentrated resource orb.
    By Higor in forum Code Reviews
    Replies: 13
    Last Post: 02-11-2013, 08:07 AM
  3. Concept: Dynamic Siege Maps
    By Scourge in forum Map Making, Suggestions & Questions
    Replies: 9
    Last Post: 01-29-2013, 08:32 PM
  4. Concept: Improving spectator quality
    By Higor in forum Code Reviews
    Replies: 12
    Last Post: 08-19-2012, 10:57 PM
  5. Map Concept
    By Higor in forum Map Making, Suggestions & Questions
    Replies: 100
    Last Post: 08-16-2012, 01:02 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •