![[gb]](/mwf/flags/gb.png "United Kingdom")
Uhm. I put a number of years into completely rewriting the network code from the ground up, with the expressed goal to make it more resistant against lag - how am I "wrong" about anything? I might be unsuccessful, possibly, but I don't think it's fair to say that I somehow ignored lag complaints.
![[de]](/mwf/flags/de.png "Germany")
You did a very fine job (especially considering the improvement based on Clonk Planet), but after all you left the task somehow unfinished :/. I remember complaining and providing feedback as far back as 2008.
The last 10% are the hardest to get. I might have been wrong about a few things when I started out, but right now I just don't see any low-hanging fruit anymore. Maybe I'm stupid or something, but between the three control delivery modes available right now I can't think of a another viable alternative.
A relatively obvious change would be to stop drawing frames automatically when a client is behind in frames (as is already happening for large behind values on runtime join). So slow clients don't slow down the game any more.Another change would be the fabled Pre-Send calculation ;)
True enough - but how exactly would that work? Such a mechanism would have to know two things:
1. That the local client's performance is, in fact, graphics-bound. Do we have a reliable method for that?
2. That all other client's performance is network-bound. Would require everybody to share *their* timings as well.
Also, how exactly do we characterize the target state? In case we have a truly slow scenario where everybody is struggling to manage the load, having frame-drops everywhere would not make sense. So is the idea something like building a global consensus on how much time budget to allocate for every frame? Median over active clients, possibly?
And yes, one of my favourite ideas for possibly speeding up the network right now would be to make the pre-send consider ping fluctuations. After all, we want something like a confidence interval here - how much time/frames must we add so we are "reasonably" (90%?) sure that no connection lags. Under the (wrong) assumptions that round-trip times form a normal distribution and are independent of each other, this should be solvable using statistical methods. Then we'd just need to measure the deviation of pings and possibly get a nice pre-send fomula that punishes people with lag "spikes" while allowing smooth play for players with slow but stable connections.
1. That the local client's performance is, in fact, graphics-bound. Do we have a reliable method for that?
2. That all other client's performance is network-bound. Would require everybody to share *their* timings as well.
Also, how exactly do we characterize the target state? In case we have a truly slow scenario where everybody is struggling to manage the load, having frame-drops everywhere would not make sense. So is the idea something like building a global consensus on how much time budget to allocate for every frame? Median over active clients, possibly?
And yes, one of my favourite ideas for possibly speeding up the network right now would be to make the pre-send consider ping fluctuations. After all, we want something like a confidence interval here - how much time/frames must we add so we are "reasonably" (90%?) sure that no connection lags. Under the (wrong) assumptions that round-trip times form a normal distribution and are independent of each other, this should be solvable using statistical methods. Then we'd just need to measure the deviation of pings and possibly get a nice pre-send fomula that punishes people with lag "spikes" while allowing smooth play for players with slow but stable connections.
Punishing people with spikes could be difficult. Ping times during spikes are often a magnitude higher than the regular ping times (Say, 1000ms vs 50ms regular). Even if you double the PreSend, the spike will cause almost the same amount of stuttering, but the responsiveness of the offending client will be reduced by a lot.For the case of spikes, maybe it would help if single clients can be pushed into asynchronous mode. In theory, if the ping times are somewhat stable, asynchronous mode is not much different from regular central mode. Of course in games like Floor Fight, having your controls dropped if you spike can cause certain death.
Changing control-mode per client is one of the things that I wish I had thought about when I started coding the whole thing - that *might* have allowed for more options right now. As it is, I can't even say whether it would be compatible with all the other stuff we're doing.
And this wouldn't really be that much about stutters - more about the consistently slow games ala was talking about. These could well be due to ping times changing as well - possibly on a smaller scale, but on all connections at once. It might be worth a shot.
And this wouldn't really be that much about stutters - more about the consistently slow games ala was talking about. These could well be due to ping times changing as well - possibly on a smaller scale, but on all connections at once. It might be worth a shot.
From my experience, the consistently slow games are almost always due to graphics running slow on one of the clients ("It Korks"). Fluctuating pings are not much of an issue. People either have completely unusably spikey connections (pings going up to 2-3 seconds regularly) so you have to kick them, or they just get some regular lag spikes e.g. one second of halt every 30 seconds caused by WiFi connection stuff.
Are you sure that it's the graphics? Couldn't it just be the simulation taking so long that the graphics delay becomes noticeable?
And a counterexample: For some reason, my router currently is varying wildly between as much as 200 and 50 ms to the next hop. I'm pretty sure that would be a pretty good way of killing a game as well...
Aren't we already sending everything twice (TCP+UDP)? Shouldn't that get most spikes?
No - the engine has two connections, but they are used for different kinds of packets. To be precise - the TCP connection is pretty much only used for transmitting resources (scenarios, object files, player files). Main reason is to allow chatting and playing without delay with background file transfers.
One thing we might try, btw, is side-stepping the clearly not optimal NAK-based protocol UDP currently uses and replace the whole thing with *two* TCP connections. Would kill all punching attempts, but *might* give better performance.
One thing we might try, btw, is side-stepping the clearly not optimal NAK-based protocol UDP currently uses and replace the whole thing with *two* TCP connections. Would kill all punching attempts, but *might* give better performance.
Ah, so that's my Network performs better when I turn UDP off...
No one is expecting you to write perfect code from the start or immediately solving anything. I understand that the work-benefit rate just isn't there short term.
But long term we of course would love to have some improvement. Lagfree clonk is like a drug that will make everyone happy ;)
I'd love to provide help with testing as much as you like, since I know players which lag for dubious reasons regularly. The most important thing should be to get the asynchron mode working properly - and to figure why it is not. I'm having some hope, because there was a time in net2 in which it kind of worked great, but later it became this state what it is today: If I change the game to asynchron mode it will just lag too, even if the lag has a different feel to it (and it even lags less most of the time in normal mode).
But long term we of course would love to have some improvement. Lagfree clonk is like a drug that will make everyone happy ;)
I'd love to provide help with testing as much as you like, since I know players which lag for dubious reasons regularly. The most important thing should be to get the asynchron mode working properly - and to figure why it is not. I'm having some hope, because there was a time in net2 in which it kind of worked great, but later it became this state what it is today: If I change the game to asynchron mode it will just lag too, even if the lag has a different feel to it (and it even lags less most of the time in normal mode).
The problem with optimizations in network code here is that we can not do that much to speed up packets. Sure we could try to reduce packet size, network thread responsiveness, etc; but there isn't much to gain here. Most changes now are trade-offs. You can sacrifice game speed for response times or vice versa. You can sacrifice graphics quality (dropped frames) for game speed (low FPS) or vice versa.The question is: If a client doesn't talk for a while because the network or CPU are clogged, then what do you do? Do you ignore this and just let the game run for all others? Then the controls will feel laggy on the offending client and he can't react properly. Do you let everyone wait for the hanging client? Then the game speed will feel slow for everyone.
> Do you ignore this and just let the game run for all others? Then the controls will feel laggy on the offending client and he can't react properly.
Thats the way ~every shooter handles this problem and it works! If someone lags the whole time, he will do something immediately (close his downloads, decrease gfx, better pc/internet con.). If the game runs for everyone slow he will do nothing except some lurky excuses.
Yeah, you're right, except that shooters can cope with a little lag, because there rarely are any physics which are influenced by the player. (Have you ever seen a car pop up in front of you in Crysis 2..? It's quite ridiculous.)
If you have a little lag, especially with varying delays, shooters can just port the player over a short distance. Clonk can't do that, so the game will be unplayable even with very little lag. The countermeasure would be of course to not increase or decrease the delay ("PreSend" ?) too quickly, but that's a hard compromise to make.
If you have a little lag, especially with varying delays, shooters can just port the player over a short distance. Clonk can't do that, so the game will be unplayable even with very little lag. The countermeasure would be of course to not increase or decrease the delay ("PreSend" ?) too quickly, but that's a hard compromise to make.
> except that shooters can cope with a little lag, because there rarely are any physics which are influenced by the player.
Or rather: Any physics which influence players. Destroyable things often have some physics, but players can usually just walk through the debris.
>Do you let everyone wait for the hanging client? Then the game speed will feel slow for everyone.
This is the current solution. This works fine if I only play private with some friends. They all optimize their computer and network, and if it doesn't work for some, I can just play with the others. If we have slow computers, we can after all play simple scenarios - which work fine on the slowest machine.
..different story in public entirely:
-Some kids don't believe that they are the lag cause and won't change anything
-Some even feel insulted and start flaming
-Some kids just download, skype, stream etc. and don't care - the game is fast enough for their standards
-Some players prefer playing with a little lag, because they actually play better this way
-Some players set the game on high resolution to view more from the landscape, they don't care about lag.
That's behaviour that makes me wish to jump out of their screen, and punch them in the face.
Their are also problems with:
-wlan, some players do perfectly everything possible and don't lag for most of the time - only to start lagging regulalrly without reasons.
-Foreign players: Our neighbour countries work fine, say Italy, Netherlands, Poland, GreatBritain, Finnland - but all further away don't and just lag!
-----
All of this create big trouble in league games especially, since you just can't kick players easily. Same applies for team games, because the teams get unbalanced. And I just shouldn't talk about league based teamgames: The team members of the lagging players will just deny kicking, because they fear loosing. And that's the whole frustrating story of the current system.
It lags, and all normal players are just pissing each other off - while the lagers don't care and play anyway.
See Nachtfalter: If the player will feel the consequences for his misbehaviour or slow machine alone, he will try to improve that situation - which works out way better for all of us.
![[us]](/mwf/flags/us.png "United States")
My two cents... I like the way OpenClonk handles lag. Perhaps because I mostly play co-operative scenarios, whatever the case, I like it.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
