No announcement yet.

netcode and rating implementation discussion

  • Filter
  • Time
  • Show
Clear All
new posts

  • netcode and rating implementation discussion

    EDIT:i'll update thread with more information once the forums are fixed

    Thread for the incoming 1-2 patch away commands that are currently being experimented on to re-implement client-side rate limiting.

    NS2 Engine/server features (dedicated server) (console commands)

    NS2 Engine has engine locked "rate" command.
    Server-side has, updaterate and interp.

    interp: (default of 100ms) my reccomendation for your server 0.05 (50ms) if on competitive gameplay, public would probably benefit from the default due to laggers playing on the servers, however change this if you change the tickrate/sendrate
    movementrate/mr: also note this affects the smoothness of how it feels to play in a server, ie:your commands and how many packets are being sent to the server, it's like cmdrate from ns (way npc/ai reacts + gametime, if you change tickrate please change this)
    sendrate: (basic form of updaterate rate, however you cannot set this higher then the tickrate, ie: if the default tickrate is 30, it'll also be locked to 30, the default sendrate = 20.
    tickrate: (can change to as high as 100ticks )

    In the experimental patch that is being worked on they want to bring back server/client side rate limiting, if hosters want to allow users to use more of there server and client bandwidth this is possible. Spark engine comes with a hardcoded "rate" command that sets the "bandwidth limit per player" currently what happens is that you cannot change this rate on either server or client, this is set to change to allow both client/server change it. The other client-side features are being optimised for the spark engine... so expect to see, client-side rating sometime soon.

    Ironhorse says:
    One of the symptoms we found in testing the highest rates that a very powerful server could handle, we found that many clients would run into a wall processing LUA, creating hitches.
    Meaning at the highest levels, (~4x the current update rates) the bottleneck became processing the world on the client
    But this doesn't mean you can't currently increase values a bit for improvements, with little to no downsides, so long as your server can handle the extra traffic and processing and you know precisely how to configure it. Any improper configuration will have issues.
    Tickrate in NS2 is just like the tickrate from Source games. The only major difference here is Source relies on the ticks for lag compensation, so higher tickrates increase the accuracy of the lag compensation by a small margin.
    Move rate in NS2 is comparable to cmdrate from Source, which is how often client commands (input) is sent to the server. This impacts part of how 'responsive' the game feels, mainly to your inputs (weapon switches etc).
    Update rate in NS2 is like update rate from Source, which is how often server updates are sent to a client. This impacts how quickly your client responds to changes in the game (you taking damage, other players dying etc).

    To push the update rate even higher, you would need to increase the move rate (from above) and the tickrate, and the move rate drastically increases CPU usage.

    ex_interp, cl_interp, and cl_extrapmax to offset changes made by interp.
    Last edited by eff; 30-05-2015, 12:19 AM.

  • #2
    Hope they provide more in-depth technical explanation of sendrate an how to scale MR value against tickrate


    • #3
      Originally posted by kid View Post
      Hope they provide more in-depth technical explanation of sendrate an how to scale MR value against tickrate

      ^taken from the UWE forums.

      also based on the last link there matoso says to revise the last link there with this information.

      MATOSO SAYS: Ouch, you had to post ... turns out I was quite wrong. Once I had engine access, I checked it out and realized that NS2 is a bit smarter than the HL/Source engine.

      Every move from a player is immediately processed and changes the state of the world. So the network updates being sent out to a player actually reflects the state of the server at the moment the update is sent - and as the world is being continously updated pretty much every ms, every network packet contains the freshest information at that moment.

      Sure, the state of the AI units will be either one or two updates old, but who cares how AI units move anyhow... it's just players that matters.

      There was a bit of a bug there (fixed in 267) where the world time (which reflects the latest time a move or update was processed) was used for AI units, whose position actually reflected the last time they were updated (same thing for all players; they are also timestamped with when they were updated last). This resulted in quite a lot jerkiness for moving AI units, which was quite annoying (well, for 266 players ... _is_ ... but not for much longer!)

      The NS2 interpolation code actually searches for state snapshots for each individual players timestamp to find the best snapshot data for each one. Just to keep it smooth.

      pretty interesting to read, i've already been keeping up to date with most of it myself, but it's quite interesting when sometimes you're browsing techincal discussion or even just in game and see some of the devs, or CDT members whom are willing to gladly leak information out depending on how you ask it, or who you are at the time. But yeah, keep your eyes peeled for individual client-rates soon enough with some server-side enhancements too, it'll greatly benefit those people with big pipes if ya get what im saying

      “interp”, “mr” and other server settings are now sent to clients when they join.
      AI units now move smoothly, uses proper world time when calculating position.

      ^this is a problem because tickrate was/might still be interfering with ai/npc and world time. but for now just leave it at default on your server unless your drifter/building time and all the game functions seem to be running smoothly, it's actually not much of a problem from what i can see, i don't think you need to actually change MR anymore, that was a pre-last patch update that was fixed (?)

      When it comes to performance, you need to measure the performance of the server at the highest possible load to ensure that it can still respond swiftly to player input even when the game is at its most loaded - the highest load is possibly when the game is at its most intense, and players need the best possible performance.

      The server kinda starts sucking badly when it gets overloaded; it's only way of saving CPU is by lowering the tickrate, and as the tickrate also limits the sendrate (how often the clients gets updated), you will start to get into some real trouble with the interp buffer.

      The interp[retation] buffer variable is set at 2/standard sendrate or 100ms to ensure that what you see on the screen is INTERPOLATED between two known network update states. Using 2/sendrate allows you to compensate for a bit of network latency variance/loss.

      If no network update arrives in time (ie, the interval between two updates are >100ms) to fill up the known network states when the client needs to see it, the client will cross its finger, and simply EXTRAPOLATE from the last two packets. Ie, it will show things in positions it GUESSES them to be in.

      Once a new network packet comes in, then the client will show things in the new known position , which may not have been at all like what the client guessed at, resulting in the entities instantly moving from one point to another - this is what is behind teleporting/rubberbanding.

      Guess what happens when the server tickrate drops below 10, and the sendrate interval then goes to > 100ms? You will have interp overrun pretty much constantly... resulting in everything teleporting all over the place, and the game becoming an unplayable mess.

      So it is INCREDIBLY important that the server tick interval NEVER gets close to 100ms - that's not an average, bw - that's the absolute upper limit of the length of a server update tick; if ANY server tick takes longer than 100ms, you WILL get a MASSIVE BUNCH OF RUBBERBANDING AND TELEPORTING FOR EVERY PLAYER ON THE SERVER.

      To ensure that does not happen, you want the server ticking along at a stable, relaxed 33ms per frame - or 30 ticks. If you start dropping below 30 ticks, then you don't know if you seeing 29 ticks at 30 ms and one tick at 110; the load each tick can vary quite a bit.

      Now, that being said, the ability to monitor server load in 267- pretty much ... isn't there. Sure, you can see the server ticks and all, but lower tickrates don't really give you enough information to accurately judge just how overloaded the server actually is.

      Anyhow, we are going to need a new way to measure server performance, because with tickrate unlocked, we can't judge server performance by comparing actual tickrate to 30 anymore (and lowering tickrate is actually a good way to increase server performance; In NS2, tickrate only* controls non-player unit actions).

      * Well, it also limits max sendrate, but for this purpose it's irrelevant; if you are going for maximum players, you do not want to increase sendrate. Actually, you might want to DECREASE sendrate and increase interp if you really want to save CPU cycles.

      The server is already accumulating "idle" time, ie time where it is just waiting for more player input to come in, so it should be possible to use that to show the actual server load - a 75% loaded server would have 25% margin until it starts running flat out. Should be able to do some fiddling with seeing how long time incoming player move packets are queued up to indicate how much > 100% the server is running at as well.

      In addition, some kind of "bad frame" measurement; ie the worst server-tick-length for the last 10 seconds or so can also be reported. And logged if > the interp setting.

      Once we have that, we don't need to argue about if a server is running well or not - everyone will be able to see it.

      And yea, there are things that can be tweaked for overloading servers - you can set mr/interp dynamically for example, so if the server is getting overloaded, you can lower the client moverate / increase the interp buffer. Should be pretty easy to add a Lua interface to the server performance indicators so you can run a Lua script to take action before the server croaks.


      • #4
        I was asking for decrease in interp and increase in update/cmdrate for ages. Then I realised that Aus server providers can barely run the game as is... What makes you think aus servers will even be able to support a NS2 server running with increased hardware requirements?


        • #5
          Originally posted by mf- View Post
          I was asking for decrease in interp and increase in update/cmdrate for ages. Then I realised that Aus server providers can barely run the game as is... What makes you think aus servers will even be able to support a NS2 server running with increased hardware requirements?
          Keep in mind that this thread wasn't specifically for the server-side benefits, but more so the upcoming clientside ones, in that respect let me talk about my experience.

          My conclusion is interesting to note, because i did watch the performance of the server and it seems to be that the server is using only a little more processing power, as you know ns2 server doesn't max out your core useage but it does increase with the tickrate increase. You may not realise but instead of the spikes of lategame ticks from 30< and below late game, the tickrate set at 60 won't drop dramatically so it's not very noticible, i even underclocked my hardware to test this theory, the server wasn't even struggling at all at 4ghz with 16people late game, when i downclocked it and upped the tickrate the lategame did start spiking due to the 500mhz loss in processing power per core, but on the other hand it was dropping from 60 ticks down to around 40/50 which had an unnoticeable affect on how people perceived the actual gameplay. However the same requirements for server @ 4.5ghz still stand, you'll not drop below 60/59ticks with that.

          I don't mean to offend server operators here, but i believe that the benefits of these commands when in use to optimize can be beneficial, last week i hosted a 60ticks server, with a sendrate of 60(actually 59, because it seems to have a problem with setting it to 60 when tickrate is 60, very silly. just to do some testing, the interesting thing that happened was that the server was actually pretty stable, i had 16 and 18 players on the server and the only times the tickrate dipped was right when the game ended as it put everyone back in the readyroom and when the map changed, and it dipped from 60 down to 30 to meet the reseting state of the engine default tickrate.

          This server was from home so keep in mind the restraints of my fibre to the home connection, i do get 3- 10ms sydney wide which is nice

          (downclocked 16gb 1600mhz ram to 1333mhz due to ramdisk problems)
          ramdisk, and a modified consistency checker which only checked the main .lua files that wouldn't allow actual physics/modified textures etc.
          tickrate 60
          sendrate 59(60)
          mr 50
          interp 0.05

          people were loading into game at 10seconds, while i consistently on lan was <6seconds, keeping in mind when i personally join internet servers i get a 6-9second loading time due to the nature of my setup and tcp/ip settings.

          The pros of the higher tickrate was that marine hits were actually connecting, skulk bites were actually hitting for people who had problems with other servers, less hitching oh and did i tell you that alien movement is now fluid more so then not? the server was used the whole day as aposed to dangerzone/iz3d but it was only a test, most of the time the server was only using 25% of each core, even when disabling that was alright because that is all it needed.

          The cons, people who were already not very good at aliens became worse because marines hit registration was far more accurate. Foreigners complained of there bullets missing more often(see tickrate + sendrate), and people complained about spectate being sort of delayed, an that just goes to show how the difference between ticks + interp had such an affect on the gameplay.

          The problem is not so much the hardware requirements, but allowing clients use more of the servers hardware. I could comfortably host a 16player 100tick server with a sendrate of 60 to account for peoples FPS/monitors etc but then the problem will start being that the clients PC's will start to lag because they aren't capable of actually of the amount of processing power. As you said is the cmdrate which at the end of the day is merged currently with tickrate/interp combos which is pretty pathetic could be beneficial if they allowed clients to control this to counteract some of the current problems.

          edit:For reference a post a few months later showing my internet speed and NBN
          Last edited by eff; 04-02-2015, 08:32 PM.


          • #6
            So.. Will this make NS2 be able to run on a normal server?
            The Flying Fish: "i think i gave you a compliment actually"


            • #7
              This doesn't improve server performance at 30 ticks, so no.


              • #8
                Originally posted by Rocky View Post
                So.. Will this make NS2 be able to run on a normal server?
                Ns2 still needs needs single core clockspeed performance, I too have a 32core server but 2.4ghz per core. Ns2 doesn't like that. You'll be lucky if servers can increase performance, I mean I could see servers like iz3d running at 25ticks and 30-40 updates but currently ns2 doesn't allow that because tickrate locks sendrate vice versa. the client side varients will help but minimally for server strain.

                - - - Updated - - -

                Well actually it does if your server can handle 30ticks you might as well update default sendrate of 20 to 30 and change the interp, it wont make too much difference but a difference none the less. And ill host a server once my thermal paste comes on 31st october or earlier for my birthday


                • #9
                  Why you have to make me sad with facts?
                  The Flying Fish: "i think i gave you a compliment actually"