Why does ping affect fps?
Skie
Skulk Progenitor Join Date: 2003-10-18 Member: 21766Members, NS2 Playtester, Reinforced - Shadow
Skulk Progenitor Join Date: 2003-10-18 Member: 21766Members, NS2 Playtester, Reinforced - Shadow
I join an empty US server with a ping of about 180. I stand alone in the summit marine start and get an fps of about 75.
If I create my own server and stand alone in summit marine start, with 0 ping, I get 95 fps.
I think this needs to be addressed. Lag makes the game really terrible. Playing on US servers as an European (or anywhere where the ping is high) is just terrible.
While on a low ping server which is running smoothly, the fps is pretty decent though.
If I create my own server and stand alone in summit marine start, with 0 ping, I get 95 fps.
I think this needs to be addressed. Lag makes the game really terrible. Playing on US servers as an European (or anywhere where the ping is high) is just terrible.
While on a low ping server which is running smoothly, the fps is pretty decent though.
Comments
I guess that makes sense if there's a lot of moving parts. But what is the client predicting if I'm just standing still and there's no one else on the server?
PS.
Prediction it is. It's interesting how ClientGame::PredictMovement is anything from 6000 to 9000 µs total on a high ping server.
On a low ping server (not even on your own, but let's say ping of 60) it ranges from 3500 to 6000 µs.
Under ClientGame::PredictMovement, Player:OnProcessMove, Entity::OnUpdatePhysics and World::InterpolateEntities all pretty much double in the time it takes to calculate them on a high ping server vs. low ping server. The ping is approximately double as well. Quite fascinating.
Still don't understand what is it calculating when nothing is moving, though.
I was wondering why my screen always stutter so i activate r_stats...to my surprise my ping and my fps was fine.
FPS was about 40 (ok at some places 20 but that wasn't in that situation) and my ping 20-50 but its stutter!
To bad i don't record it, but its very weird.
I hope they fix that.
As you seem to know how to use the profiler, perhaps you find some things that could be optimized? I also think that there shouldn't be much to predict on an empty server.
I might know how to use the profiler but the lua is definitely not my forte. One would have to delve deeper to find what's actually causing the extra calculation time. The three functions/entities that slow down the most I mentioned a couple of posts ago.
The client loop:
- time = read clock
- read input from you
- send input to server
- add input to the input queue
- check if the server has send a new state snapshot
* if a new state snapshot has been received, update the base world state and time and remove inputs that the server indicates have been
used.
- Predict the world, using the base state and time, incorprating ALL of the input from you AT the correct times.
- render the world to the screen
The work you need to do in the Prediction step is dependent on how long your input queue is. The length of your input queue is increased by one each loop - ie, each client FPS - and shortened when the server sends you a new snapshot.
A fully functioning server sends you a new snapshot 20 times per second. The server adds a 100ms buffer to your input, and then lag is added on top of that. Assuming 100ms ping, the snapshots from the server will be about 200ms out of date, and you will get them at 50ms intervals, so that means that you will have rougly 200-250ms worth of input queue to predict each frame.
At 50 fps and the above input queue, you are looking at predicting about 10 (immediately after the snapshot)/11/12, (new snapsthot) 10/11/12 etc frames.
Now, imagine if the server gets bogged down to 5 ticks per second... then the snapshots will be coming in every 200ms instead. That means you are looking at a 200-400ms input queue instead ... and that would be 10/11/12/13/14/15/16/17/18/19/20, (new snapshot) 10/11 ... etc prediction steps.
The worst thing here is that the framerate starts to wobble - the number of prediction steps goes from 10 to 20, and that affects the framerate in itself, so you don't get a low, smooth framerate, but a framerate that wobbles back and forth several times a second.
So your fps is related to the length of your input queue, which in turn depends on latency, server update rate AND your client FPS (yea, feedback loop - fortunately, its a negative feedback loop, so the fps don't crash).
I'm a bit lost, what it input queue again ? It's like mouse and keyboard inputs ? The client go through this in real time no? it's not like it waits for the server to confirm that you moved your mouse to update the camera position.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->The server adds a 100ms buffer to your input<!--QuoteEnd--></div><!--QuoteEEnd-->
What does that mean exactly ? For example if I click at 10 second, does the server consider what I clicked at 10.1 seconds ?
Of course not. But the server has to send the new data about other players and stuff to you.
I think, in the input queue is all the data you want to send to the server. But I'm not sure about this.
<!--quoteo(post=1906302:date=Feb 23 2012, 05:33 PM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Feb 23 2012, 05:33 PM) <a href="index.php?act=findpost&pid=1906302"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What does that mean exactly ? For example if I click at 10 second, does the server consider what I clicked at 10.1 seconds ?<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't understand this either. Is it really a buffer or did it meant to be the calculation time the server is bussy with.
As to why the server sends snapshots 20 times per second rather than 30 ... well, probably cuts amount of bandwidth used by 30% or so. Bandwidth usage has been a real problem up until a few patches ago, but there was some serious compression just before gorilla.