build 224 perf increase speculation
shader
Join Date: 2003-02-07 Member: 13247Members
Join Date: 2003-02-07 Member: 13247Members
<div class="IPBDescription">capped input sampling rate</div>During the Logitech cup livestream, Flayra mentioned that a coming optimization in build 224 would help out with the framerate hit that happens when you have a high ping.
NS2 client framerate for people with high ping is slower than it could be because the game uses a variable input sampling rate. Lots of games (eg Source engine), use a fixed input sampling rate - they check the mouse and keyboard 30 times a second (for example). This data gets packaged into a usercommand and is used on the server for player movement, and on the client for prediction. Client prediction is where the client takes the last update of your position it got from the server, and adds on all the movement commands you've sent since then to calculate ('predict') your up-to-date position. If you have a high ping, this will be more work, as the last update from the server could be 200ms old, so it has to recalculate 200ms worth of move commands every single frame to update your predicted position. If your ping is low, there are less movement commands to execute to predict your current position (maybe 50ms worth).
Instead of using a fixed input rate, like Source, NS2 samples input once per client frame, and then runs prediction on the client, and movement on the server, using the client timestep. So 10fps clients have their input sampled 10 times per second, while 100fps clients have their input sampled 100 times per second. This means high framerate clients require the server and the client to do more work, as there are more usercommands to process, each applying to a smaller timestep than for a low fps client. A 100fps client would create 10 times more work for the server movement and client prediction code than a 10fps client would.
This means an optimization in one part of the game that improves client framerate ends up causing increased work in the client prediction and server movement parts of the game because it is increasing the number of usercommands each player generates, so performance increases slower than it could.
One possible solution to this is just to cap the client input rate - i.e. sample input at the client frame rate, until that hits 30fps, then just skip some frames to keep the rate under 30fps. This means that once client framerate hits 30fps, further framerate increases don't create extra work for the client prediciton and server movement code. Sampling input 30 times a second is easily enough for smooth movement (it's good enough for Source).
I think possibly this is what UWE have done for 224.
[edit: grammar]
NS2 client framerate for people with high ping is slower than it could be because the game uses a variable input sampling rate. Lots of games (eg Source engine), use a fixed input sampling rate - they check the mouse and keyboard 30 times a second (for example). This data gets packaged into a usercommand and is used on the server for player movement, and on the client for prediction. Client prediction is where the client takes the last update of your position it got from the server, and adds on all the movement commands you've sent since then to calculate ('predict') your up-to-date position. If you have a high ping, this will be more work, as the last update from the server could be 200ms old, so it has to recalculate 200ms worth of move commands every single frame to update your predicted position. If your ping is low, there are less movement commands to execute to predict your current position (maybe 50ms worth).
Instead of using a fixed input rate, like Source, NS2 samples input once per client frame, and then runs prediction on the client, and movement on the server, using the client timestep. So 10fps clients have their input sampled 10 times per second, while 100fps clients have their input sampled 100 times per second. This means high framerate clients require the server and the client to do more work, as there are more usercommands to process, each applying to a smaller timestep than for a low fps client. A 100fps client would create 10 times more work for the server movement and client prediction code than a 10fps client would.
This means an optimization in one part of the game that improves client framerate ends up causing increased work in the client prediction and server movement parts of the game because it is increasing the number of usercommands each player generates, so performance increases slower than it could.
One possible solution to this is just to cap the client input rate - i.e. sample input at the client frame rate, until that hits 30fps, then just skip some frames to keep the rate under 30fps. This means that once client framerate hits 30fps, further framerate increases don't create extra work for the client prediciton and server movement code. Sampling input 30 times a second is easily enough for smooth movement (it's good enough for Source).
I think possibly this is what UWE have done for 224.
[edit: grammar]
Comments
If this is all true and how the game works, thank you :)
1: IMO 30 fps is not enough. I think it is the bare minimum. Notice that there aren't any really fast paced shooters on the source engine.
2: You might be able to sample the local user input much more quickly, but integrate multiple client frames into a single server update. This way you don't decrease the sample time of user input and client update for clients who have the power to handle it, but you can reduce load on the server.
3: If something like this is implemented, it should be a server option so higher end servers, and servers with lower player counts can allow for higher client update rates.
Pretty sure Gldsrc games were the same.
If the difference was noticeable you'd have people who get NS2 running at 60fps talking about how much more responsive NS2 movement is compared to a Source game. Does this happen?
1: IMO 30 fps is not enough. I think it is the bare minimum. Notice that there aren't any really fast paced shooters on the source engine.
2: You might be able to sample the local user input much more quickly, but integrate multiple client frames into a single server update. This way you don't decrease the sample time of user input and client update for clients who have the power to handle it, but you can reduce load on the server.
3: If something like this is implemented, it should be a server option so higher end servers, and servers with lower player counts can allow for higher client update rates.<!--QuoteEnd--></div><!--QuoteEEnd-->
1. Don't think of it as 30 FPS. Servers don't have FPS, they have tick rates. I'm pretty sure most if not all servers run at around 30 ticks a second. More than that is pointless. Its like running Angry Birds at 60 fps.
2. The integration process will hit the client's processing time, which is what this whole thing is trying to avoid. The notion of increasing certain client's pseudo update rates because they have better machines is laughable. It sounds a lot like rate hacking of the old days. We are trying to level the playing field here, not further imbalance it.
3. I guess its feasible, though someone unlucky enough to join such a server while not having a powerhouse machine capable of perfectly smooth high performance would be choke'd and loss'd into oblivion.
If this performance change is coming, then I am pretty annoyed by the fact that it is coming less than a week before I will probably be able to play on local servers reliably for the first time, after playing with 300 ping and 15 fps for the past 2 years. Oh well, an improvement is an improvement.
way to argue meaningless semantics, should we just use the term 'hertz' instead, that would be the most accurate.
<!--quoteo(post=1995393:date=Oct 22 2012, 11:11 PM:name=Imbalanxd)--><div class='quotetop'>QUOTE (Imbalanxd @ Oct 22 2012, 11:11 PM) <a href="index.php?act=findpost&pid=1995393"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->2. The integration process will hit the client's processing time, which is what this whole thing is trying to avoid. The notion of increasing certain client's pseudo update rates because they have better machines is laughable. It sounds a lot like rate hacking of the old days. We are trying to level the playing field here, not further imbalance it.
3. I guess its feasible, though someone unlucky enough to join such a server while not having a powerhouse machine capable of perfectly smooth high performance would be choke'd and loss'd into oblivion.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think you should reread my post, and the OP, becuase what you just typed doesn't seem logically connected to the topic.
PS: Gold Source servers could configure their tick rate, and many servers ran at 100+ fps. Same with Quake 3 to the best of my knowledge.
Ok, you may regard it as semantics, but please, don't use the phrase "servers ran at x FPS". It makes anyone who knows what they are talking about cringe.
Also try not to get upset that someone doesn't agree with you, its very petty.
As for you being hellbent on punishing people who can't provide update data to a server at least 60 times a second, I'm guessing you have a pretty beast machine and a mother of an internet connection? Just asking.
Someone who can only receive updates 20 times a second will only see updates 20 times a second, and someone who can only send 20 updates a second will only be accurately updated 20 times a second. Yes, we cannot hamstring everyone else to help people with plain bad machines, but we can lay back on punishing them for absolutely no reason. If you played on two goldsouce servers, one running at 30 ticks, the other at 60, you would not be able to reliably tell the difference in typical play. You remind me of those CS players that use CRTs because they update faster, as if the human eye could ever tell the difference.
that's an input update in a rate of 33,33 ms
i think it's pretty good
at least worked well for ns1, even that I think n1 is faster than ns2, so I think it's good enought for ns2
It is semantic quibbling, Imbalanxd doesn't know ######. There were GoldSrc servers that ran at 1000 fps. Timestep for internal server physics didn't have to match up with network updates sent to the client. Valve limited Source servers to 66 fps not too long ago, to the chagrin of many, and I'm pretty sure people made server mods to bypass that.
I have a 120hz monitor. Compared to a 60hz one, the difference is definitely noticeable, even just on the desktop.
<!--coloro:orange--><span style="color:orange"><!--/coloro-->*I am not learning to be nice. Last warning before a permanent ban*<!--colorc--></span><!--/colorc--> --Comprox
I am guessing they are related, but it sounds like FPS and client tick has now been separated.
So if it is updating at 30 ticks a second, it draws movement as such: -----|-----|-----|-----|-----| (What you don't see)
In parallel with that, fps is drawing the animations at 100fps like this: -|-|-|-|-|-|-|-|-|-|-|-|-|-|-| (What you do see)
So your computer basically smooths out the transitions between the ticks, and draws the movement at 100fps accordingly.
So I am guessing that as long as you have client prediction collecting info on what you 'did' hit and sending it to the server, as long as the tick rate is in a reasonable area of 30+ ticks then you will not see much of a difference?
If this is true^ then we should see considerable performance increase, as well as reducing hitching? Maybe completely?
I bet you move dem desktop icons around MLG stylez yo.
You know it dog!
But seriously, I notice so much more with my 120hz montior
Expects: Skulk nerf, fade nerf, gorge trivial change. Shotgun buff
As far as rumours go, not only skulk but also fade and Lerk are getting the glancing blow stuff (3 cones, 100% damage(same size as b223), 66% dmg(bigger), 33%dmg(biggest, kept it vague since im not 100% sure about sizes))
That's already one thing that I'd call a buff, maybe even a bit over the top.
We will find out tomorrow, I guess.
It's ironic. As strides were made in client performance, it created a negative feedback loop. The servers started to bog down under the weight of increased client framerates. Funny in a dark way if you ask me!
Anyway, Build 224 is a monstor. Personally I'm so incredibly proud of Max and Dushan. They don't take the easy way out, ever. They do what is best for the game and the players. This is certainly not your average 'one week before release' operation. But this is not your standard development, and this is not a standard game.
I am guessing they are related, but it sounds like FPS and client tick has now been separated.
So if it is updating at 30 ticks a second, it draws movement as such: -----|-----|-----|-----|-----| (What you don't see)
In parallel with that, fps is drawing the animations at 100fps like this: -|-|-|-|-|-|-|-|-|-|-|-|-|-|-| (What you do see)
So your computer basically smooths out the transitions between the ticks, and draws the movement at 100fps accordingly.
So I am guessing that as long as you have client prediction collecting info on what you 'did' hit and sending it to the server, as long as the tick rate is in a reasonable area of 30+ ticks then you will not see much of a difference?
If this is true^ then we should see considerable performance increase, as well as reducing hitching? Maybe completely?<!--QuoteEnd--></div><!--QuoteEEnd-->
You are sort of right but are confusing a few parts of the process. I can't think of way to explain which parts without a long post as this is a complex subject.
But yes, basically currently the input sampling rate and the client framerate are linked, and it appears 224 is separating them. This is a good idea because sampling input more than 30 times a second doesn't create any noticeable increase in responsiveness, but because of the way the Spark engine works, it creates a big increase in workload for both the server and the client. UWE have been in the weird position of having performance improvements in some areas of the game causing slowdowns in another area.
This new change will mean that any increases in client framerate over 30fps are 'free' - they shouldn't cause slowdowns in other parts of the game. If most players are currently averaging 45fps, this would increase server performance during the player movement phase by about 50%. Ditto for the client prediction phase on each players machine, so improved performance at both ends.
Note 30 times a second is a guess on my part, but sounds like a good value to cap it at as it is what some other engines use.
It shouldn't have any impact on hitching that I can see. The game used to sometimes freeze up when loading textures and models, which is an unrelated issue.
Source lets you set the server tick rate, the input sampling rate (cmdrate), and the update rate (from server to client) separately. Which one are you talking about that you can tell the difference on?
This change is basically equivalent to the Source/Gldsrc cmdrate setting.
<!--quoteo(post=1995712:date=Oct 23 2012, 02:33 PM:name=Underwhelmed)--><div class='quotetop'>QUOTE (Underwhelmed @ Oct 23 2012, 02:33 PM) <a href="index.php?act=findpost&pid=1995712"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->30 updates a second is far from enough, from both client to server and server to client. GoldSrc default cmdrate was 30 and there was definitely an improvement in increasing that.
It is semantic quibbling, Imbalanxd doesn't know ######. There were GoldSrc servers that ran at 1000 fps. Timestep for internal server physics didn't have to match up with network updates sent to the client. Valve limited Source servers to 66 fps not too long ago, to the chagrin of many, and I'm pretty sure people made server mods to bypass that.
I have a 120hz monitor. Compared to a 60hz one, the difference is definitely noticeable, even just on the desktop.<!--QuoteEnd--></div><!--QuoteEEnd-->
In Source and Goldsrc games, I'm sure pro players could probably notice the cmdrate and updaterate improvements on a LAN. I'd want to see double-blind tests before I believe the difference was noticeable on your average internet game. Anyway, there is no reason why NS2 couldn't allow you to bump up the rates either way for specific high performance situations like LAN games. This new change should make input rate a tuneable parameter like Source/Gldsrc, instead of being locked to client framerate.
Besides, it's better for NS2 to reach parity with stock Goldsrc/Source games first before trying to exceed them.
Regarding your 120Hz monitor comment, that's irrelevant, as in most games (and now in NS2), the input sampling rate has nothing to do with the client rendering framerate. People are much more sensitive to the rendering framerate, which is why most games sample input at a much lower rate than they draw the world.
(I currently run about 50-70fps depending how much is going on ingame)
He said that 224 is planned for tomorrow.
I could tell the difference between a 33 tickrate server and a 66 tickrate server. In source your cmdrate and updaterate are capped at the tickrate. So I'm talking about everyone playing on the server with the maximum settings. Tickrate, cmdrate and updaterate all = 33 or 66.
But yes, basically currently the input sampling rate and the client framerate are linked, and it appears 224 is separating them. This is a good idea because sampling input more than 30 times a second doesn't create any noticeable increase in responsiveness, but because of the way the Spark engine works, it creates a big increase in workload for both the server and the client. UWE have been in the weird position of having performance improvements in some areas of the game causing slowdowns in another area.
This new change will mean that any increases in client framerate over 30fps are 'free' - they shouldn't cause slowdowns in other parts of the game. If most players are currently averaging 45fps, this would increase server performance during the player movement phase by about 50%. Ditto for the client prediction phase on each players machine, so improved performance at both ends.
Note 30 times a second is a guess on my part, but sounds like a good value to cap it at as it is what some other engines use.
It shouldn't have any impact on hitching that I can see. The game used to sometimes freeze up when loading textures and models, which is an unrelated issue.<!--QuoteEnd--></div><!--QuoteEEnd-->
Thanks for explaining, it sounds like this will actually give some huge benefits in quite s few areas then?
Looking forward to seeing Dushan and Max's fine work!
It is semantic quibbling, Imbalanxd doesn't know ######. There were GoldSrc servers that ran at 1000 fps. Timestep for internal server physics didn't have to match up with network updates sent to the client. Valve limited Source servers to 66 fps not too long ago, to the chagrin of many, and I'm pretty sure people made server mods to bypass that.
I have a 120hz monitor. Compared to a 60hz one, the difference is definitely noticeable, even just on the desktop.
<!--coloro:orange--><span style="color:orange"><!--/coloro-->*I am not learning to be nice. Last warning before a permanent ban*<!--colorc--></span><!--/colorc--> --Comprox<!--QuoteEnd--></div><!--QuoteEEnd-->
For everyone's information his guy just got banned for rightfully dismissing passive aggressive misinformation. This isn't an uncommon event either.
It's ironic. As strides were made in client performance, it created a negative feedback loop. The servers started to bog down under the weight of increased client framerates. Funny in a dark way if you ask me!
Anyway, Build 224 is a monstor. Personally I'm so incredibly proud of Max and Dushan. They don't take the easy way out, ever. They do what is best for the game and the players. This is certainly not your average 'one week before release' operation. But this is not your standard development, and this is not a standard game.<!--QuoteEnd--></div><!--QuoteEEnd-->
Damn it I read that post in your voice
Wow really... that seems very harsh considering what he wrote. I've seen much worse
Anyway, these are very complex changes to be making a week before release and shows how dedicated UWE are to giving us the best user experience possible, exciting times!