Performance question
Alpha.
Join Date: 2011-01-04 Member: 76186Members
Join Date: 2011-01-04 Member: 76186Members
I'm wondering how server makes packets that it then sends to clients? Meaning: 1. For buildings - if building is dropped, server sends updates to clients about that building. But the question is how it chooses what data to send? 2. For players - basically same question. I move, server receives my current location, and then sends it to nearby players, but how it chooses to who send it?
With every new player connected CPU usage increases, reaches 100% at some point - server practically dies then [tick rate drops to 3 etc.]. Obvious solution is to lower number of operations that server have to do for each player. Thats why I'm asking: what operations it actually makes?
I know i saw some of information I'm asking for somewhere, just can't find the topic.
With every new player connected CPU usage increases, reaches 100% at some point - server practically dies then [tick rate drops to 3 etc.]. Obvious solution is to lower number of operations that server have to do for each player. Thats why I'm asking: what operations it actually makes?
I know i saw some of information I'm asking for somewhere, just can't find the topic.
Comments
What I've inferred from both playing the game, and tinkering with it's script, is that it works the same way most multiplayer-games do, on a need-to-know basis. It will only send data to the client that is specifically relevant to them, and nothing more. This method saves both in bandwidth (least amount of data to send) and helps against cheating (can't wall-hack if your client isn't told there is someone behind the wall). You can see this in action on laggy servers (with that I mean low-tickrate servers) in particular. Go comm on marine\alien and select a random location on the mini-map (somewhere far from your current view). Often you'll see a blank room and moments later (half a second or longer) it'll be filled with 'things' (RTs, DI or whichever). Judging from the net_stats readout, the bandwidth usage for clients is pretty low: 3-5 KB/s up, 10-20KB/s down. This is on par with many other multiplayer games (CS:S \ TF2 etc).
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->With every new player connected CPU usage increases, reaches 100% at some point - server practically dies then [tick rate drops to 3 etc.]. Obvious solution is to lower number of operations that server have to do for each player. Thats why I'm asking: what operations it actually makes?<!--QuoteEnd--></div><!--QuoteEEnd-->
The terrible server-performance at the moment I believe can be mostly attributed to Lua. While it's a pretty fast interpreted-language, UWE is asking a lot by writing all of the gameplay\interface-code in Lua. The only solution here will be a better way of Lua-scripting (certain syntax-usage and style-preference changes can mean massive speed-ups), a more optimized virtual-machine and possibly moving the dirty work into the engine.
Yes. Thats what I'm thinking about. But exactly how? I think [definitely not sure] I red somewhere on this forums that server calculates, hm, visibility area (?) for each player, realtime, and then sends updates about that area. If this is true - isn't it [calculations] very CPU-intensive? I believe it's a possible explanation [at least partial] for cpu usage increase with players number?
If it's true about that amount of cpu operations - isn't there a way for optimization? Even I can think about one, like dividing a map to parts, creating a 'databases' of all current positions/health in each part [updated realtime], and then sending entire [partial] database to client depending on his coords? Less optimal from bandwidth usage view, but less CPU-intensive? [calculations count [almost] not depends on players number]
I'm sorry if it's stupid idea, just trying to help best I can.
As far as your suggestion is concerned, I'm unsure how the occlusion-culling has been implemented in Spark (it may be using sectors isolated by portals, or it may not). These algorithms, however, are located in the engine, so it's already running pretty fast (although it can be made faster if map-leaks are tackled more efficiently, sometimes entire sections of the map are rendered unnessarily because of a miniscule leak). It should also be noted that clients ideally shouldn't be trusted at all by the server, and thus should not recieve more data than is absolutely vital. This usually isn't that much of an issue with multiplayer-games, but with NS2 being very open by the ways of Lua (especially right now, while there is no consistency-checking at all) it is advisible not to send too much information to clients.
It can be easily managed, even using existing code used to calculate visibility:
<img src="http://img830.imageshack.us/img830/2335/2011030100001.jpg" border="0" class="linked-image" />
Map divided to small areas, each with a number and parameters - numbers of other areas visible from this point. So i.e. if player is in coordinates matching area 8 - he receives updates about areas 8, 10, 9, 11 and 13. This way you can exactly control what data client receives when in certain spot of the map and you have to calculate visibility <b>only once per map</b> - it can be probably done using existing code. Of course its only a sketch of an example, I'm sure someone can make it better.
Important thing is, that server just reads your coords, reaches its ram and sends an update, w/o unnecessary calculations.
Thoughts?
oh, well then, <!--coloro:red--><span style="color:red"><!--/coloro-->this would completely explain<!--colorc--></span><!--/colorc--> the behavior I've commented on about <a href="http://getsatisfaction.com/unknownworlds/topics/159_mouse_jerkiness_stutter_after_fade_blink" target="_blank">160 Mouse jerkiness/stutter after fade blink (video) </a>
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec--><!--coloro:lime--><span style="color:lime"><!--/coloro-->This is actually a problem that is independent of blink.<!--colorc--></span><!--/colorc--> (Well, 3 problems actually) Mouse stutter is a constant problem that is only MAGNIFIED by the many occlusion calculations (and server updates?) that are all performed nearly at once(additional with turning view orientation) when blinking to a new location.
This occurs to a lesser extent while moving around normally or by rotating view orientation. It(#1: occlusion culling performance) is one of the most significant performance issues with the game at this time.
Unfortunately, it appears that this stutter/hitch is also tied to SERVER performance, so this link is an additional independent bug(#2: view orientation dependent on the server). Player view orientation should never depend on server performance whatsoever.
Of course, there is also server performance itself. (#3)
So, in my evaluation, this fade blink stutter is actually three issues in one, none of which is actually related directly to fade blink.
They are all still present in build 165.<!--QuoteEnd--></div><!--QuoteEEnd-->
Note that this is all based on "feel", but I think it's accurate. If they could solve these problems it would help sooo much.
<img src="http://img830.imageshack.us/img830/2335/2011030100001.jpg" border="0" class="linked-image" />
Map divided to small areas, each with a number and parameters - numbers of other areas visible from this point. So i.e. if player is in coordinates matching area 8 - he receives updates about areas 8, 10, 9, 11 and 13. This way you can exactly control what data client receives when in certain spot of the map and you have to calculate visibility <b>only once per map</b> - it can be probably done using existing code. Of course its only a sketch of an example, I'm sure someone can make it better.
Important thing is, that server just reads your coords, reaches its ram and sends an update, w/o unnecessary calculations.
Thoughts?<!--QuoteEnd--></div><!--QuoteEEnd-->
You have just described a form of binary space partitioning.
<!--QuoteBegin-'juice'+--><div class='quotetop'>QUOTE ('juice')</div><div class='quotemain'><!--QuoteEBegin-->oh, well then, this would completely explain the behavior I've commented on about 160 Mouse jerkiness/stutter after fade blink (video)<!--QuoteEnd--></div><!--QuoteEEnd-->
The so-called client-side 'stuttering' is believed to be (largely) caused by the Lua garbage-collector, and is being worked on as we speak. As for the initial 'freezing' that occurs when you move out of blink, I'm experiencing it too and I'm not sure why that is present (as the engine isn't constricting player-angles server-side anymore as it did earlier builds).