Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Game lags only for laggy clients?
- - Date 2012-12-06 12:59
Parent - - By Pyrit Date 2012-12-04 14:59
@Network

What's with the idea that the game only lags for the laggy clients? (alas post btw)
Parent - - By PeterW [gb] Date 2012-12-04 16:16 Edited 2012-12-04 16:28
Well, that's what asynchronous mode is. Its weaknesses are well known - somebody has to decide who's "laggy". That pretty much makes it a no-go for league games, unless we have a dedicated server.

Edit: Something that we could act on would be the known problems with packet losses (aka WLAN). That would mean reimplementing my rather naive guaranteed-delivery UDP network layer (C4NetIOUDP). Good exercise if somebody wants to implement a low-level network protocol. On the other hand, it's a shot into the dark really - we have no hard data whatsoever whether it will make a noticeable difference.
Parent - - By Zapper [de] Date 2012-12-04 16:44
A very naive idea: could it possibly help if Clonk just sends every packet twice (when in a known laggy-wlan-environment)? Halves the throughput obviously - but that should not be a problem since Clonk does not need throughput but reliability and speed and it would not rely on any answer from the host before re-sending the packet.
Parent - - By Sven2 [de] Date 2012-12-04 17:11
When wireless LAN drops packets e.g. because the adapter is busy searching for new stations, then it probably drops all packets for a certain time frame. I doubt that sending stuff twice in quick succession would help.
Parent - - By Zapper [de] Date 2012-12-04 17:20
One would wait for a very short time (1ms or even 2 ms? should be long enough in terms of WLAN-collisions) of course - that would still be a lot faster than noticing the missing reply from the server >30ms later and re-sending the packet at that point
Parent - - By Sven2 [de] Date 2012-12-04 17:43
Are you sure it is due to collisions and not due to the adapter searching for new networks? Because that's the most common problem I had.

Also, doubling the traffic to reduce the effect of collisions is kinda weird.
Parent - - By Zapper [de] Date 2012-12-04 17:46

>Because that's the most common problem I had.


Mh, so the most common problem is not that single packets get lost but that the whole link is simply unavailable for a time which is larger than the ping anyway?
Parent - - By Sven2 [de] Date 2012-12-04 18:34
Yes. With some people on wireless, the game halts for 1-2 seconds once every ~30 seconds.

I don't know if that's the same problem ala talks about of course.
Parent - - By PeterW [gb] Date 2012-12-04 22:31
Well, that might just be because C4NetIOUDP only checks for packet losses every other second. ACK based protocols like TCP are a *lot* better at recovering losses quickly.
Parent - By PeterW [gb] Date 2012-12-05 18:11
Hm, let me back-pedal a bit, I remember I was wrong about this before - C4NetIOUDP would actually recover from one-packet-lost errors quite quickly already, as the first out-of-sequence packet would immediately cause a check and the resending of the packet. For a one-second pause, we need to lose so many packets that we run out of data and have to stop sending.

This actually means that even double-sending wouldn't cause much improvement to these mega-lags :/
Parent - - By PeterW [gb] Date 2012-12-04 22:27 Edited 2012-12-04 22:29
Hm, yeah, I had thought of something a bit similar in fact - the key observation is that we are sending a lot of very small packets, so we are actually mostly paying packet overhead. Or put another way: Appending past packets to existing ones would be relatively cheap and could allow us to recover from packet losses very rapidly as pre-send ensures that we will continue sending for a bit even if packets are lost.

On the other hand, that's another shot into the dark, and I'm not even sure how to measure the improvement. I also don't like the thought of transmitting extra data for everyone just for the 1% that have a crappy WLAN.
Parent - - By Zapper [de] Date 2012-12-04 22:46

>I also don't like the thought of transmitting extra data for everyone just for the 1% that have a crappy WLAN.


My general idea was that would be a default-off option under "troubleshooting". So that only when you have a bad experience (and WLAN) others will point you at trying that option and see whether it helps. ["OMG NOOB LAG TURN ON WLAN BOOST OMG"]
Parent - By Sven2 [de] Date 2012-12-04 23:18
People will just turn it on randomly.

It's not hard to detect if there are packet losses. So the system can just append the packets there when there are packet losses.
Parent - - By PeterW [gb] Date 2012-12-05 00:40
Isn't the problem that the kind of people that have crappy WLAN are also the kind of people that you will have trouble explaining to that they need to activate some obscure option?
Parent - By Zapper [de] Date 2012-12-05 12:08
I had crappy WLAN in my old flat, too!

A lot of the regular CR players have suboptimal WLAN from what I get from ala.
Parent - - By PeterW [gb] Date 2012-12-05 00:47

> <Zapper> Möglicherweise sogar mit drei-letzte-Pakete anhängen Wenn das gesamtpaket (plus UDP/IP Header) dann noch unter ~570byte ist
> <Zapper> (und wenn laut presend drei Pakete noch OK sind)


No, we shouldn't let packets grow that large. We don't need to, really - many packets will be just "nothing happened in tick X on client Y" - maybe 6 bytes payload. So even low limits like 20-30 bytes would potentially do some good.
Parent - By Zapper [de] Date 2012-12-05 09:17

>many packets will be just "nothing happened in tick X on client Y"


Mh, could it help to just extent that protocol to "nothing happened in the last X frames" instead of "nothing happened in the last frame"? If that is really the most common packet.
But I'd guess with the mouse and all that you would have constant updates WITH controls a lot more often?
Parent - - By Zapper [de] Date 2012-12-05 11:40 Edited 2012-12-05 11:43
I just read through one of the interesting articles that exist about the Quake (3) netcode. Next to some other tricks (which are obviously not feasible for Clonk), they have no problem with sending stuff (even chat!!) every single frame again until it gets acknowledged.
And that seems to work just fine.

> http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

Parent - - By PeterW [gb] Date 2012-12-05 13:21 Edited 2012-12-05 13:23
Yes, but only because chat is rare to the point of irrelevance - for the actual game data Q3 can just skip old states and send only the newest one. We can't do that, so unfortunately there's little we can really learn from that. Note that nowadays e.g. Torque already go the full distance by having separate protocols for "event packets" like chat and game data.
Parent - - By Zapper [de] Date 2012-12-05 13:47
What I mainly got from that article was that it is not neccessary to optimize packet size when you want a speedy transmission, but sometimes brute force instead of smart acknowledgement can be a very good solution.

Of course, Quake uses a state-model, unlike Clonk, but the that idea can still carry over.
Parent - - By PeterW [gb] Date 2012-12-05 15:11 Edited 2012-12-05 15:16
And I'm telling you that you got the message wrong imo - brute force is only a good solution for things you don't care about. Chat messages were simply not worth optimizing for the Q3 guys - so what if the game clogs up your connection for the few seconds you happen to be chatting. We are effectively looking into sending 20 "chat messages" per second per client, we have to worry about snowball effects.

Double-sending with strict limits would be acceptable, I think - but I am *very* wary of anything beyond that. Packet size does matter.
Parent - - By Zapper [de] Date 2012-12-05 15:32 Edited 2012-12-05 15:34
Chat messages were just one example that belong to one of their game-states.

But generally, the overhead of being able to create a game-state delta packet against the last-acknowledged state means that the server would rather keep past states in memory (which obviously increases the packet size of later updates) instead of rather keeping UDP-packets around to be able to re-send them on request.

Yes, the requirements in Clonk are very different: in Quake a client obviously receives game-state-updates as opposed to controls. That's partly why a client is really not interested in past game-states to have a synchronized simulation.

But I still got from that article that even in a high-fps & low-latency environment like a FPS it does not matter much whether the UDP packets are now 5B or 100B - completely independant of chat-messages.

PS: and I'd believe that Clonk currently uses more the very small (<5B?) packets?
Parent - - By Sven2 [de] Date 2012-12-05 16:47

> But I still got from that article that even in a high-fps & low-latency environment like a FPS it does not matter much whether the UDP packets are now 5B or 100B - completely independant of chat-messages.


That's something I don't believe unless I see proper measurement of it.
Parent - By PeterW [gb] Date 2012-12-06 12:59
Especially because large packets are a lot more likely to be lost when we just assume random isolated bit changes. Admittedly, this only doubles the failure rate while the double-sending would be expected to square it (= reduce it). Still, it's remarkably tricky to predict what would happen, and as far as I know the Q3 people haven't done proper measurements either, so this might just be them having less whiny fans ( ;) ).

I think the only way forward would be to grab somebody with known problems and try to get exact numbers for how big the loss rates and loss bursts are for different packet sizes. Anybody? :)
Up Topic Development / Developer's Corner / Game lags only for laggy clients?

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill