<!--quoteo(post=1969602:date=Sep 1 2012, 08:16 AM:name=matso)--><div class='quotetop'>QUOTE (matso @ Sep 1 2012, 08:16 AM) <a href="index.php?act=findpost&pid=1969602"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The main problem, performance wise, is that the server has to run the input handling for every Move generated by the clients. As clients generate one Move per display frame, 20 players at 60 fps generates 1200 Moves per second, so the server has a bit of a load problem - it has to handle on one computer what is being generated by 20 computers.<!--QuoteEnd--></div><!--QuoteEEnd-->
Didn't NS1 (and most other multiplayer games) do this without an issue?
<!--quoteo(post=1969866:date=Sep 1 2012, 07:11 PM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Sep 1 2012, 07:11 PM) <a href="index.php?act=findpost&pid=1969866"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Didn't NS1 (and most other multiplayer games) do this without an issue?<!--QuoteEnd--></div><!--QuoteEEnd-->
I imagine Lua scripting is to blame for slowdown when dealing with alot of clients.
<!--quoteo(post=1969820:date=Sep 1 2012, 10:07 PM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Sep 1 2012, 10:07 PM) <a href="index.php?act=findpost&pid=1969820"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You're totally wrong.<!--QuoteEnd--></div><!--QuoteEEnd--> Ok, at first I thought "yeah, this guy may just want NS2 to be successful and is a bit harsh because of that". But you are completely disrespecting the developer matso who is friendly enough to answer multiple questions with long posts. What the hell are you doing here? When you aren't forced to pay for the game, then what do you want? When you want the game to be successful, why do you disrespect the developers of the game you like? How long are you gonna squirt without helping at all? Matso gives us information about the problems and possibilities in the engine...and you violate him.
<!--quoteo(post=1969641:date=Sep 1 2012, 08:27 PM:name=falc)--><div class='quotetop'>QUOTE (falc @ Sep 1 2012, 08:27 PM) <a href="index.php?act=findpost&pid=1969641"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You don't have to use a copy of the player object, if you do synchronization correctly you can work directly with the player objects.<!--QuoteEnd--></div><!--QuoteEEnd-->
You could, but then the input threads would be blocked whenever the game thread was using the player objects (which would be most of the time). Or you would incur the costs of multiple lock and unlock operations if the game thread tried locking the players whenever it needed to access them (which would be often).
Plus you usually only want player moves applied to player objects once per server frame.
Using copies with a single brief sync step satisfies the 'once per frame' constraint and keeps the input threads and the game thread running in parallel as much as possible.
<!--quoteo(post=1969866:date=Sep 2 2012, 10:11 AM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Sep 2 2012, 10:11 AM) <a href="index.php?act=findpost&pid=1969866"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Didn't NS1 (and most other multiplayer games) do this without an issue?<!--QuoteEnd--></div><!--QuoteEEnd-->
Source and, I think, Goldsrc games use a <a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking" target="_blank">fixed input sampling rate</a>. So the problem of servers having to do more work for high framerate clients doesn't happen for them.
But they do handle input from multiple players every frame (obviously). They just do it in C++.
<!--quoteo(post=1970038:date=Sep 2 2012, 12:49 PM:name=shad3r)--><div class='quotetop'>QUOTE (shad3r @ Sep 2 2012, 12:49 PM) <a href="index.php?act=findpost&pid=1970038"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Or you would incur the costs of multiple lock and unlock operations if the game thread tried locking the players whenever it needed to access them (which would be often).<!--QuoteEnd--></div><!--QuoteEEnd-->
You can't tell the CPU which thread it should handle next, this is completely random in the worst case. Plus the hardware worst case scenario would be 1 core = 1 running thread. When you now cause additional overhead for the game to keep the player objects in synch, the overhead is probably much worse than using direct references (and using only one object).
<!--quoteo(post=1970044:date=Sep 2 2012, 11:22 PM:name=falc)--><div class='quotetop'>QUOTE (falc @ Sep 2 2012, 11:22 PM) <a href="index.php?act=findpost&pid=1970044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You can't tell the CPU which thread it should handle next, this is completely random in the worst case. Plus the hardware worst case scenario would be 1 core = 1 running thread. When you now cause additional overhead for the game to keep the player objects in synch, the overhead is probably much worse than using direct references (and using only one object).<!--QuoteEnd--></div><!--QuoteEEnd-->
I think we are talking about different ways of handling the problem. I was imagining a pool of per-player threads that handled input in parallel as it arrived in preparation for the next server step. This would keep all cores working whenever there was work to be done, but depending on how the networking works, this might not work - i haven't looked at the NS2 code much.
If the main server thread just farmed out the input handling stage to multiple worker threads, then you could use the same objects. All available cores would be working during the input handling phase, but the rest of the sever step would be a single thread.
<!--quoteo(post=1970051:date=Sep 2 2012, 03:58 PM:name=shad3r)--><div class='quotetop'>QUOTE (shad3r @ Sep 2 2012, 03:58 PM) <a href="index.php?act=findpost&pid=1970051"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think we are talking about different ways of handling the problem. I was imagining a pool of per-player threads that handled input in parallel as it arrived in preparation for the next server step. This would keep all cores working whenever there was work to be done, but depending on how the networking works, this might not work - i haven't looked at the NS2 code much.<!--QuoteEnd--></div><!--QuoteEEnd-->
So, if the server has 20 slots for example, the server would start 20 threads (for each player one). Every thread would only handle the input from one player and update one certain player object, which gets copied or at least the state of it gets synchronized to a player object used by the world-thread (better term imho) whenever it wants to do an update?
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
Pretty much. In practice you are not going to attach the threads to a per-player object; better to use the number of threads to determine how many cores you would like to use; not much use for more threads than cores for jobs that does just CPU.
You just have a per-player context that gets queued to run on the first available thread whenever it has inputs to handle.
<!--quoteo(post=1970071:date=Sep 2 2012, 05:03 PM:name=matso)--><div class='quotetop'>QUOTE (matso @ Sep 2 2012, 05:03 PM) <a href="index.php?act=findpost&pid=1970071"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->better to use the number of threads to determine how many cores you would like to use; not much use for more threads than cores for jobs that does just CPU.<!--QuoteEnd--></div><!--QuoteEEnd-->
Depending from the implementation and the work the threads have to handle, this is not true.
<!--quoteo(post=0:date=:name=align)--><div class='quotetop'>QUOTE (align)</div><div class='quotemain'><!--quotec-->I wouldn't call a simple blunt statement "completely disrespecting" someone, and certainly not "violating" them.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=0:date=:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant)</div><div class='quotemain'><!--quotec-->I don't know what you're smoking but it's got to have serious side effects.<!--QuoteEnd--></div><!--QuoteEEnd--> <!--quoteo(post=0:date=:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant)</div><div class='quotemain'><!--quotec-->you mean it [the engine]sucks<!--QuoteEnd--></div><!--QuoteEEnd--> <!--quoteo(post=0:date=:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant)</div><div class='quotemain'><!--quotec-->I don't care how much easier it is to reload Lua code, it simply isn't an acceptable choice for game language using UWE's method.<!--QuoteEnd--></div><!--QuoteEEnd-->
Maybe it's not violating, but what's the point behind those "statements"?
<!--quoteo(post=1970067:date=Sep 3 2012, 12:27 AM:name=falc)--><div class='quotetop'>QUOTE (falc @ Sep 3 2012, 12:27 AM) <a href="index.php?act=findpost&pid=1970067"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->So, if the server has 20 slots for example, the server would start 20 threads (for each player one). Every thread would only handle the input from one player and update one certain player object, which gets copied or at least the state of it gets synchronized to a player object used by the world-thread (better term imho) whenever it wants to do an update?<!--QuoteEnd--></div><!--QuoteEEnd-->
Sorry, by 'per-player threads' I meant threads that do calculations for a single player. You wouldn't need one thread per connected player (unless you have 18+ cores), just that these threads handle calculations for one player at a time.
Otherwise, yes, that's exactly what I meant. Should keep all the cores busy so long as there is input to process.
I still don't see the need to use copies of the player objects. When you have to keep the objects synchronized you are still blocking the access to both at the same time and additionally have the overhead to udate the state.
<!--quoteo(post=1970039:date=Sep 2 2012, 02:05 PM:name=shad3r)--><div class='quotetop'>QUOTE (shad3r @ Sep 2 2012, 02:05 PM) <a href="index.php?act=findpost&pid=1970039"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Source and, I think, Goldsrc games use a <a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking" target="_blank">fixed input sampling rate</a>. So the problem of servers having to do more work for high framerate clients doesn't happen for them.<!--QuoteEnd--></div><!--QuoteEEnd-->
I wonder why Max isn't doing it this way, I mean it sounds like a solved problem.
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
<!--quoteo(post=1970090:date=Sep 2 2012, 06:24 PM:name=w0dk4)--><div class='quotetop'>QUOTE (w0dk4 @ Sep 2 2012, 06:24 PM) <a href="index.php?act=findpost&pid=1970090"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I wonder why Max isn't doing it this way, I mean it sounds like a solved problem.<!--QuoteEnd--></div><!--QuoteEEnd-->
Because high client fps hasn't really been a problem ... and its not really in 217 either. In lategame combats, even hot clients have problems doing 40 (which is a lot better than the 15 hitchy fps you got in the same situation 3-4 months ago, but still...).
So 20 players doing 60 stable fps was more of an example than a reality in 217.
<!--quoteo(post=1970118:date=Sep 2 2012, 07:02 PM:name=matso)--><div class='quotetop'>QUOTE (matso @ Sep 2 2012, 07:02 PM) <a href="index.php?act=findpost&pid=1970118"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Because high client fps hasn't really been a problem ... and its not really in 217 either. In lategame combats, even hot clients have problems doing 40 (which is a lot better than the 15 hitchy fps you got in the same situation 3-4 months ago, but still...).
So 20 players doing 60 stable fps was more of an example than a reality in 217.<!--QuoteEnd--></div><!--QuoteEEnd-->
But that seems crazy to design it around the fact that clients have low fps. Do they not have very high confidence of improving it much then? Or I guess maybe it's just not a priority but is planned eventually? It just seems to be a waste for the client to send updates to the server more often than the tickrate.
<!--quoteo(post=1970090:date=Sep 3 2012, 02:24 AM:name=w0dk4)--><div class='quotetop'>QUOTE (w0dk4 @ Sep 3 2012, 02:24 AM) <a href="index.php?act=findpost&pid=1970090"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I wonder why Max isn't doing it this way, I mean it sounds like a solved problem.<!--QuoteEnd--></div><!--QuoteEEnd-->
It isn't quite so simple as I made out. (My Source modding experience is mainly AI, I'm not super familiar with this stuff). It looks like Source clients send one movement command per client frame, it's just that the server combines all movement commands that apply to a given server frame before it calculates the results of the movement.
EDIT: as pointed out below, I was wrong. In Source input is sampled once per client frame, but then all commands that apply to one input tick are combined ON THE CLIENT and sent as one packet to the server. This means that your commands can get moved in time slightly - they get quantized to the nearest input tick.
<!--quoteo(post=1970233:date=Sep 3 2012, 12:53 AM:name=shad3r)--><div class='quotetop'>QUOTE (shad3r @ Sep 3 2012, 12:53 AM) <a href="index.php?act=findpost&pid=1970233"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It looks like Source clients send one movement command per client frame, it's just that the server combines all movement commands that apply to a given server frame before it calculates the results of the movement.<!--QuoteEnd--></div><!--QuoteEEnd-->
From reading the valve wiki it would seem like the client combines them into one packet before sending to the server.
"But instead of sending a new packet to the server for each user command, the client sends command packets at a certain rate of packets per second (usually 30). This means two or more user commands are transmitted within the same packet."
<!--quoteo(post=1969847:date=Sep 2 2012, 01:15 AM:name=falc)--><div class='quotetop'>QUOTE (falc @ Sep 2 2012, 01:15 AM) <a href="index.php?act=findpost&pid=1969847"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->He is not, to a certain extent.<!--QuoteEnd--></div><!--QuoteEEnd--> Then it's not embarrassingly parallel anymore.
<!--quoteo(post=1969908:date=Sep 2 2012, 05:07 AM:name=countbasie)--><div class='quotetop'>QUOTE (countbasie @ Sep 2 2012, 05:07 AM) <a href="index.php?act=findpost&pid=1969908"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ok, at first I thought "yeah, this guy may just want NS2 to be successful and is a bit harsh because of that". But you are completely disrespecting the developer matso who is friendly enough to answer multiple questions with long posts. What the hell are you doing here? When you aren't forced to pay for the game, then what do you want? When you want the game to be successful, why do you disrespect the developers of the game you like? How long are you gonna squirt without helping at all? Matso gives us information about the problems and possibilities in the engine...and you violate him.<!--QuoteEnd--></div><!--QuoteEEnd--> So I have to brownnose before I point out he's wrong? I already said I don't have access to code (engine in C++) so I don't have much that I can do to cure root issues.
<!--quoteo(post=1970038:date=Sep 2 2012, 02:49 PM:name=shad3r)--><div class='quotetop'>QUOTE (shad3r @ Sep 2 2012, 02:49 PM) <a href="index.php?act=findpost&pid=1970038"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You could, but then the input threads would be blocked whenever the game thread was using the player objects (which would be most of the time). Or you would incur the costs of multiple lock and unlock operations if the game thread tried locking the players whenever it needed to access them (which would be often).
Plus you usually only want player moves applied to player objects once per server frame.
Using copies with a single brief sync step satisfies the 'once per frame' constraint and keeps the input threads and the game thread running in parallel as much as possible.<!--QuoteEnd--></div><!--QuoteEEnd--> I already posted link to Microsoft's presentation about doing this with a little more theory behind it, it is there somewhere in my posts from months ago.
<!--quoteo(post=1970232:date=Sep 3 2012, 01:52 AM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Sep 3 2012, 01:52 AM) <a href="index.php?act=findpost&pid=1970232"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But that seems crazy to design it around the fact that clients have low fps. Do they not have very high confidence of improving it much then? Or I guess maybe it's just not a priority but is planned eventually? It just seems to be a waste for the client to send updates to the server more often than the tickrate.<!--QuoteEnd--></div><!--QuoteEEnd--> I'm not sure what people understood from that wiki page about Source but it's easy to confuse things. Source has 33/66/100 server ticks per second. Client can request updates from server from 10 to 100 times per second. Same with sending client input. When one of those 33 frames is happening and client has higher cmd rate than tickrate then server queues those cmds and runs Think functions for smaller delta time.
In Source, server runs player Think functions with queued cmds <b>one after another</b> so there's no problem with conflicts between data modified when running different player input.
<!--coloro:orange--><span style="color:orange"><!--/coloro--><sup>Merged your quadruple post. Please edit your post next time. -Angelusz</sup><!--colorc--></span><!--/colorc-->
<!--quoteo(post=1970235:date=Sep 3 2012, 01:02 AM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Sep 3 2012, 01:02 AM) <a href="index.php?act=findpost&pid=1970235"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->From reading the valve wiki it would seem like the client combines them into one packet before sending to the server.
"But instead of sending a new packet to the server for each user command, the client sends command packets at a certain rate of packets per second (usually 30). This means two or more user commands are transmitted within the same packet."
I guess the way you described is how NS2 does it.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well, this graph says that source clients sample the actual input 33 times per second: <a href="https://developer.valvesoftware.com/wiki/File:Networking1.gif" target="_blank">https://developer.valvesoftware.com/wiki/Fi...Networking1.gif</a>
That means that Source has a cap of 33 input samples, whereas NS2 does sample every "tick" which would be the FPS. So if you would connect with a 333fps client you would cause the load of 10 Source-engine clients. Of course it's not as simple as that but it sounds like this could be a nice performance win if that's really how it works.
How many of those samples are included in a packet does not really matter as long as they are still calculated seperately by the server (i.e. calling move() for every single sample). Btw.: NS2 client update packet rate is 20 per second IIRC.
CBasePlayer *pPlayer = NULL; CBaseEntity *pEnt = CBaseEntity::Instance(player); if ( pEnt && pEnt->IsPlayer() ) { pPlayer = static_cast< CBasePlayer * >( pEnt ); } // Too many commands? if ( totalcmds < 0 || totalcmds >= ( CMD_MAXBACKUP - 1 ) ) { const char *name = "unknown"; if ( pPlayer ) { name = pPlayer->GetPlayerName(); }
Msg("CBasePlayer::ProcessUsercmds: too many cmds %i sent for player %s\n", totalcmds, name ); // FIXME: Need a way to drop the client from here //SV_DropClient ( host_client, false, "CMD_MAXBACKUP hit" ); buf->SetOverflowFlag(); return 0.0f; }
// Initialize for reading delta compressed usercmds cmdNull.Reset(); from = &cmdNull; for ( i = totalcmds - 1; i >= 0; i-- ) { to = &cmds[ i ]; ReadUsercmd( buf, to, from ); from = to; }
// Client not fully connected or server has gone inactive or is paused, just ignore if ( ignore || !pPlayer ) { return 0.0f; }
I'd have to reread the code but I believe that on non-listen server, client creates more CUserCmds (per client frame) than server (per server tick). This creates whole issue of linearity of prediction. If gpGlobals->frametime can be different than TICK_INTERVAL then client computing x^2 * dt and adding it to variable will get different value than server (1^2 + 1^2 = 2 on client and 2^2 = 4 on server). I remember I had that problem. My memory is clouded and I'd have to recheck if it was the case or a mix of listen/dedicated servers and prediction.
HL2 code seems to say that input is sampled into CUserCmds at TICK_RATE but recompiling mod and running it in debug is beyond my laziness threshold.
<!--quoteo(post=1970349:date=Sep 3 2012, 11:29 AM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Sep 3 2012, 11:29 AM) <a href="index.php?act=findpost&pid=1970349"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm not sure what people understood from that wiki page about Source but it's easy to confuse things. Source has 33/66/100 server ticks per second. Client can request updates from server from 10 to 100 times per second. Same with sending client input. When one of those 33 frames is happening and client has higher cmd rate than tickrate then server queues those cmds and runs Think functions for smaller delta time.
In Source, server runs player Think functions with queued cmds <b>one after another</b> so there's no problem with conflicts between data modified when running different player input.<!--QuoteEnd--></div><!--QuoteEEnd-->
Is there any purpose to updating more frequently than the server tickrate though? Isn't that like trying to display a 120fps animation on a 60hz monitor. All of the source games I've played the servers always limited your updates to and from the server. They were generally always 33/66/100. I always just assumed that the admin set those limits to the tickrate of the server.
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
Depends on what you define the job to be. In NS2, the time required to process a user move is high enough (0.5-1ms) that I consider just RUNNING the move to be worthwhile job. Once you have processed the move, merging the result into the game would of course be a single-threaded job.
And the job of running the move is obviously parallel, as that is what the client and server are both doing, each on their own side. So setting up small "pseudo-clients" that would replicate the job of the client on the server, each running in their own thread, would be worthwhile. Once every 30ms, before the world update, you would have to "reap" the pseudo-clients and merge their input into the actual game world, which is probably best done in a single thread.
On Source, the cost of handling a user move is low enough that it would be useless to spin it out in multiple threads.
<!--quoteo(post=1970077:date=Sep 2 2012, 04:24 PM:name=countbasie)--><div class='quotetop'>QUOTE (countbasie @ Sep 2 2012, 04:24 PM) <a href="index.php?act=findpost&pid=1970077"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Maybe it's not violating, but what's the point behind those "statements"?<!--QuoteEnd--></div><!--QuoteEEnd--> My bad, thought you were referring to the one post.
<!--quoteo(post=1969731:date=Sep 1 2012, 08:03 PM:name=G1R)--><div class='quotetop'>QUOTE (G1R @ Sep 1 2012, 08:03 PM) <a href="index.php?act=findpost&pid=1969731"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Well.... all that is irrelevant to the opinion that NS2 is overpriced.<!--QuoteEnd--></div><!--QuoteEEnd-->
NS2 is a hardcore FPS/RTS. This makes it somewhat niche. Niche things tend to be priced a bit differently.
But to be honest, I've already gotten around 300 hours out of the game and most of those were very entertaining. That's more than I can say for 90% of the "AAA" $50 games with their 4 hours campaigns and tacked on generic multiplayer with empty servers. If they even have servers.
<!--quoteo(post=1970445:date=Sep 3 2012, 05:30 PM:name=matso)--><div class='quotetop'>QUOTE (matso @ Sep 3 2012, 05:30 PM) <a href="index.php?act=findpost&pid=1970445"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Depends on what you define the job to be. In NS2, the time required to process a user move is high enough (0.5-1ms) that I consider just RUNNING the move to be worthwhile job. Once you have processed the move, merging the result into the game would of course be a single-threaded job.<!--QuoteEnd--></div><!--QuoteEEnd--> That only works if "user move" (usercmd in Sourcespeak) is split into 2 parts: query world and resolve conflicts. Query world would not change any global data structures. Code that is written with serial execution in mind doesn't have that property. Move code in NS2 has to query global spatial partition each time it wants to know that player can move from A to be B and doesn't get stuck earlier. Last time I thought about parallelizing this I thought it'd lead to people passing through each other.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->And the job of running the move is obviously parallel, as that is what the client and server are both doing, each on their own side.<!--QuoteEnd--></div><!--QuoteEEnd-->
You're comparing different things. Server has to keep state correct with respect to execution of other players' moves. Data structures manipulated during move execution have to be either duplicated or access to them has to be synchronized. That is what prediction does - it keeps local data separate from ones confirmed to be correct by the server. Anything that has data races is by definition NOT embarrassingly parallel anymore.
Client does the same thing, it gets information about state of other players from the server.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->So setting up small "pseudo-clients" that would replicate the job of the client on the server, each running in their own thread, would be worthwhile. Once every 30ms, before the world update, you would have to "reap" the pseudo-clients and merge their input into the actual game world, which is probably best done in a single thread.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->On Source, the cost of handling a user move is low enough that it would be useless to spin it out in multiple threads.<!--QuoteEnd--></div><!--QuoteEEnd--> That's true but it doesn't really prove anything.
Why are we talking about this whole thing if server is running fast enough?
Comments
Didn't NS1 (and most other multiplayer games) do this without an issue?
I imagine Lua scripting is to blame for slowdown when dealing with alot of clients.
Ok, at first I thought "yeah, this guy may just want NS2 to be successful and is a bit harsh because of that".
But you are completely disrespecting the developer matso who is friendly enough to answer multiple questions with long posts. What the hell are you doing here? When you aren't forced to pay for the game, then what do you want? When you want the game to be successful, why do you disrespect the developers of the game you like? How long are you gonna squirt without helping at all?
Matso gives us information about the problems and possibilities in the engine...and you violate him.
You could, but then the input threads would be blocked whenever the game thread was using the player objects (which would be most of the time). Or you would incur the costs of multiple lock and unlock operations if the game thread tried locking the players whenever it needed to access them (which would be often).
Plus you usually only want player moves applied to player objects once per server frame.
Using copies with a single brief sync step satisfies the 'once per frame' constraint and keeps the input threads and the game thread running in parallel as much as possible.
Source and, I think, Goldsrc games use a <a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking" target="_blank">fixed input sampling rate</a>. So the problem of servers having to do more work for high framerate clients doesn't happen for them.
But they do handle input from multiple players every frame (obviously). They just do it in C++.
EDIT: added link.
You can't tell the CPU which thread it should handle next, this is completely random in the worst case. Plus the hardware worst case scenario would be 1 core = 1 running thread. When you now cause additional overhead for the game to keep the player objects in synch, the overhead is probably much worse than using direct references (and using only one object).
I think we are talking about different ways of handling the problem. I was imagining a pool of per-player threads that handled input in parallel as it arrived in preparation for the next server step. This would keep all cores working whenever there was work to be done, but depending on how the networking works, this might not work - i haven't looked at the NS2 code much.
If the main server thread just farmed out the input handling stage to multiple worker threads, then you could use the same objects. All available cores would be working during the input handling phase, but the rest of the sever step would be a single thread.
So, if the server has 20 slots for example, the server would start 20 threads (for each player one). Every thread would only handle the input from one player and update one certain player object, which gets copied or at least the state of it gets synchronized to a player object used by the world-thread (better term imho) whenever it wants to do an update?
You just have a per-player context that gets queued to run on the first available thread whenever it has inputs to handle.
Depending from the implementation and the work the threads have to handle, this is not true.
<!--quoteo(post=0:date=:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant)</div><div class='quotemain'><!--quotec-->I don't know what you're smoking but it's got to have serious side effects.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=0:date=:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant)</div><div class='quotemain'><!--quotec-->you mean it [the engine]sucks<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=0:date=:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant)</div><div class='quotemain'><!--quotec-->I don't care how much easier it is to reload Lua code, it simply isn't an acceptable choice for game language using UWE's method.<!--QuoteEnd--></div><!--QuoteEEnd-->
Maybe it's not violating, but what's the point behind those "statements"?
Sorry, by 'per-player threads' I meant threads that do calculations for a single player. You wouldn't need one thread per connected player (unless you have 18+ cores), just that these threads handle calculations for one player at a time.
Otherwise, yes, that's exactly what I meant. Should keep all the cores busy so long as there is input to process.
EDIT: what matso said.
I wonder why Max isn't doing it this way, I mean it sounds like a solved problem.
Because high client fps hasn't really been a problem ... and its not really in 217 either. In lategame combats, even hot clients have problems doing 40 (which is a lot better than the 15 hitchy fps you got in the same situation 3-4 months ago, but still...).
So 20 players doing 60 stable fps was more of an example than a reality in 217.
I've waited 10 F'ing years for this to come out. i'd buy and play this if they released it for the Atari 2600!
So 20 players doing 60 stable fps was more of an example than a reality in 217.<!--QuoteEnd--></div><!--QuoteEEnd-->
But that seems crazy to design it around the fact that clients have low fps. Do they not have very high confidence of improving it much then? Or I guess maybe it's just not a priority but is planned eventually? It just seems to be a waste for the client to send updates to the server more often than the tickrate.
It isn't quite so simple as I made out. (My Source modding experience is mainly AI, I'm not super familiar with this stuff). It looks like Source clients send one movement command per client frame, it's just that the server combines all movement commands that apply to a given server frame before it calculates the results of the movement.
EDIT: as pointed out below, I was wrong. In Source input is sampled once per client frame, but then all commands that apply to one input tick are combined ON THE CLIENT and sent as one packet to the server. This means that your commands can get moved in time slightly - they get quantized to the nearest input tick.
From reading the valve wiki it would seem like the client combines them into one packet before sending to the server.
"But instead of sending a new packet to the server for each user command, the client sends command packets at a certain rate of packets per second (usually 30). This means two or more user commands are transmitted within the same packet."
I guess the way you described is how NS2 does it.
Then it's not embarrassingly parallel anymore.
<!--quoteo(post=1969908:date=Sep 2 2012, 05:07 AM:name=countbasie)--><div class='quotetop'>QUOTE (countbasie @ Sep 2 2012, 05:07 AM) <a href="index.php?act=findpost&pid=1969908"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ok, at first I thought "yeah, this guy may just want NS2 to be successful and is a bit harsh because of that".
But you are completely disrespecting the developer matso who is friendly enough to answer multiple questions with long posts. What the hell are you doing here? When you aren't forced to pay for the game, then what do you want? When you want the game to be successful, why do you disrespect the developers of the game you like? How long are you gonna squirt without helping at all?
Matso gives us information about the problems and possibilities in the engine...and you violate him.<!--QuoteEnd--></div><!--QuoteEEnd-->
So I have to brownnose before I point out he's wrong? I already said I don't have access to code (engine in C++) so I don't have much that I can do to cure root issues.
<!--quoteo(post=1970038:date=Sep 2 2012, 02:49 PM:name=shad3r)--><div class='quotetop'>QUOTE (shad3r @ Sep 2 2012, 02:49 PM) <a href="index.php?act=findpost&pid=1970038"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You could, but then the input threads would be blocked whenever the game thread was using the player objects (which would be most of the time). Or you would incur the costs of multiple lock and unlock operations if the game thread tried locking the players whenever it needed to access them (which would be often).
Plus you usually only want player moves applied to player objects once per server frame.
Using copies with a single brief sync step satisfies the 'once per frame' constraint and keeps the input threads and the game thread running in parallel as much as possible.<!--QuoteEnd--></div><!--QuoteEEnd-->
I already posted link to Microsoft's presentation about doing this with a little more theory behind it, it is there somewhere in my posts from months ago.
<!--quoteo(post=1970232:date=Sep 3 2012, 01:52 AM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Sep 3 2012, 01:52 AM) <a href="index.php?act=findpost&pid=1970232"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But that seems crazy to design it around the fact that clients have low fps. Do they not have very high confidence of improving it much then? Or I guess maybe it's just not a priority but is planned eventually? It just seems to be a waste for the client to send updates to the server more often than the tickrate.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not sure what people understood from that wiki page about Source but it's easy to confuse things. Source has 33/66/100 server ticks per second. Client can request updates from server from 10 to 100 times per second. Same with sending client input. When one of those 33 frames is happening and client has higher cmd rate than tickrate then server queues those cmds and runs Think functions for smaller delta time.
In Source, server runs player Think functions with queued cmds <b>one after another</b> so there's no problem with conflicts between data modified when running different player input.
<!--coloro:orange--><span style="color:orange"><!--/coloro--><sup>Merged your quadruple post. Please edit your post next time. -Angelusz</sup><!--colorc--></span><!--/colorc-->
"But instead of sending a new packet to the server for each user command, the client sends command packets at a certain rate of packets per second (usually 30). This means two or more user commands are transmitted within the same packet."
I guess the way you described is how NS2 does it.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well, this graph says that source clients sample the actual input 33 times per second: <a href="https://developer.valvesoftware.com/wiki/File:Networking1.gif" target="_blank">https://developer.valvesoftware.com/wiki/Fi...Networking1.gif</a>
That means that Source has a cap of 33 input samples, whereas NS2 does sample every "tick" which would be the FPS. So if you would connect with a 333fps client you would cause the load of 10 Source-engine clients. Of course it's not as simple as that but it sounds like this could be a nice performance win if that's really how it works.
How many of those samples are included in a packet does not really matter as long as they are still calculated seperately by the server (i.e. calling move() for every single sample). Btw.: NS2 client update packet rate is 20 per second IIRC.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->float CServerGameClients::ProcessUsercmds( edict_t *player, bf_read *buf, int numcmds, int totalcmds,
int dropped_packets, bool ignore, bool paused )
{
int i;
CUserCmd *from, *to;
// We track last three command in case we drop some
// packets but get them back.
CUserCmd cmds[ CMD_MAXBACKUP ];
CUserCmd cmdNull; // For delta compression
Assert( numcmds >= 0 );
Assert( ( totalcmds - numcmds ) >= 0 );
CBasePlayer *pPlayer = NULL;
CBaseEntity *pEnt = CBaseEntity::Instance(player);
if ( pEnt && pEnt->IsPlayer() )
{
pPlayer = static_cast< CBasePlayer * >( pEnt );
}
// Too many commands?
if ( totalcmds < 0 || totalcmds >= ( CMD_MAXBACKUP - 1 ) )
{
const char *name = "unknown";
if ( pPlayer )
{
name = pPlayer->GetPlayerName();
}
Msg("CBasePlayer::ProcessUsercmds: too many cmds %i sent for player %s\n", totalcmds, name );
// FIXME: Need a way to drop the client from here
//SV_DropClient ( host_client, false, "CMD_MAXBACKUP hit" );
buf->SetOverflowFlag();
return 0.0f;
}
// Initialize for reading delta compressed usercmds
cmdNull.Reset();
from = &cmdNull;
for ( i = totalcmds - 1; i >= 0; i-- )
{
to = &cmds[ i ];
ReadUsercmd( buf, to, from );
from = to;
}
// Client not fully connected or server has gone inactive or is paused, just ignore
if ( ignore || !pPlayer )
{
return 0.0f;
}
MDLCACHE_CRITICAL_SECTION();
pPlayer->ProcessUsercmds( cmds, numcmds, totalcmds, dropped_packets, paused );
return TICK_INTERVAL;
}<!--c2--></div><!--ec2-->
I'd have to reread the code but I believe that on non-listen server, client creates more CUserCmds (per client frame) than server (per server tick). This creates whole issue of linearity of prediction. If gpGlobals->frametime can be different than TICK_INTERVAL then client computing x^2 * dt and adding it to variable will get different value than server (1^2 + 1^2 = 2 on client and 2^2 = 4 on server). I remember I had that problem. My memory is clouded and I'd have to recheck if it was the case or a mix of listen/dedicated servers and prediction.
HL2 code seems to say that input is sampled into CUserCmds at TICK_RATE but recompiling mod and running it in debug is beyond my laziness threshold.
In Source, server runs player Think functions with queued cmds <b>one after another</b> so there's no problem with conflicts between data modified when running different player input.<!--QuoteEnd--></div><!--QuoteEEnd-->
Is there any purpose to updating more frequently than the server tickrate though? Isn't that like trying to display a 120fps animation on a 60hz monitor. All of the source games I've played the servers always limited your updates to and from the server. They were generally always 33/66/100. I always just assumed that the admin set those limits to the tickrate of the server.
Depends on what you define the job to be. In NS2, the time required to process a user move is high enough (0.5-1ms) that I consider just RUNNING the move to be worthwhile job. Once you have processed the move, merging the result into the game would of course be a single-threaded job.
And the job of running the move is obviously parallel, as that is what the client and server are both doing, each on their own side. So setting up small "pseudo-clients" that would replicate the job of the client on the server, each running in their own thread, would be worthwhile. Once every 30ms, before the world update, you would have to "reap" the pseudo-clients and merge their input into the actual game world, which is probably best done in a single thread.
On Source, the cost of handling a user move is low enough that it would be useless to spin it out in multiple threads.
My bad, thought you were referring to the one post.
NS2 is a hardcore FPS/RTS.
This makes it somewhat niche.
Niche things tend to be priced a bit differently.
But to be honest, I've already gotten around 300 hours out of the game and most of those were very entertaining.
That's more than I can say for 90% of the "AAA" $50 games with their 4 hours campaigns and tacked on generic multiplayer with empty servers. If they even have servers.
That only works if "user move" (usercmd in Sourcespeak) is split into 2 parts: query world and resolve conflicts. Query world would not change any global data structures. Code that is written with serial execution in mind doesn't have that property. Move code in NS2 has to query global spatial partition each time it wants to know that player can move from A to be B and doesn't get stuck earlier. Last time I thought about parallelizing this I thought it'd lead to people passing through each other.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->And the job of running the move is obviously parallel, as that is what the client and server are both doing, each on their own side.<!--QuoteEnd--></div><!--QuoteEEnd-->
You're comparing different things. Server has to keep state correct with respect to execution of other players' moves. Data structures manipulated during move execution have to be either duplicated or access to them has to be synchronized. That is what prediction does - it keeps local data separate from ones confirmed to be correct by the server. Anything that has data races is by definition NOT embarrassingly parallel anymore.
Client does the same thing, it gets information about state of other players from the server.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->So setting up small "pseudo-clients" that would replicate the job of the client on the server, each running in their own thread, would be worthwhile. Once every 30ms, before the world update, you would have to "reap" the pseudo-clients and merge their input into the actual game world, which is probably best done in a single thread.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->On Source, the cost of handling a user move is low enough that it would be useless to spin it out in multiple threads.<!--QuoteEnd--></div><!--QuoteEEnd-->
That's true but it doesn't really prove anything.
Why are we talking about this whole thing if server is running fast enough?