[Top Issue] Latest patch, jitter and lag
Plasma
Join Date: 2003-04-26 Member: 15855Members, Constellation, Squad Five Blue
Join Date: 2003-04-26 Member: 15855Members, Constellation, Squad Five Blue
<div class="IPBDescription">Just a point of view from me</div>Hi,
The latest patch adds some great features, I had a game for about 20 minutes earlier today and it was pretty fun trying out the new gear.
The <b>only</b> gripe I have, and its the same gripe I've had with every other patch, is <b>the jitter and lag</b>.
I know the team is working on it. I now only check out the big patches like this one, and as soon as I notice the jitter I get distracted and annoyed.
I can't stress enough how good it would be if more resources are put into identifying and solving this problem *completely*.
From the bottom of my heart with warmth and affection :) please focus more resources on solving this problem.
In all honesty, any other task you have I don't think is as important as this one - its presence means I won't bother trying to play a game later on because its still lagging, I know I won't 100% enjoy myself when it counts.
It's disrupting from the game play experience, its the one big thing people talk about on this forum as a negative to this game, it dampens all of the other hard work that has gone into the game (new gear, game play, bloom/lighting etc) which is really saddening.
If someone asked me if they should pre-order, I'd have to mention to them that its still lagging right now and they may want to wait.
Just my honest opinion, I still think the game is coming along very nicely and each new patch brings neat changes; its just this one issue that leaves a sour taste in my mouth that I don't think is receiving the attention it so desperately, crucially needs.
Thanks,
Andrew
The latest patch adds some great features, I had a game for about 20 minutes earlier today and it was pretty fun trying out the new gear.
The <b>only</b> gripe I have, and its the same gripe I've had with every other patch, is <b>the jitter and lag</b>.
I know the team is working on it. I now only check out the big patches like this one, and as soon as I notice the jitter I get distracted and annoyed.
I can't stress enough how good it would be if more resources are put into identifying and solving this problem *completely*.
From the bottom of my heart with warmth and affection :) please focus more resources on solving this problem.
In all honesty, any other task you have I don't think is as important as this one - its presence means I won't bother trying to play a game later on because its still lagging, I know I won't 100% enjoy myself when it counts.
It's disrupting from the game play experience, its the one big thing people talk about on this forum as a negative to this game, it dampens all of the other hard work that has gone into the game (new gear, game play, bloom/lighting etc) which is really saddening.
If someone asked me if they should pre-order, I'd have to mention to them that its still lagging right now and they may want to wait.
Just my honest opinion, I still think the game is coming along very nicely and each new patch brings neat changes; its just this one issue that leaves a sour taste in my mouth that I don't think is receiving the attention it so desperately, crucially needs.
Thanks,
Andrew
Comments
Smooth as...
Great work UWE, must be server related issue.
the server load increases exponentially with the player number. After 14-16 players it becomes just too much to handle. The task on the progress tracker "Optimize relevancy determination on the server" should fix this i think?
Server errors. There are errors, specially stuff falling out of the map, that create lua errors. Those errors can in some case happen very often (several times a second) and spamming the log/console of the server. This destroys the tickrate. From what i have seen in the other threads, its mainly about stuff falling out of the map.
From what i have seen, "small" servers (up to 14) behave very well and fast, as long as nothing falls out of the map or any other bad error happens. We are on the good way i think :)
the server load increases exponentially with the player number.<!--QuoteEnd--></div><!--QuoteEEnd-->
Evidence? Quadratic is the worst you'd expect with no optimization at all; exponential would be <i>horryfying</i>.
too much for the server to handle? for christ's sake.
in 2001 we had HL1 servers run decently on 1GHz single-core computers with 32 players with networking protocol based on QW and back then there was MUCH MORE to synchronize then nowadays (map entities, animations and rendermodes, visual effects made of entities, all of which by the way was a waste o bandwidth and has been optimized even since using client-side definitions), then in 2005 with Source Engine - again - even more synchronized data thanks to more detailed world and lots of interactivity + PHYSICS that aren't just eye-candy but influence the game (unlike NS2). 2005 - BF2 - 64 players. You could run 32 server on your home computer and experience fluent gameplay, with infitely more networked content.
Today games are much simplier networking-wise then it was a few years ago. A lot of stuff has been limited or removed so they resemble more of a Q3 engine.
Now to NS2 - close to none interactive elements requiring constant updates, closed spaces only (PVS simplifiying the process even further), no game mods (gameplay mods, not engine mods) = fully deterministic client-side prediction for content, handled via scripts.
I will never forget when I enabled net debugging in NS2 and saw 300+ vectors being synchronized constantly while looking at a single guy using armory - what. the. hell.
Structures? Dynamic infestation? I could handle all that within 500b/s tops.
32 players? what's the problem? 30 cmd updates per second per player, 20-30b each, what is there to process?
And keep in mind that since 2005 network speed and stability improved significantly so the task is even simplier.
a hint: mutlithreading with networking = dead end. Best example? Crysis. (but Im not certain if it's being used in NS2 like that)
Come on, UWE!
Honestly? They would be better off using Q3 engine and building the game on top of that (keep the core, replace whole rendering, movement and physics code)
</rant on 2-year beta, and yes, it still runs like crap on my new machine>
:(
Careful now, soon people will come out of the woodworks and start slamming your PC for not being being properly configured or whatever other ###### they're using to rationalize the _TERRIBLE_ performance.
In other news, yes as we've discussed in detail in the "Fully optimized - what does it mean?"-thread many of the issues stem from the Lua-script, which isn't something that will go away overnight I fear, unless something drastic will be done about it (*cough* LuaJIT, move performance-intensive parts to the engine via FFI and rewrite the ###### parts of the script *cough*). This isn't a case of 'optimize after feature-completion', as these are big design decisions that have to be taken as early on as possible, not rewriting your ###### for-loop to be more efficient (which you can do later on).
Still fun to play as gorge and lerk.
Strictly speaking, I imagine it runs better for me than it does for you. Terms like smooth\well\okay kinda lose their meaning being as subjective as they are, and clearly I define them radically different. Perhaps we can settle with everyone's favourite qualification: playable.
The problem is that the server engine asks every lua entity if it is relevant to each player, every time it is building an update to send to a player. So the actual cost is numberOfPlayer x numberOfEntities x updatesPerSecond in game. A rough estimate is that it costs 1 ms per player per 200 entities in the game per update. With an average mid-game count of 400 entities and 16 players, each update costs the server 32ms, and its supposed to do that 20 times per second - it would take 600ms, or 60% of the cpu to try to do that (it actually does it less often, meaning that everyone feels it as more lag instead).
The good news is that its pretty much all unneeded work, so once Max is done rewriting that part, the server will run about twice as fast in larger games.
</rant on 2-year beta, and yes, it still runs like crap on my new machine>
:(<!--QuoteEnd--></div><!--QuoteEEnd-->
Max doesn't like the Q3 code. I think he doesn't like the disadvantage forced on high ping players. Have tried to find the post to prove this but I'm struggling to use this forum's search engine.
FWIW, speaking competitively, I think the Q3- opensource!- netcode is immense: if a shot didn't register it's because I missed the player. I can't say this for other netcodes. I think NS2's current netcode is an in-house one, but don't think it's ready yet (which is fine as the game is still a beta!).
Anyway back to the waiting game. Seeyas in 6 months when I try again :P
That's quadratic, assuming the number of entities grows roughly in proportion to the number of players. If it grows slightly slower or slightly faster it is slightly better or slightly worse than quadratic, but it is certainly nowhere near exponential. The point was; <i>don't say exponential if you don't really mean it</i>.
O(n^2) is not great, but O(2^n) is <i>horrifying</i>. Compare n^2 and 2^n for a number of n:
n | n^2 | 2^n
2 | 4 | 4
3 | 9 | 8
4 | 16 | 16
5 | 25 | 32
6 | 36 | 64
7 | 49 | 128
8 | 64 | 256
9 | 81 | 512
10 | 100 | 1024
11 | 121 | 2048
12 | 144 | 4096
13 | 169 | 8192
14 | 196 | 16384
15 | 225 | 32758
16 | 256 | 65536
17 | 289 | 131072
18 | 324 | 262144
19 | 361 | 524288
20 | 400 | 1048576
21 | 441 | 2097152
22 | 484 | 4194304
23 | 529 | 8388608
24 | 576 | 16777216
25 | 625 | 33554432
26 | 676 | 67108864
27 | 729 | 134217728
28 | 784 | 268435456
29 | 841 | 536870912
30 | 900 | 107374182
31 | 961 | 214748365
32 | 1024 | 429496730
However there is still the jitter that happens every now and then, and while improved I think over previous patches, it still happens from time to time which is enough to distract me from the experience I'm supposed to be immersed in.
The other similar nitpick bugs like drifters not building (apparently a known issue?) was also pretty frustrating.
FWIW, speaking competitively, I think the Q3- opensource!- netcode is immense: if a shot didn't register it's because I missed the player. I can't say this for other netcodes. I think NS2's current netcode is an in-house one, but don't think it's ready yet (which is fine as the game is still a beta!).<!--QuoteEnd--></div><!--QuoteEEnd-->
Nonono.
As far as I know, NS2 does it pretty much the same way as NS1 (or HL1/HL2) <a href="http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking" target="_blank">does it</a>. The client tells the server it has hit something in specific timeframe, the server calculates the same, and check if the client is telling the truth. This means, a person who hits something on <i>his</i> screen will generally register the hit. Because of the delay, people will get 'cornered'. The source wiki article explains this perfectly, read the sections entity interpolation, input prediction and lag compensation.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Command Execution Time = Current Server Time - Packet Round-Trip-Time - Client View Interpolation<!--c2--></div><!--ec2-->
In Q3, again afaik, because the server doesn't care about the delay between you and the server, you'll have to lead targets depending on your latency. Imagine playing NS, that you would have hit with the shotgun in front of a skulk on server A but not on B, or maybe it could change during the game, better watch your scoreboard! This may not be such a problem if the latencies are small enough, but not sure where is the cut-off point. The price of the HL-style lag compensation is a bit of added latency.
In fighter games, the competitive players need <i>much</i> faster response time than FPS-games, something like ping 30+ ms becomes unplayable, because they have many splitframe abilities and the response has to be timed exactly according to the enemy. Its like playing MIDI keyboard without <a href="http://en.wikipedia.org/wiki/Audio_Stream_Input/Output" target="_blank">ASIO</a>, 30ms just means you are going to play it out of rhythm. Some of the fighter games use lag compensation and some do not (they had weird nickanames for these), but I heard the lag compensation method is better.
I still do agree with the general idea that the jitter/lag much needs to be much less for the final product, and I'd like to have stable 100FPS server. I have no problem giving UWE all the time it needs to get the performance up though. Also I'm not sure if all of the problems are related to server performance, atleast model collision jitter might have something to do with physics calculation. And nice catch Matso.
Like he said. And my comp is like 4 years old..
First one was bugged, half the players were phantoms, sitting in idle poses floating off the ground and hogging comm mode.
Second one ran great, around 100-120 ping
Third one was jittery as hell, hard to move around and play. Ping was only in the 90's, which surprised me.
...I need to start writing down the names of the good ones >.<
I wonder if certain player actions are spamming the server with updates, like when you're a gorge and can't place a hydra early on, it seems as if it's repeatedly trying and the net stats show an increase in data being sent and received, similar stuff happened with the marines fixing power points, hundreds of sparks would fly and slow the game down, seemed like it was spamming the action really fast, so something to look at maybe?
1) Server performance (low tickrate) gives a poor experience to players
2) Client jitter (eg when shooting at a skulk) - I can pretty much without fail lockup/pause my screen for like 0.5-3 seconds at 0fps when fighting on occasion.