OpenArena Message Boards

OpenArena => Multiplayer => Topic started by: The Geez on August 29, 2011, 06:34:35 PM



Title: Connection Icon
Post by: The Geez on August 29, 2011, 06:34:35 PM
How is it possible to turn off that annoying connection icon above people's heads on my server? lol

 :-\


Title: Re: Connection Icon
Post by: Gig on August 30, 2011, 12:42:48 AM
What? Could you please post a screenshot?

UPDATE: Uh, I understand... no need for a screen.


Title: Re: Connection Icon
Post by: Cacatoes on August 30, 2011, 02:40:20 AM
It's because players lag.
It could be possible to disable notes over other players head, but if so I forgot the cvar, maybe cg_draw*something*


Title: Re: Connection Icon
Post by: Gig on August 30, 2011, 02:55:09 AM
It's because players lag.
It could be possible to disable notes over other players head, but if so I forgot the cvar, maybe cg_draw*something*

Something similar to \cg_drawfriend or \cg_drawRewards? It's possible. If someone knows it, he could add it to the list DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Graphic_options]here (http://([b). Anyway I don't suggest to disable it. I feel that fragging a lagging, immobile player, could be not so polite, like a chatfrag.

Geez, normally you should not see that symbol too often (well, while a player is lagging, or when he lost connection)... if you see it too commonly, or above more players at once, it may mean that your server may be not correctly configured or that your internet connection is not fast enough.


Title: Re: Connection Icon
Post by: 7 on August 30, 2011, 10:44:09 AM
How is it possible to turn off that annoying connection icon above people's heads on my server? lol

Just a wild guess: by not running your server on a wireless connection?

When every player on your server seems to lag, its probably your server that's lagging and not all of the players. Because most cable and dsl connections nowadays have enough upstream bandwidth to support at least 4 players, the bottleneck is probably a wireless connection.

If this isn't the case and you simply haven't got enough upstream bandwidth, you should limit your players' bandwidth by setting sv_maxrate in your server config. You should set sv_maxrate to your upstream bandwidth in kB/s multiplied by 900 and divided by the number of players you want to support, but don't go under a value of 5000!  (By multiplying by 900 instead of the full 1000, you reserve 10% of the upstream bandwidth for overhead, which is a good thing.)

Example: Suppose you've got 50 kB/s upstream and want to support 4 players maximum you should set sv_maxrate to 50 * 900 / 4 = 11250.


Title: Re: Connection Icon
Post by: Gig on August 30, 2011, 10:48:48 AM
Example: Suppose you've got 50 kb/s upstream and want to support 4 players maximum you should set sv_maxrate to 50 * 900 / 4 = 11500.
50 kb or kB?

50 kB * 8 = 400 kb... upload bandwidth of an average ADSL, I suppose. 400kbps/1024=0,39 Mbps (ADSL technology can go up to 1 Mbps, if I remember correctly, but usually service providers give you lower bandwidth).


Title: Re: Connection Icon
Post by: 7 on August 30, 2011, 11:12:19 AM
50 kB * 8 = 400 kb... upload bandwidth of an average ADSL, I suppose. 400kbps/1024=0,39 Mbps

I mean kB, and I made a real error too, which I corrected above.

You are making a fundamental error in your calculations too by the way, by mixing kibibits (1 kibit  = 2^10 bits) and kilobits (1 kbit = 10^3 bits).
(400 kbit/s) / 1000 = 0.4 Mbit/s exactly!

See: http://en.wikipedia.org/wiki/Binary_prefix


Title: Re: Connection Icon
Post by: Gig on August 30, 2011, 04:59:36 PM
Uhm... they state that bandwidth is expressed in kilobits instead of kibibits. I thought it was expressed in kibibits and that simply did not use the "new" kibi etc. names... so I was wrong.


Title: Re: Connection Icon
Post by: The Geez on August 30, 2011, 07:41:42 PM
The server is on a Comcast cable connection. Hardwired, no wireless. 60/11, 60mbps down, 11mbps up. I figure that's way more  than enough for 2 simple Q3 servers.

UPDATE: I may have found the issue, I had sv_fps set to 100 on the server. What should this default to? I changed it to 60, and I see much less of the connection icon on people. It still comes up over their head on occasion, but maybe this is now on their end.






Title: Re: Connection Icon
Post by: pulchr on August 31, 2011, 12:36:31 AM
i don't run a server, but a quick google search suggests something in the range of 20 to 30 sv_fps.


Title: Re: Connection Icon
Post by: Gig on August 31, 2011, 01:53:07 AM
I'm not sure about the best sv_fps value, anyway our DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]server config example (http://([b) uses 25.

@7, for the moment, I did DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Tweak&action=historysubmit&diff=8901&oldid=8726]this change (http://([b) (fix it if needed), but I'd like to write something more complete to DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Multiplayer]this page (http://([b) (where I added DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Manual%2FMultiplayer&action=historysubmit&diff=8910&oldid=8907]this (http://([b) in the meanwhile), and I would appreciate your help.
I think we should cover:
- How to calculate how many players are supported starting from a certain upload bandwidth (including how to convert from Mbps to kBps), at maximum rate (25000) and at another rate, and to what sv_maxrate one should not go under.
- How to do the inverse calculation (how one should set sv_maxrate to support the needed number of players).
- Remember to the user to set sv_maxclients taking in account the calculations above.
- That sv_maxrate should be set to 25000 to have VoIP feature working correctly.
- Difference with "kilo" and "kibi" etc. measures, saying that bandwidth is expressed in SI decimal prefixes (see Wikipedia (http://en.wikipedia.org/wiki/Binary_prefix#Data_transmission_and_clock_rates)), explaining that's why we divide by 1000 instead of 1024.
- Some words about sv_minrate, too?
- Anything else you think would be useful for a server admin to know about bandwidth management.

In the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]server config example (http://([b), I would simply add how many players are supported for each MBps of upload bandwith, in the line about sv_maxrate, at 25000.



Title: Re: Connection Icon
Post by: Cacatoes on August 31, 2011, 06:12:29 AM
Just leave it blank, it will use default and you'll be fine.

20 or 40 since these values won't require players to adjust theirs.
If you select 30 and people have 20, it isn't a multiple of their value, so it has to be avoided.

Some solution to avoid headaches could be to automatically synchronise player/server values, as often suggested by Falkland ages ago.

High sv_fps value require high bandwidth, which can be good when you play on LAN, but not on WAN.


Title: Re: Connection Icon
Post by: sago007 on August 31, 2011, 09:32:39 AM
Default for sv_fps is 20. This setting is tolerant for occasional packagedrops and are good for Internet/wireless where some player typically have a ping around 50 ms.


Title: Re: Connection Icon
Post by: Gig on August 31, 2011, 12:52:37 PM
Then, any idea of why the example DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]here (http://([b) used 25? Do you think it's better to change it to 20?


Title: Re: Connection Icon
Post by: sago007 on August 31, 2011, 01:08:24 PM
Then, any idea of why the example DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]here (http://([b) used 25? Do you think it's better to change it to 20?
I don't remember, at some point it was pointed out that the engine could calculate more fluently if the sv_fps was 25 (maybe because the framerate was 125 or pmove_fixed was used). I doubt it makes much difference because the game takes timing into account then interpolating. Optimizing for network is likely more important. 


Title: Re: Connection Icon
Post by: 7 on September 01, 2011, 01:39:08 AM
Then, any idea of why the example DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]here (http://([b) used 25? Do you think it's better to change it to 20?
I don't remember, at some point it was pointed out that the engine could calculate more fluently if the sv_fps was 25 (maybe because the framerate was 125 or pmove_fixed was used). I doubt it makes much difference because the game takes timing into account then interpolating. Optimizing for network is likely more important.  

Basically, sv_fps 20 gives you the (in)famous '50 ms built-in lag' (1000 ms / 20 fps = 50 ms lag); if you increase sv_fps more snapshots per second will be sent to the clients so the 'built-in lag' is reduced: sv_fps 25 will reduce the built-in lag to 40 ms and sv_fps 30 to 33 ms. Increasing sv_fps has two drawbacks: firstly, players with slow connections will get data congestion and will appear laggy to other players (which is the Geez' problem), and secondly and more importantly, the unlagged code works best at sv_fps 20.

@Gig: I will update the wiki pages in the coming weekend.

Edit:
Unlagged FAQ: http://ra.is/unlagged/faq.html#ISFPSHT20SR

(Which reminds me that cl_timenudge in combination with unlagged does seem to work correctly according to g_trueping since B48, I'll edit that wiki section too.)


Title: Optimizing the connection settings of ioquake3 and openarena
Post by: GrosBedo on September 01, 2011, 06:33:00 AM
=> For those who don't want to read my long post: sets sv_fps 25 is one of the best optimized parameter currently for a server, and for a client the best optimized parameters are: set snaps = cl_maxPackets = com_maxFPS (so if you have com_maxFPS = 125 you should have snaps = 125, cl_maxPackets = 125, com_maxFPS = 125).

Then, any idea of why the example DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]here (http://([b) used 25? Do you think it's better to change it to 20?
I don't remember, at some point it was pointed out that the engine could calculate more fluently if the sv_fps was 25 (maybe because the framerate was 125 or pmove_fixed was used). I doubt it makes much difference because the game takes timing into account then interpolating. Optimizing for network is likely more important.  

Setting to sv_fps 25 is an important optimization for network (more solid and constant data flow) as well as hitscan (hits are more precise). And there's no point in pmove_fixed, sv_fps always alter the gameplay (see below my summary of the rules for optimizing connections).

More infos :
http://www.urbanterror.info/forums/topic/19188-suggestion-wierd-behavior-of-the-engine-snapss-perhaps-important/page__p__244181#entry244181

But you are right in pointing that sv_fps 25 is an optimized parameter because of the popularity of the framerate 125, because com_maxfps (and cl_maxPackets) must be a multiple of sv_fps (and inversely) for the flow to be constant.

Quote from: 7
Edit:
Unlagged FAQ: http://ra.is/unlagged/faq.html#ISFPSHT20SR

(Which reminds me that cl_timenudge in combination with unlagged does seem to work correctly according to g_trueping since B48, I'll edit that wiki section too.)

The unlagged code and documentation is pretty old and almost totally deprecated at the time (for example noone use cl_timenudge as it was used) and some informations are even false (cl_timenudge was limited from -30 to +30 in the standard engine of Quake 3 Arena, so there was no way to set +33 without a mod).

A high snaps can't override the server snaps, so you can set 999 and it will automatically adapt to the server's sv_fps.

Quote from: 7
Basically, sv_fps 20 gives you the (in)famous '50 ms built-in lag' (1000 ms / 20 fps = 50 ms lag); if you increase sv_fps more snapshots per second will be sent to the clients so the 'built-in lag' is reduced: sv_fps 25 will reduce the built-in lag to 40 ms and sv_fps 30 to 33 ms. Increasing sv_fps has two drawbacks: firstly, players with slow connections will get data congestion and will appear laggy to other players (which is the Geez' problem), and secondly and more importantly, the unlagged code works best at sv_fps 20.

False. This is a rough simplification of how the engine works, which ends up in a totally false statement.

sv_fps defines the number of times per second the server will update you on the whereabouts of the server and the other players. But this does NOT mean you can not act meanwhile (like shooting or killing). I explain myself (quickly and dirtily) :

With the following (optimized) settings :
* Client :
com_maxfps 125
cl_maxpackets 125
snaps 25
* Server :
sv_fps 25

Your client will send its own actions as updates (125 per second = each 8 ms). The server will then receive them, work on them, and then send back the world update to all players, but not instantly : it will wait for the next server snapshot (snap_shot s_erver = snaps) which happens, in our case, 25 times per second = 40 ms. And 25 FPS is one of the standards for videos, so it's more than enough to reproduce faithfully a player's movement.

So in the end :
- snaps and sv_fps does NOT produce lag because you can still do actions meanwhile and they are taken into account.
- a higher sv_fps to reduce the snapshots gap is meaningless, because in 50 ms the players can move only of such a few units (less than 15 in average) that it's just ridiculous to pursue more precision.

What is more important to avoid lags is to produce a constant flow without standard deviation of packets as much as possible, and this is exactly what sv_fps 25 does.

For more informations :
Mails from arQon (CPMA's main author) : http://www.cidelcorp.fr/nk/index.php?file=Sections&op=article&artid=36
A very good article explaining all this in detail (in french) : http://forum.drc.su/quake-iii-cl-maxpackets-sv-fps-and-com-maxfps-explained-vt1103.html



A summary of the "rules" of the connection settings for the ioquake3 engine :
- (Almost) everything is calculated frame by frame (see Note2).
- cl_maxPackets <= com_maxfps (see Note1).
- cl_maxPackets = com_maxfps / (ceil(com_maxfps / cl_maxPackets)) (the nearest lesser neighbour of cl_maxPackets, more explanation in the Note2 below)
- sv_fps is linked to cl_maxPackets (and to com_maxfps incidentally). com_maxfps and cl_maxPackets must be a multiple of sv_fps (and inversely).
- snaps <= sv_fps
- Precise discrete integer values : resulting operations, frames, packets and seconds can only be an integer (more details in Note2). If a wrong value is chosen (not discrete, not integer or higher than max), the nearest lesser neighbour will be selected automatically.
- Everything must be a multiple of the other.
To which we can add by deduction :
- Clients' com_maxfps rules all other parameters (this is a major con of the ioquake3 engine).

To summary, we have this chain :
1000ms >= client's com_maxFPS >= client's cl_maxPackets >= server's sv_fps >= client's snaps
(don't forget the rule : Everything must be a multiple of the other.)
We can clearly see here the links between each.

Note1: As you can see, most parameters can only be set to a lesser or equal value of another parameter. What happens if you set it higher ? Nothing, it is just set to the equal value.
Eg : com_maxfps = 125 and cl_maxPackets = 450, when you play automatically cl_maxPackets = 125

Note2: This is probably the main rule (after the "com_maxfps rules it all"). This rule tells that when you set a value, it can only take some precise discrete values based on the other parameters.
For example : we set com_maxfps = 150. What happens ? Nothing, you will get the lowest next value to 150 that results in a integer number of frames per second. Why ?
Because 150 FPS = one frame each 6.66666...(infinity) ms, which the engine considers IMPOSSIBLE (but I agree that seconds can be splitted in real life, but the engine works this way for everything). So the engine will fluctuate and often adapt your FPS to about 143 FPS (because 1000/7 = 142.9 = 143 which is the nearest lesser neighbour of 150 FPS). So in the end, setting com_maxfps = 150 is EXACTLY the same as com_maxfps = 143.

Another example : we set com_maxfps = 125. Now we set cl_maxPackets to 110. Since everything in the engine is calculated frame by frame (yes, the visuals influenciate your gameplay in ioquake3 !), this means that the engine will decide to send packets each frame (not between). So when you tell it to send 110 packets per second and at the same time that it has 125 frames per second, there is quite a dilemma !
In the end, the solution that it will find is that it will simply find the nearest lesser neighbour : sending one packet each 2 frames = 125/2 = 62.5 = 63. So to summary our example, when we set com_maxfps = 125 and cl_maxPackets = 110, we really get cl_maxPackets = 63 (one packet each 2 frames). So better choose cl_maxPackets = 125 next time ;).


Title: Re: Connection Icon
Post by: 7 on September 01, 2011, 07:20:09 AM
Yes, I oversimplified how the engine works, but no, that doesn't mean I don't know how it really works.

1) Since unmodified clients have snaps set to 20, setting sv_fps to something other than a factor of 20 is a really bad idea.

Edit:
If a client has snaps set to a value lower than the servers sv_fps, the server doesn't send it every snapshot it generates, but only ever second (or third, or even fourth), until the transmission rate is lower or equal to the one set with the clients snaps value. This means for example that when a client with snaps set to (the standard value of) 20 connects to a server with sv_fps set to 25, the server will only send every second snapshot to the client, giving it an effective rate of 12 snapshots per second. With 12 server fps effectively, the clients built-in lag becomes 1000 ms / 12 fps = 83 1/3 ms.

This means that every noob that hasn't set snaps to something greater or equal then 25 will experience 83 1/3 ms built-in lag while someone who does experiences 1000 / 25 = 40 ms built-in lag; less then half of what the noob experiences. Setting sv_fps to 30 is a little better, because 1000 / 15 fps = 66 2/3 ms built-in lag, while 1000 / 30 = 33 1/3, so in this case the noob only has double the built-in lag (as he would on a sv_fps 40 server).

2) Setting snaps to 999 on a client is crazy, because you claim to have a connection with about 1 ms ping and huge bandwidth: if a server had set sv_fps to 999 or higher also, it would send you 999 snapshots per second and flood you off the internet!

Edit:
Snaps 40 will give you the maximum snapshots per second on just about every decently configured server out there, without the risk of getting flooded.

3) With sv_fps 20 each snapshot takes 50 ms, so player prediction works over a time span of 50 ms also, and so does the unlagged skip correction. By increasing sv_fps you decrease this time span, which gives you a) less negative cl_timenudge to play with, and b) more unrailable players with phone jacks above their heads because they skip so bad.

4) Increasing sv_fps does not increase the precision of unlagged hitscan weapons, it does give better hitscan detection when you're not using unlagged.

5) Do not confuse up ArQons CPMA code with the unlagged code or sago007's accurate physics code. When you combine accurate physics and unlagged delagging, almost all of ArQons points are moot. (CPMA and unlagged take different approaches to delagging the client.)

6) I wrote most of the technical explanations on the wiki, but feel free to correct any mistakes!


Title: Re: Optimizing the connection settings of ioquake3 and openarena
Post by: Gig on September 01, 2011, 07:32:52 AM
- snaps and sv_fps does NOT produce lag because you can still do actions meanwhile and they are taken into account.
A question. The server of The Geez, despite having a huge internet connection (60/11 Mbps) had clients lagging (he saw connection icon over their head), that diminished when he lowered his sv_maxfps (that was set to the high value of 100). Exactly, how can sv_maxfps increase players lag? Is it possible that his enormous bandwidth ended? Even with the rate at 25000, with 11 Mbps of upload in theory he should be able to support something like 50 clients...
I suppose that, if a high sv_maxfps sends more data to the clients, that should not exceed "sv_maxrate" and "rate" values anyway (else, what would "rate" do?), and thus less important data would be discarded... maybe the problem could be that too much data is discarded?
PS: TheGeez did not mention his sv_maxrate value.


Title: Re: Optimizing the connection settings of ioquake3 and openarena
Post by: 7 on September 01, 2011, 07:59:17 AM
Exactly, how can sv_maxfps increase players lag? Is it possible that his enormous bandwidth ended? Even with the rate at 25000, with 11 Mbps of upload in theory he should be able to support something like 50 clients...

It increases the players lag by sending them more packets per second, which means more bytes per second over the line and more data per second to process for the client.

Quote from: Gig
I suppose that, if a high sv_maxfps sends more data to the clients, that should not exceed "sv_maxrate" and "rate" values anyway (else, what would "rate" do?), and thus less important data would be discarded... maybe the problem could be that too much data is discarded?

The sv_maxrate limits how much bytes per second can be sent to a client, but not how much packets per second (that's what sv_fps on the server and snaps on the client are for). Cheap hardware (and wireless networks) have problems processing high packet rates and start lagging. Also, because of transport overhead (UDP headers, ethernet frames and such) it takes more bandwidth to send 2 UDP packets containing 1 byte of data then it takes to send 1 UDP packet containing 2 bytes of data.

Edit:
The players get the 'phone jacks lag' above their heads because they start skipping. A client needs to send at least one packet containing player information to the server after receiving a snapshot but before receiving the next snapshot. If a players client doesn't manage to send an update of the players position, the player will have the same position in two snapshots, followed by the actual position in the next snapshot, so to other players the player seems to skip from the position in the first snapshot to the position in the third snapshot.

(So basically, someone can make his client skip by setting cl_maxpackets to a value lower than the number of snaps he receives per second).


Title: Re: Connection Icon
Post by: sago007 on September 01, 2011, 08:24:52 AM
For networking cl_maxPackages is likely the biggest limit. If the snaps are small they may be packaged in a single package. Also a wireless access points that are configured from max speed (all?) will group packages together for higher throughput, so raising cl_maxPackages have little or no effect in most cases, because they will be joined on another network layer.


Title: Re: Connection Icon
Post by: Gig on September 01, 2011, 08:57:28 AM
For the moment, I've done DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Manual%2FMultiplayer&action=historysubmit&diff=8912&oldid=8910]this little change (http://([b) in the "Multiplayer" page, but it is better that you guys do the appropriate corrections to the "Tweak" page, and add a section about how to calculate server network settings in the "Multiplayer" page (maybe when you reach a common opinion)... I fear it's out of my reachings...


Title: Re: Optimizing the connection settings of ioquake3 and openarena
Post by: GrosBedo on September 01, 2011, 03:07:30 PM
- snaps and sv_fps does NOT produce lag because you can still do actions meanwhile and they are taken into account.
A question. The server of The Geez, despite having a huge internet connection (60/11 Mbps) had clients lagging (he saw connection icon over their head), that diminished when he lowered his sv_maxfps (that was set to the high value of 100). Exactly, how can sv_maxfps increase players lag? Is it possible that his enormous bandwidth ended? Even with the rate at 25000, with 11 Mbps of upload in theory he should be able to support something like 50 clients...
I suppose that, if a high sv_maxfps sends more data to the clients, that should not exceed "sv_maxrate" and "rate" values anyway (else, what would "rate" do?), and thus less important data would be discarded... maybe the problem could be that too much data is discarded?
PS: TheGeez did not mention his sv_maxrate value.

This is an interesting question which can be answered by several different manners according to my theories :

- sv_fps too high for connection to handle : the sv_fps is so high that the server's AND client's connections are too slow to handle. Indeed, in the case of a fast server and a slow client, the client will have some hard time playing if it can't manage the sv_fps because (as you said) it will have to discard snapshots, but here you have 2 possible cases :

* the client has a high snaps. In this case, the client will skip and have jerking movements because it will have flunctuating, unstable flow of data.

* the client has a low snaps. Here, the client will get a constant flow of snapshots adapted to its connection, but it will have to interpolate, and I think that the interpolation between constantly missing snaps is not very good (indeed, the network optimization code was made considering that the client gets regularly the server's snapshots, if it misses 1 snapshot on 2 (or even 3 or 4 ...) then the interpolation may be very bad because the loss is as regular as the packets received !).

Overall, I think that in this case the client should set a low snaps. Better get a constant loss than an unstable flow.

- Highly unstable flow, very high standard deviation : the sv_fps is not a multiple of the client's com_maxfps, which produces a highly unstable flow (very high standard deviation).
I will take the example of The Geez :
Considering that sv_fps = 100, we will hypothetize here that most players will have set com_maxfps = 125 and snaps = 100.
This means that the client gets 100 snapshots per second, but have to process them 125 times per second. As you can imagine, this is very complicated. In other words, this is what will probably happen :
frame 1: process snapshot 1
frame 2: nothing
frame 3: process snapshot 2
frame 4: process snapshot 3
frame 5: nothing
frame 6: process snapshot 4
frame 7: nothing
frame 8: process snapshot 5
frame 9: process snapshot 6
and so on...

And this is in the case that players have snaps = 100 ! If they have snaps = 20, you can divide by 5 :

frame 1: process snapshot 1
frame 2: nothing
frame 3: nothing
frame 4: nothing
frame 5: process snapshot 2
frame 6: nothing
frame 7: nothing
frame 8: process snapshot 3
frame 9: nothing
and so on...

As you can see, it's highly unstable, because the engine has to interpolate sometimes between 5 snapshots, sometimes 4, sometimes 7, sometimes more or less... The other problem is that players are no more synchronized, because while player1 process snapshot 2 at frame 5, another player2 can process snapshot 2 at frame 7, and so on... Resulting in lags for everyone.

This problem is particularly vicious as it hit everyone, even clients with a very fast connection.

See : http://www.urbanterror.info/forums/topic/19188-suggestion-wierd-behavior-of-the-engine-snapss-perhaps-important/page__p__244181#entry244181

- sv_fps is higher than client's com_maxfps. This is the worst case, as the client is always behind the train.
Example of The Geez :

sv_fps = 100 and client's com_maxfps = 85 (default new player's value) and snaps = 85

The maths are simple here. Even if snaps would really be set at 85 (in real it would be converted to the nearest lesser neighbour of 85 which is a multiple of 100 = 50), the client would get only 85 snapshots per second. Where are the last 11 snapshots ? The client's engine doesn't even know about them, because it expects to get a maximum of 85 snapshots since it is limited by com_maxfps = 85 (datas get processed only by frames, not in between).

So here you always lose 15 snapshots without even knowing it. No doubt that the player will suffer from lags. Anyway the other players with a higher fps will not suffer from this problem.

---

The key here is the stability of the connection.
The problem here and in most cases of servers lags is NOT the speed of the connection, nor the number of snapshots and packets, but the standard deviation from a constant flow. We all know that lags is a direct result of an unstable flow of packets, so servers (and clients) should be configured with a goal of stability and NOT a goal of high performance. So instead of setting a very high value, the best is to set a low value that would fit most players.

This is why I (and the guys at urbanterror) propose sv_fps 25 because com_maxfps = 125 is the most popular setting for FPS. If it was different, then another setting for sv_fps should be used.

sv_fps = 100 is a very bad idea which, as I demonstrated, can only produce an unstable flow of packets (=> lags).

These theories would explain why, by lowering the sv_fps value, in any of these cases it would reduce the problem by reducing the connection burden/standard deviation/surplus of frames lost.

Basically, you can try 2 things to test my theories :
- server's set sv_fps = 125 and your clients com_maxfps = 125, cl_maxPackets = 125 and snaps = 125. Everything should be fine (unless your connection really has a problem and is too slow, but that should not be the case as I can read your specs).
- set your server's sv_fps to another multiple of 125 : 63, 42, 32, 25 (the best being 125 and 25 as these two values are not rounded up). sv_fps = 5 should be very stable too but a little too small value :p.

Anyway, I add my voice to those advising to connect directly to the ADSL and not use Wireless, because most wireless connections will drop packets and they not necessarily ensure a stable connection and latency since they can (as sago007 pointed out) package the packets, and send them later (which makes no difference when you download a big movie, but makes a lot of difference when hosting a game server).



@7
I agree with almost everything you said, none of this contradicts what I explained. Anyway, I notice that you don't take account of the cl_maxpackets in your schema, which is very important and explains why, even if indeed you receive one snapshot each 50 ms, it is not really a lag since your actions are acknowledged, and because it is a constant delay which is unnoticeable.

About the snaps = 999, I agree but the server would implose way before the client ;) So not even one server would have the audacity to set such a ridiculous amount. I advised this value because it would then adapt to any other sv_fps value, but indeed a more reasonable value would be 125 (same as your fps) for example, which makes much more sense since it would respect the scheme :
1000ms >= client's com_maxFPS >= client's cl_maxPackets >= server's sv_fps >= client's snaps

1000ms >= 125 >= 125 >= 125 >= 125

So in the end, just set the same value for everyone of these parameters and you should be ok ;)

Changing sv_fps from 20 to 25 gives not only the benefice of lowering the server's snapshots delay from 50ms to 40ms, the main aspect is that it gives a solid 0 standard deviation for clients with com_maxfps = 125 (or a multiple). This means that you drop not even 1 packet, no irregular interpolation to fix losses, nothing : the connection is really stable. See (again) for demonstration :
http://www.urbanterror.info/forums/topic/19188-suggestion-wierd-behavior-of-the-engine-snapss-perhaps-important/page__p__244181#entry244181

But I agree that changing sv_fps to 25 instead of the default 20 is dangerous because of the new players with default settings, but the argument does not reside in changing sv_fps or not but changing the default connection parameters in OpenArena at first launch. Indeed, if we had to configure servers depending on new players' parameters, we would have to set very low parameters (ie: maxrate, sv_fps), so in the end, we would have very slow performances. I'd rather adopt an attitude of pedagogy, optimizing the servers parameters, and teaching new players about how to edit them (you have /players, /serverstatus and automatic chat messages with third party tools to do help you in this task - /players and /serverstatus helps to determine the players with a very low maxrate or maxpackets, and some mods like ExcessivePlus help to go further). But things evolved a bit since last OA version and the first-time connection wizard.

This is a great step forward, but we need to go further, and snaps 20 is definately a BAD value since you can NOT set a multiple of 20 for com_maxfps, so you necessarily end up with an unstable connection with this setting.

About the rest, no I don't confuse arQon CPMA's network code with unlagged and with sago's work, I was talking about the standard way Quake 3 Arena engine was working (almost all the network codes were made for this engine, not for ioquake3, CPMA/unlagged/ExcessivePlus included). But sago's work is the most promising of course ;)

About the 4th point, this is a sideeffect that was noticed by a lot of players during the league because of the sv_fps 25, and unlagged was enabled. But after all, there was no foolproof demonstration. But one could compare the hits ratio of a server with sv_fps 20 and another with sv_fps 25 to try to investigate this issue.

And congrats to you 7 and Gig for the server's administration wiki, you guys did a remarkable job.

/Edit:

I think that the best way to update this whole system would be to no more reason in terms of number of packets or snapshots, but in term of frames (since everything is ruled by frames here), and so the variables should be ruled this way.

Example : instead of snaps = 25, we would have snaps = 1 for 1 snapshot per frame, or snaps = 2 for 1 snapshot each 2 frames.
instead of cl_maxPackets = 125 we would have cl_maxPackets = 1 for 1 packet per frame, or cl_maxPackets = 2 for one packet each 2 frames.
etc. for the other parameters that are constrained the same fashion.

This nomenclatura would avoid any confusion.


Title: Re: Connection Icon
Post by: 7 on September 01, 2011, 04:14:53 PM
A few remarks.

1) Interpolation is what happens between two snapshots so interpolation is always dead on, extrapolation (prediction) is what happens when the client doesn't get the next snapshot in time. A little extrapolation (up until 20 ms or so) isn't a problem either, because the prediction errors within this small frame of time are very small also (not even the fastest airstrafer/rockerjumper deviates much from his predicted path within 20 ms).

2) The urban terror measurements are done while running the server and the client on the same host, IOW under ideal conditions. As sago already pointed out, real networks are not ideal and do fragment, reassemble and group packets, not to mention the unstable and asymmetric routing paths, the network congestion and the packet loss, which all disturb/influence the arrival times of the packets sent over the network.

3) Not every player has hardware that pulls 125 fps and not every player that does own a real 3d card has com_maxfps set to 125, specially when it doesn't give you any advantage in jumping height anymore when sago's physics is enabled on the server. (What you now need most is stable fps on the client, specially if you're using mouse acceleration).

4) Again, the urban terror guys assume extrapolation is a bad thing and try to avoid it at any cost by tuning every network parameter as to let every packet reach the clients running like a clockwork in the almighty 125 fps rhythm, but this is impossible in practice and consequentially a large portion of the network code was actually written to deal with this situation (even more so if unlagged is enabled).

5) It's only natural that hitscan weapons score more frags on servers where some sort of delagging code 'magically' does away with the built-in lag so you don' t have to lead hitscan weapons anymore and can aim dead on target. This is in large part the reason why there's so much whining and weapon rebalancing going on in QL (which users ArQons delagging code) and also part of the reason why they changed the hitboxes to hit-cylinders. So definitely yes, enabling the unlagged code makes hitscan weapons stronger on internet servers, as a matter of fact it makes them at least just as strong as they are in regular zero-ping situations (ie on LAN or localhost).


Title: Re: Connection Icon
Post by: Cacatoes on September 02, 2011, 03:14:23 AM
Didn't read all this, but:
- I run @60fps ; I think I enabled vsync. Couldn't reach 125fps at all time with my computer.
- pmove_float=1 by default on new servers, consider this. If you don't agree with this new way to handle physics, then explain why 125 etc etc is better, otherwise investigating more about "the old way" is some kind of a waste.


Title: Re: Optimizing the connection settings of ioquake3 and openarena
Post by: GrosBedo on September 02, 2011, 09:21:21 AM
@7
1/ I never implied that interpolation was disabled at a moment or another, it's always on, but I'm pretty sure that the algorithm was made with occasionnal loss in mind, not regular loss due to a faulty engine processing. Here the problem is not just the loss of packets, it's the total droping due to the engine not processing them altogether, which is kind of a different problem. Luckily we are to have a good interpolation algorithm which support a problem it was not addressed in the first place, else we would have much more problems !

2/ "The world is bad so let's all be bad" argument. You are saying that because networks are not perfect, we should not even try to fix some known and proved gaps ? Stupid argument. You are basically stating that optimizing is useless.

3/ I think that you misunderstood what I said. More on that later on in my reply to Cacatoes.

4/ Same as 2. Interpolation is a great technology, but it, as its name implies, interpolate from what it knows, so this produces a simulation. The goal of every game server administrator is to reduce this marge of simulation.
If you can't agree, as you did here, I'm sure that you will be completely happy by playing with snaps = 5 and a maximum of interpolation.

[joke]And yes, Extrapolation is EVIL :
The Lurking Dangers of Extrapolation : http://www.youtube.com/watch?v=CZlwdXVYNaU&feature=related
[/joke]

5/ Do you think I'm stupid ? Everyone knows that. As I explained before, a synchronized sv_fps with client's com_maxfps seems to help the hitscan to be more precise, and this was particularly tested WITH unlagged (and yes, I know the unlagged technology the problem it produced for the community by "overpowering" [which I don't agree] hitscan weapons). So here, I'm talking about a different thing than what people are used to. Else, why the hell would I lose my time posting common sense and deja-vu ?

Anyway, as I underlined the "seems", I must point out that this is an assumption based solely on observations, but was not demonstrated technically (yet) so this is not something over which I will argue the existence or not, I just point out the potential existence based on quite a few reports from players.

----

Fallacy, fallacy, fallacy... I think we must be misunderstanding each other, because you are not at all talking about the same subject as me, mainly floating and repeating common sense and logical assumptions. 7, you are trying to argue with me, though I can't see what you are arguing. Everything I have written was demonstrated, I just summarized all these informations here, but you are free to check out the links (or other, this is not exhaustive) on the net. I mean you know how the engine works, you told so, so what the heck ? Where's the debate ?

What I am saying is that I'm not here to participate to inexistent debates, I'm not kind a fan of that type of hobby. I'm spending enough time on writing my knowledge just for the sake of opensourceness.

Anyway, I think that I understood why you are debating, and this reside not in the way the engine work, but mainly on my proposition. I will clarify that just below in my reply to Cacatoes.

Didn't read all this, but:
- I run @60fps ; I think I enabled vsync. Couldn't reach 125fps at all time with my computer.
- pmove_float=1 by default on new servers, consider this. If you don't agree with this new way to handle physics, then explain why 125 etc etc is better, otherwise investigating more about "the old way" is some kind of a waste.

I already adressed your point in my previous posts, but maybe this is a little too obfuscated by the mass of informations so I will clarify here.

In my previous posts, I have written 2 different things : a (rough) description of how the engine handle the network datas, and a personnal idea of an all-terrain network config for the dummy who doesn't read a bit. I think that the latter is what is confusing you people, so let me clarify a bit.

These settings are only a personnal idea on the question, this is not the end-of-it-all (because the real solution would be a revamping of the whole engine).

Here is a full detailing on how I have made up these settings.

These settings were made with the following assumptions :

1- sv_fps and com_maxfps are linked and com_maxfps should be a multiple of sv_fps to be optimally stable (in theory).
2- Most players have either com_maxfps = 125 or the default com_maxfps = 85 (really 84 or 83 because of the rule of the nearest lesser integer neighbour, see the previous long post).
3- sv_fps must not be too high to be stable and usable for most/all types of modern connections.
4- There are more players than servers administrators.
5- Hope that mentalities will change about snaps (or a next update of OA will change the default value of snaps).
6- The default snaps and sv_fps value of 20 is not stable neither for com_maxfps = 125 neither for com_maxfps = 85.

-> Considering point 4, I think that servers administrators should adapt to the players base.

-> Following point 2 and 1, one should choose a multiple of 125 or 85, ideally the GCD of both. Unluckily, the GCD = 5, which is too low, and if you take the real FPS into account, you get the GCD of 125 and 84 = 1. So you have to choose.

-> Hoping for point 5 to concretize, one should choose to keep com_maxfps = 125 since it's the most popular among not new players. We can then get some ideas of the potential sv_fps : 1, 5, 25 (there are other values like 18, 21, 32, 42, 63, ... but they are unstable, they are rounded up).

-> Following point 3 : we choose either 5 or 25. 5 is way too low, so we take 25.

-> Result : we get sv_fps = 25

I must point out again that this was made following my own assumptions and decisions. You can do your own and get a totally different result just by changing one assumption (for example by ignoring point 4, you can try to force the player base to adapt to your server's settings and make them changing their config).

---

To come back to your question Cacatoes

- yes, since you run at 60 FPS (for real you run at 59/58 FPS), yes these settings aren't optimal (that's why I noted com_maxfps = 125 !), but the basic setting is the same : you should set snaps = cl_maxPackets =  com_maxFPS. These three settings should be the exact same for every player, and that would be the optimal setting for players.

Here, we are NOT talking about optimal settings for players, but optimal settings for servers, and particularly one : sv_fps. Only incidentally, it is connected to clients settings.

- we are not talking about physics and gravity nor the advantage of com_maxFPS = 125. We are talking about how to optimize the network settings for a server (and incidentally the clients). As I explained above in a previous post, the management of the network datas is processed per frame, and so com_maxFPS rules how your network is managed. The value of 125 is just a dummy value because it's popular as I explained above.

But as you point out, there is a correlation in high jumping and a good network setting : you jump higher because you process more frames stably, and if you process more stably, your network data will be more stable too. To find a good value, just calculate 1000/x where x is any integer you want. The values you will get will be generally (not always) the best ones to jump higher (and probably to get a good network flow). Here is a quick list :
1000, 500, 333, 250, 200, 167, 143, 125, 111, 100, 91, 83, 77, 71, 67, 63, 59, 56, 53, 50, 48, 45, 43, 42, 40, etc...

I edited my previous post to avoid confusion on the blue highlighted phrase



Now some more elements I would like to highlight.

- Public sv_fps
First, a major problem of sv_fps is that by default it is NOT considered to be a public variable. This is particularly a problem because you have no way to know the sv_fps of a server (and so you can't know what is the exact value you should set as snaps).

A way to circumvent that is to use sets instead of set, like this :
sets sv_fps 25

This will show your sv_fps as a server detail in the dpmaster (or when you do /serverstatus).

To go further you can even add snaps :
sets sv_fps 25
sets snaps 25
sets set_your_snaps_to 25

Note: snaps is useless for a server, it will just show it as a public detail to guide the players.

- A value that fits all : sv_fps = 21

Secondly, as I demonstrated in a previous post, the default value of sv_fps = 20 is totally useless. Why ? Because you can do much better just by setting sv_fps = 21.

Demonstration :
com_maxFPS / sv_fps

-> If com_maxFPS = 85
85/20 = 4.25
85/21 = 4.05
85/25 = 3.4

-> If com_maxFPS = 125
125/20 = 6.25
125/21 = 5.95
125/25 = 5

As you can see, even if sv_fps = 25 is the optimum setting for players with com_maxFPS = 125, it is not at all for players with com_maxFPS = 85, and the default sv_fps = 20 is better for them.

But, we can notice that sv_fps = 21 is a good compromise that is better for both com_maxFPS values, without attaining optimum for any. We can clearly see that the standard deviation (not calculated here but it is pretty clear, look the numbers after the comma) is much less in both cases.

In the end, it is obvious that it would be a good optimization to change the default value of sv_fps and snaps to 21. It would benefit to most (almost all) players without any drawback.

- Final word

Of course, the best solution would be the recode the network part of the engine so that it gets processed completely independantly from the FPS system, but this would require quite a good amount of work.

Meanwhile, changing the default value of sv_fps and snaps, making sv_fps public by default to guide players, as well as changing the behaviour of some other network settings (cl_maxPackets = 1 for 1 packet per frame, = 2 for 1 packet per 2 frames, etc...) are easy and quick fixs to make things better without to much reworking.


Title: Re: Connection Icon
Post by: Cacatoes on September 02, 2011, 10:59:34 AM
My mistake, but I was thinking when pmove_float was set to 1 we could just totally ignore that com_maxfps question.
If it remains a parameter which has an impact on network, then it has to be considered, of course.

What about something like:
- some synchronization being automatically made between sv_fps and com_maxfps
- com_maxfps would be restricted to multiples of sv_fps (made public)
- com_desiredmaxfps would be set by players according to his/her hardware and personnal preferences
- com_maxfps would be set to the nearest value of com_desiredmaxfps
- com_ignoremaxfps could be set to 1 to leave the engine work @ com_desiredmaxfps

?


Title: Re: Connection Icon
Post by: 7 on September 02, 2011, 03:33:28 PM
1) The network code was written with structural loss in mind (it was written for 56K modems). Whenever a snapshot arrives too late, it has to be dropped by the client, precisely because it is late and holds a game state that has already passed. Again: there is nothing faulty about the client dropping snapshots when the snapshots arrive late, the code does that on purpose because the late snapshots are useless.

2) Again: Carmack and the other coders at Id were very much aware that clients would have to drop late snapshots, that's why they not only put in code to interpolate the game state between a newly arrived snapshot that's on time and the previous snapshot, but also code to extrapolate (predict) the game state from that previous snapshot if the new snapshot doesn't arrive on time (and has to be dropped when it finally arrives).

4) I think you're simply unaware of the extrapolation/prediction capabilities of the code and are being led astray by the UrT-forum guys.

Interpolation and extrapolation is actually essential, because it decouples the client's fps from the server's snapshot rate. If there was no interpolation between snapshots (or extrapolation if a snapshot is tardy), the client could only render the game state stored in the snapshots as they arrive, so if there was no interpolation, clients playing on a sv_fps 25 server would all run 25 fps, no more, no less.

You simply have to interpolate or extrapolate from your game state data if the server sends it at a (sv_fps) rate of between 20 and 40 times per second, but you want to recalculate the game state 125 (com_maxfps) times per second on the client.

Please reread the above two paragraphs and allow them to really sink in. Do you now understand why it's a little absurd to claim there is a coupling between the client's fps and the server's fps, when Id has been investing enormous amounts of time, money and coding genius into decoupling them ever since the QuakeWorld days? Exactly because client and server fps are not coupled you can achieve high frame rates on the client and still play over the internet.

5) I misunderstood you, if you really think the unlagged code works better at sv_fps 25 (while the coder who wrote it doesn't), we really should do some statistics ;)

Edit:
What this all comes down to, is that if there is a fractional part (numbers behind the dot) after dividing com_maxfps by sv_fps (as you do in your demonstration), the client will have to structurally extrapolate because the relation between the server fps and the client fps is such that there will always be a few snapshots arriving late and not just because of lag. This is what he UrT guys are measuring and get all worked up about, but I can assure you that the code was written being aware of this and this isn't a problem at all.

So what the UrT guys are attempting without realizing it, is to work around this structural extrapolation by tuning the relation between server fps and the client fps. It never comes to them that the people who wrote the code are actually high-level software engineers who damn well know what they're doing and do a lot of testing and performance measuring on their products also.


Title: Re: Optimizing the connection settings of ioquake3 and openarena
Post by: Gig on September 03, 2011, 03:31:03 AM
- Public sv_fps
First, a major problem of sv_fps is that by default it is NOT considered to be a public variable. This is particularly a problem because you have no way to know the sv_fps of a server (and so you can't know what is the exact value you should set as snaps).

A way to circumvent that is to use sets instead of set, like this :
sets sv_fps 25

This will show your sv_fps as a server detail in the dpmaster (or when you do /serverstatus).

To go further you can even add snaps :
sets sv_fps 25
sets snaps 25
sets set_your_snaps_to 25

Note: snaps is useless for a server, it will just show it as a public detail to guide the players.

This is, IMHO, an important point, that I pointed out a couple of times before.
Allowing players to know about more server settings would be useful not only to effectively allow them to configure their network settings for best experience on that server, but also to know which options/features are being used or not (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Special_game_options]e.g. (http://([b) catchup, vampire mode, awardpushing, delag hitscan, kind of physics) .

I think a partial solution could be to make more "space" available for "sets" variables (that isn't very much, considering how long a single variable could be), but then you should encourage in some way server admins to actually use them!

Probably it would be better to use this community to decide which variables should automatically be considered "public" and then add a new client-side command that queries the server for that specific informations (I suppose using a completely new command instead of changing the init string should not break compatibily with third party stuff -meaning that maybe they expect for a maximum init string lenght?-, even if would mean that dpmaster and other tools would not read those values unless such tools will be updated by their authors. I don't know, decide yourself.).
But let's talk about that in a specific thread:
http://openarena.ws/board/index.php?topic=4245.0

At the moment, in theory server admins could use the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Message_of_the_day]message of the day (http://([b) to inform users about some server settings, but it would be quite intrusive and would still rely on admins' good will.


Title: Re: Connection Icon
Post by: GrosBedo on September 03, 2011, 07:28:19 PM
@7
Inter/extrapolation is necessary, but no it is not optimal, and no Im convinced Carmack and ID guys were not aware of all the consequences. They may be high level software engineers, but this all was done in the 90's. More details follow.

I did not underestimate the usefulness/necessity to interpolate/extrapolate. But lets get back in time. At the time, ID Software s guys made the choice to use the band new interpolation/extrapolation technology to fix the problem of the synchronization of the network. But this was done a long time ago, when ADSL was very rare, 56K/28K modems ruled the Internet world, and the web technologies were just beginning to be developped. Since, there have been many changes and technological evolutions, particularly in the area of web and server/client transactions. Luckily we now have technologies like the unlagged mod, cpma 100ms hack, sago's updates and ExcessivePlus progressive full unlag are different approach to evolve this old network code. But they all are mods (except sago's updates) based on the existing network code, and so they can't fix inherent flaws, they can only propose some workarounds.

What I am saying is that now there are many new much better way to deal with the challenges of the transactions than ever before, and so the interpolation/extrapolation model isn't the end of it all. Extrapolating is good, but synchronization is good too, and both should be pursued when you try to get an efficient network code.

To make an analogy, it's just like trying to drive a car alongside a train at the exact same speed. You have 2 ways : either you run alongside and try to jauge your own speed, sometimes running faster, sometimes slower, but in the end you get at the destination at the same time ; either you just attach your car to the train and you are sure to run at the exact same speed and not even needing to make any adjustments.

Im not saying inter/extrapolation is unnecessary here, in some other applications it can be, but here for a 3D network game we need this technology. But one should not only rely on simulating the data if one can achieve a better synchronization. Less we have to rely on inter/extrapolation, better it is for the gameplay, don't you agree ?

About Carmack and the ID guys being aware of it all, I am pretty convinced of the contrary. Why ?
- First, because it is an old engine and what is made now is not what was made at this time.
- Secondly, because if they knew the flaws their FPS-oriented engine had (like jumping higher with some specific framerates, and the standard deviation of the packets flow), they would have fixed them (what they did in their subsequent games if Im not mistaken).
- Third, because the default values they chose for these important parameters (com_maxFPS and sv_fps) are TOTALLY random (at least not based on consideration about the way the engine work, which is pretty confusing from the guys who made it).
- Fourth, because com_maxFPS impact on the whole engine and sv_fps usage is pretty poorly documented, and the documentation is not even from the dev team but by independant guys.

Which brings me to another point : the interpolation and extrapolation mechanism is not optimally designed, because it was designed to overcome unsynchronized network transactions due to transport, not due to the engine (un)processing.

Making a metaphor with a mail fetching : let's say your postman always comes the Monday, Wednesday, Thursday, Friday and Sunday. You then have 2 ways of proceeding :

- If you don't know the days of the week when the postman comes, you can adopt a general method, like "I check the mail each 2 days". This will give you pretty good results, as you will have mails ASAP the Monday, Wednesday, Friday and Sunday. But, the mail received Thursday will be fetched only Friday with this approach. So there is 1 day when you  will not get the mail as soon as it is posted.

- If you study the days when the postman comes, you can conclude that there are exactly 5 days when he comes, and so you can check and fetch your mail exactly at these days. This is a more optimized approach but necessitate that you study your postman's habits.

Here it's the same : knowing the flaw of the engine, the inter/extrapolation could be enhanced a lot.

Lastly, such an optimization may not seem much for us players with high broadband and stable connections with overpowered computers and playing in optimal situations. But Im pretty sure this can make a lot of difference when you have an unstable connection.

---

In the end, I don't see any argument against the values sv_fps = 25/21, you don't seem to object to their optimality as opposed to 20.

You are saying that this is not a big enhancement. I say who cares ? It's a very small change and it can only be better, so where's the dilemma ?

Plus, you saw how much devastating a bad setting of sv_fps can lead (this is the subject of this thread!), so it kind of prove that it's a very sensible parameter.



@Cacatoes
I don't know about these ideas, I do feel that this would be another workaround and this is not where the efforts should be focused on.

I mean, I think that the way the FPS are ruling the other parts of the engine is really not a good idea and should be reworked altogether to be fully independant (in summary, propagating the same changes done to the physics engine to the whole engine), but this is a great deal of work and may be not as efficient in the end in term of time and functionnalities than to migrate directly to another game engine (like the soon-to-be-released id tech 4 ?).

Anyway on second thought, I do agree for a way to synchronize sv_fps and com_maxfps (and why not synchronize snaps and cl_maxpackets automatically ?). But then this would mean that the server's administrator would impose his own preferences over the players. But I think that indeed, if it can enhance the gameplay for everybody, I can't see anyone objecting against a way to better synchronize all players.

I think that :
1- client's settings should be simplified and better default settings should be chosen.
2- the clients should be synchronized to the server (via framerate ? a multiple of course or another way).

We could imagine too that the server could even have the power to enforce the client's network settings, but this could be very dangerous if the servers administrators are inexperienced.

Anyway meanwhile, I still propose the simple change of the default sv_fps and snaps values from 20 to 21, this would fit everyone until a better solution is found.



@Gig
I didn't see your thread before, thank you for pointing out, I will post a reply there.


Title: Re: Connection Icon
Post by: 7 on September 04, 2011, 02:15:56 AM
Come on GrosBedo, I just explained that interpolation and extrapolation is technically the only way to have clients run at higher frame rates than the server.

Basically the server sends the clients a 'photo' ('snapshot') of the situation on the server every 50ms, so the clients know where all the players are at 0ms, 50ms, 100ms, 150ms etc. If a client wants to render a frame 25ms into the game it has to find out where everything is at 25ms, so it has to take an 'average' of the 0ms and 50ms 'photos' the server sent it. Taking this 'average' is what's called interpolation, and if you don't interpolate, you can only render frames at the same rate the server sends them. If you change the time between the 'photos' to 40ms by setting sv_fps to 25, the client has to interpolate just as well.

Also note that the server can only send 'photos' (snapshots) of things that have already happened, which means that what the clients see on their monitors is always behind what's going on at the server. This delay is the infamous 'built-in' lag of one 'photo' (so in the case of sv_fps 20 the built-in lag is 50ms).

Sometimes the server is a few ms late sending a 'photo' to the clients, which means the clients can't interpolate, IOW they can't take an 'average' of the new 'photo' and the previous 'photo' to find out where everything is because the new 'photo' hasn't arrived yet. To solve this problem, Id wrote (lots of) code that tries to predict where everything is by extrapolating the positions of all the stuff recorded in previous 'photos'.

This is not an inherent flaw in the network code but exactly how the network code is supposed to work.



To make an analogy, Carmack designed a motor engine that runs perfectly well on low-octane fuel, but you and the UrT guys insist you have to tank high-octane fuel because the engine doesn't run right on low-octane fuel, when the engine is behaving perfectly as expected (the UrT guys just don't understand this).



By the way, the default network parameters are not chosen totally at random, but to make 56K modems run right. It's a very bad idea to set up a server that runs badly with these default parameters, because just about everybody trying out the game for the first time will run it with these default parameters and will have a sh*tty experience on your server (because their built-in lag will skyrocket if they've got snaps 20 on a sv_fps 25 server, as I already explained). So basically such a server is like bad advertising for the game to any noob out there, who thinks he's going to get a great gaming experience by connecting to a 'pro-server' but gets an extra bad one.

Edit:
As for sv_fps 21 being 'more optimal' then sv_fps 20: the closer towards 1 the fractional part of com_maxfps / sv_fps is, the more structural extrapolation there will be going on, so com_maxfps 125 and sv_fps 21 is just about as 'bad' as it's going to get, because 125 / 21 = 5.952380952, and 0.952380952 is awfully close to 1.

Also, just take step back and objectively judge what you're trying to accomplish: you're trying to give the 125 fps players who already have an unfair advantage by being able to jump higher than other players, another advantage by tuning the network parameters so they have the least possible extrapolation going on, to the detriment of the other players who'll get more. The practical new advantage that you're giving the 125 fps players by this is that they'll be able to use (a little) lower negative cl_timenudge values than the other players while having the same amount of prediction errors.


Title: Re: Connection Icon
Post by: GrosBedo on September 04, 2011, 08:12:31 AM
Ok let's get straight to the point because our blind discussion begin to look ridiculous.

The mechanism of extra/interpolation does not nullify the need to synchronize a network.

Quote from: 7
Also note that the server can only send 'photos' (snapshots) of things that have already happened, which means that what the clients see on their monitors is always behind what's going on at the server. This delay is the infamous 'built-in' lag of one 'photo' (so in the case of sv_fps 20 the built-in lag is 50ms).

Already said here :
Quote from: GrosBedo
Your client will send its own actions as updates (125 per second = each 8 ms). The server will then receive them, work on them, and then send back the world update to all players, but not instantly : it will wait for the next server snapshot (snap_shot s_erver = snaps) which happens, in our case, 25 times per second = 40 ms.
But I repeat to make it clear : you are forgetting the client's packets (cl_maxPackets is not just an eye candy setting). The clients still interact with the server, even when the server is not interacting with them.
And I still strongly disagree with this very misleading term of "built-in lag", it's like saying there is a real lag included in the engine when it is not like a lag at all, it's a completely different thing managed completely differently and doesn't result in a impact to the gameplay of the players.

Quote from: 7
This is not an inherent flaw in the network code but exactly how the network code is supposed to work.
It is, because the network code was designed to compensate for an unsynchronized network because of the nature of the network, not because the engine simply doesn't process the frames. I can't see any modern server application processing data packets at a constant framerate, if so, please show me one.

Quote from: 7
To make an analogy, Carmack designed a motor engine that runs perfectly well on low-octane fuel, but you and the UrT guys insist you have to tank high-octane fuel because the engine doesn't run right on low-octane fuel, when the engine is behaving perfectly as expected (the UrT guys just don't understand this).
This analogy is out of place, noone ever told you to put sv_fps = 125, on the contrary.

Quote from: 7
By the way, the default network parameters are not chosen totally at random, but to make 56K modems run right.

Ah, because setting sv_fps and snaps to 21 instead of 20 is really better to 56K modems ? 1 framerate can kill it all ?

And I will reveal you something : 56K modems are dead since long, so I think that we can all move on from this limiting perspective.

Quote from: 7
because just about everybody trying out the game for the first time will run it with these default parameters and will have a sh*tty experience on your server (because their built-in lag will skyrocket if they've got snaps 20 on a sv_fps 25 server, as I already explained).

Are you stupid or what ? If we change the default value of snaps and sv_fps, where's the dilemma ? Anyway, even with snaps 20 on a server with sv_fps = 21 or 25, it should make really no difference to a new player.

Quote from: 7
As for sv_fps 21 being 'more optimal' then sv_fps 20: the closer towards 1 the fractional part of com_maxfps / sv_fps is, the more structural extrapolation there will be going on, so com_maxfps 125 and sv_fps 21 is just about as 'bad' as it's going to get, because 125 / 21 = 5.952380952, and 0.952380952 is awfully close to 1.

LULWHAT ?
In common mathematics, what you are stating is absurd. Closer it is to integer values, less interpolation there needs to be. Couldn't be more obvious I think.

Quote from: 7
you're trying to give the 125 fps players who already have an unfair advantage by being able to jump higher than other players, another advantage (... and) use (a little) lower negative cl_timenudge values than the other players while having the same amount of prediction errors.

1- noone use cl_timenudge anymore, you are a dinosaur.

2- there's no more advantage to 125 fps than any other FPS now thank's to sago's changes on the physics engine.

3- sv_fps set to 21 profits to almost everyone, even players with the default com_maxfps = 85 (don't you want new players to get a better gameplay?)

4- the engine works the same for everyone. What I said adapt to everyone. Please demonstrate me how this rule is not optimum for everyone: snaps = cl_maxPackets = com_maxFPS

5- I'm promoting a better understanding of sv_fps and its interaction with other settings, because there are way too many mistakes made with it (common ones being sv_fps set at 30 or 100!).

6- there is nothing against tweaking sv_fps and snaps values. Noone ever before this technical demonstration by UrT guys really tried to tweak this setting. Even in the unlagged faq, they are just stating that setting too high values for sv_fps is bad, but they are not demonstrating why sv_fps 20 is better than 21 or 25 or any other value.

7- Unlagged is nice, but it doesn't work for : projectile weapons (at least in this implementation), movements, other game's events (flag capture, domination, etc.). So I think that a better synchronization would be quite a good idea here.



/Edit

More on the unlagged stuff :

Quote
If you miss a snapshot, where you see other players will not be correct. Exactly what kind of “not correct” isn't necessarily important. It's that the server, not able to know which snapshots you got and which you didn't, will assume you got them all, and do all of your hit tests accordingly. What the server thinks you saw and what you really saw will not be the same thing.

(...)

Receiving snapshots late can cause problems as well. Your client has to keep drawing stuff while it hasn't received an update from the server, and it figures out where to put things by guessing (extrapolating, actually). Sometimes the guesses aren't quite right, and again, what the server thinks you saw and what you really saw will not be the same thing.
from: http://ra.is/unlagged/faq.html#IJRAMBIHOIJRAHBIM

In another passage :

Quote
These kinds of conditions are simply not good for consistency (because it means the things his game was rendering didn't match up with what the server thought it rendered).
from: http://ra.is/unlagged/faq.html#DUGHPTA

A keyword here seems to be consistency. Even unlagged, with its impressive prediction capabilities, can't fix all the network problems. I am not saying that tweaking sv_fps would be the end of it all, but it demonstrate the need to synchronize clients and servers as well as possible, even with interpolation/extrapolation/prediction mechanism.

---

More on their entry about sv_fps:
Quote
(Setting a higher sv_fps) does have some detrimental effects:
(...)
* Higher pings (it seems the client engine holds onto snapshots a little longer)
Everyone now knows that it is only an illusion, you don't get a higher ping because you raise sv_fps (unless you get some data congestion as you said or a very wrong unsynchronized value).
Quote
* Other players may be “jerkier” since more samples mean less smoothing in general
Really ? Because having more samples makes an interpolation or prediction less effective ? That's the first time I hear that.
Quote
The new skip correction becomes less effective
Note: for an explanation on what is skip correction, please read http://ra.is/unlagged/faq.html#WSC

This one is an interesting point. They don't really explain why, but I think it's pretty obvious. "Skippers" (players who need skip correction) are obviously players who have some bad, inconsistent connection, and as such they are skippin

/Edit2
No in fact, I can't see the reason why they say it would be less effective. Even if there are more servers frames, the skipping algorithm would still function as it was intended if implemented well.


Title: Re: Connection Icon
Post by: 7 on September 04, 2011, 09:27:49 AM
The mechanism of extra/interpolation does not nullify the need to synchronize a network.

Then type in \g_synchronousClients 1 on the console and see if that works better, GrosBedo!

Quote
But I repeat to make it clear : you are forgetting the client's packets (cl_maxPackets is not just an eye candy setting). The clients still interact with the server, even when the server is not interacting with them.

cl_maxpackets determines how much packets the client will send to the server and doesn't influence the amount of  interpolation versus extrapolation in the least. The only thing you can really screw up with cl_maxpackets is setting it to a value lower than the servers sv_fps, because this will make the client have 'phone jack lag'. For the rest lower cl_maxpackets values just make your movement and aim less accurate because they get transmitted to the server less frequently (but that's not really relevant to this discussion)

Quote
It is, because the network code was designed to compensate for an unsynchronized network because of the nature of the network, not because the engine simply doesn't process the frames. I can't see any modern server application processing data packets at a constant framerate, if so, please show me one.

Nooooo. The client fps is decoupled from the server fps because the network is too slow, not because it's asynchronous.

Just about every multiplayer game out there functions with a discrete heartbeat, not just the IdTech engines.

Quote
Ah, because setting sv_fps and snaps to 21 instead of 20 is really better to 56K modems ? 1 framerate can kill it all ?

And I will reveal you something : 56K modems are dead since long, so I think that we can all move on from this limiting perspective.

So now its not the 'inherently faulty network code' but the wrong default parameters? Make up your mind.

Quote
Are you stupid or what ? If we change the default value of snaps and sv_fps, where's the dilemma ? Anyway, even with snaps 20 on a server with sv_fps = 21 or 25, it should make really no difference to a new player.

No I' m not stupid and yes it makes a difference GrosBedo, because snaps sets the maximum amount of snapshots the client is prepared to receive and process, so if sv_fps > snaps the server will send it every second snap. Because the delay between the received snaps determines the built-in lag, on a sv_fps 21 server the new player will get 100ms built-in lag instead of 47ms, and on the sv_fps 25 server he'll get 83ms built-in lag instead of 40ms.

Quote
In common mathematics, what you are stating is absurd. Closer it is to integer values, less interpolation there needs to be. Couldn't be more obvious I think.

When you divide com_maxfps by sv_fps, you calculate how many frames the client renders for every server snapshot it receives, agreed? This means also that the fractional part indicates how little of the last client frame overshoots the server snaps, which indicates how much too late the server snapshot will arrive on the client. If the snapshot is very late, it will be late often...

Quote
1- noone use cl_timenudge anymore, you are a dinosaur.

Not everyone that takes a different approach to playing the game from yours is automatically stupid...

Quote
2- there's no more advantage to 125 fps than any other FPS now thank's to sago's changes on the physics engine.

Exactly, so why are you so hellbent on synchronizing the whole shebang to 125 fps?  Seems to me you're the dino, GrosBedo.

Quote
4- the engine works the same for everyone. What I said adapt to everyone. Please demonstrate me how this rule is not optimum for everyone: snaps = cl_maxPackets = com_maxFPS

When are you finally going to get in into your head that not everyone has got enough hardware and bandwidth to do this? Specially snaps 125 is totally insane (or do you expect sv_fps 125 servers?)

Quote
6- there is nothing against tweaking sv_fps and snaps values. Noone ever before this technical demonstration by UrT guys really tried to tweak this setting. Even in the unlagged faq, they are just stating that setting too high values for sv_fps is bad, but they are not demonstrating why sv_fps 20 is better than 21 or 25 or any other value.

Right, that's what I've been demonstrating. I've explained twice now why its a bad idea, but you just go on and on and on about the UrT guys. Have you ever wondered why no real developer ever reacted to those guys on their forum? (Hint: it's because they don't understand inner workings of the engine and draw the wrong conclusions from their measurements.)

Quote
7- Unlagged is nice, but it doesn't work for : projectile weapons (at least in this implementation), movements, other game's events (flag capture, domination, etc.). So I think that a better synchronization would be quite a good idea here.

Exactly, you need cl_timenudge for that, because negative timenudge decreases the built-in lag by processing snapshots earlier (and doing more extrapolation).

Edit:
Clarified the cl_maxpackets and the com_maxfps / sv_fps fractional part pieces.


Title: Re: Connection Icon
Post by: GrosBedo on September 04, 2011, 11:14:34 AM
Then type in \g_synchronousClients 1 on the console and see if that works better, GrosBedo!

Good point :) But if I am not mistaken, the goal of g_synchronousClients is to synchronize clients between them.

But by synchronization, I meant that each clients should be synchronized with the server as much as possible, but independantly, according to their own schedule.

I am clearly aware that we are here talking about an asynchroneous type of server/client transactions. The problem here, is that the server process these in a few discrete states only. If a different approach would have been adopted avoiding these discrete steps, we would not meet the "built-in lag" as you call it.

Quote from: 7
Quote
But I repeat to make it clear : you are forgetting the client's packets (cl_maxPackets is not just an eye candy setting). The clients still interact with the server, even when the server is not interacting with them.

cl_maxpackets determines how much packets the client will send to the server and doesn't influence the amount of  interpolation versus extrapolation in the least. The only thing you can screw up with cl_maxpackets is setting it to a value lower than the servers sv_fps, because this will make the client have 'phone jack lag'.

This was in response to the "built-in lag" statement, I was not talking about interpolation. A lag is a delay in the processing of the network data because of a congestion. This is not the case, and in plus it's too bold to say that it's 50 ms, this would mean that the player's client stops any transaction with the server during this time, which is plainly false. You get updated each 50 ms, but your actions are registered each 8 ms as I demonstrated earlier, so this is not a simple "built-in 50 ms lag delay".

Quote from: 7
Nooooo. The client fps is decoupled from the server fps because the network is too slow, not because it's asynchronous.

Just about every multiplayer game out there functions with a discrete heartbeat, not just the IdTech engines.

Um, if I get to understand rightly what you are trying to say, I think that we just told the same thing. The network code needed to be asynchroneous because of the needs. A gaming application is not the same as a business calendar for example. Anyway nowadays, synchroneous and asynchroneous applications doesn't mean much, now every modern network technologies tend to be both at the same time, bringing the best of both worlds.

Anyway, you say that the client fps can't be coupled with server fps ? That's already the case, clients receive exactly the same number of packets from the server than sv_fps, and server receive exactly the same number of packets from the clients than their com_maxfps (assuming they have cl_maxpackets >= com_maxFPS and snaps >= sv_fps).

In other words :
- server is coupled to the client
- client is coupled to the server
- but both coupling are not at the same rate

There are indeed facilities for slow connections by tweaking these settings so that you send one packet each x frames, but still I maintain that even if the network code is asynchroneous, it was designed to be coupled as much as possible in a bidirectionnal transaction. If this was note the case, snaps and cl_maxPackets should work a lot different than what they are now by processing packets in an ineven interval of frames (not each 2 frames for example but each 1.5 frames etc.).

The network code is not fully asynchroneous. That's the problem.

Quote from: 7
Quote
Ah, because setting sv_fps and snaps to 21 instead of 20 is really better to 56K modems ? 1 framerate can kill it all ?

So now its not the 'inherently faulty network code' but the wrong default parameters? Make up your mind.

It's both. Faulty network code, and default settings that aren't making things better. The latter being much more easy to fix than the first.

Quote from: 7
Quote
Are you stupid or what ? If we change the default value of snaps and sv_fps, where's the dilemma ? Anyway, even with snaps 20 on a server with sv_fps = 21 or 25, it should make really no difference to a new player.

No I' m not stupid and yes it makes a difference GrosBedo, because snaps sets the maximum amount of snapshots the client is prepared to receive and process, so if sv_fps > snaps the server will send it every second snap. Because the delay between the received snaps determines the built-in lag, on a sv_fps 21 server the new player will get 100ms built-in lag instead of 47ms, and on the sv_fps 25 server he'll get 83ms built-in lag instead of 40ms.

I repeat myself: imagine that we change the default settings for the next release of OpenArena, so that every new player will get snaps = 21 and sv_fps = 21, where's the problem?

I am aware of the problem in setting these values in a current environment, so that's why the choice is to be left to the administrator of the server, but we are talking about future change now, detached of current implications. You are making politics here, and I'm talking about ideal settings. People don't always adopt good ideas, but that's another problem, the problem is not in the idea.

Quote from: 7
Quote
In common mathematics, what you are stating is absurd. Closer it is to integer values, less interpolation there needs to be. Couldn't be more obvious I think.

When you divide com_maxfps by sv_fps, you calculate how many frames the client renders for every server snapshot it receives, agreed? This means also that the fractional part indicates how much of the last client frame overshoots the server snapshot, in other words how much of the server snapshot arrives late on the client...

You summarised well my approach. But I don't agree with your point of view, I think that the server will render full frames and not semi frames, though you're making me doubt now.

/Thinking more about this.../

Quote from: 7
Quote
1- noone use cl_timenudge anymore, you are a dinosaur.

Not everyone that takes a different approach to playing the game from yours is automatically stupid...

No I did not say you were stupid because of that, you can play whatever way you want (who would be mad enough to tell you otherwise?). It's just that this setting has be abandonned since long now with the unlagged code and cg_projectileNudge, and because of the problems in prediction it brought.

What I mean anyway is that this setting is not the point here : cl_timeNudge is a workaround for latency, when here I talk about an optimization of the consistency.

Quote from: 7
Quote
2- there's no more advantage to 125 fps than any other FPS now thank's to sago's changes on the physics engine.

Exactly, so why are you so hellbent on synchronizing the whole shebang to 125 fps?  Seems to me you're the dino, GrosBedo.

I'm not, I told already told to Cacatoes that these settings were not optimal with com_maxFPS = 60.

125 fps is the most common setting for advanced users (not the elite, just advanced), with 85 for new players. I already explained that this was an assumption I used for my decisions, my advices are not to be confused with the statements I made about the engine optimization.

To summary, I state :
snaps = cl_maxPackets = com_maxFPS
and all the rules in a previous post

I advise :
sv_fps = 21 if you want everyone to be happy
sv_fps = 25 if you want advanced users to be happy (and use sets, motd and/or console messages to warn users about this setting)

Quote from: 7
Quote
4- the engine works the same for everyone. What I said adapt to everyone. Please demonstrate me how this rule is not optimum for everyone: snaps = cl_maxPackets = com_maxFPS

When are you finally going to get in into your head that not everyone has got enough hardware and bandwidth to do this? Specially snaps 125 is totally insane (or do you expect sv_fps 125 servers?)

snaps 125 is insane ? First, I doubt any server will set this value, it would crash before the client would even lag. Secondly, 125 packets per second is already what the client send with cl_maxPackets = 125, if a client can upload this much, it can download at least the same.

Anyway, snaps = com_maxFPS is an easy way to:
- get the maximum snaps from a server (snaps will adapt to the server, you can't receive more than the server sends you)
- not receive more snaps than your number of FPS
- theoretically not overflow your network (people usually tends to have much more download bandwidth than upload)

A big sv_fps is only a problem for the server because it defines the number of packets it will have to send to every players, and so it relies on the upload bandwidth. That's why sv_fps must be low, for the server to handle everything. On the other hand, a big snaps is not a problem for the client because it relies on the download bandwidth and probably has way too much download bandwidth to spare.

Quote from: 7
Quote
6- there is nothing against tweaking sv_fps and snaps values. Noone ever before this technical demonstration by UrT guys really tried to tweak this setting. Even in the unlagged faq, they are just stating that setting too high values for sv_fps is bad, but they are not demonstrating why sv_fps 20 is better than 21 or 25 or any other value.

Right, that's what I've been demonstrating. I've explained twice now why its a bad idea, but you just go on and on and on about the UrT guys. Have you ever wondered why no real developer ever reacted to those guys on their forum? (Hint: it's because they don't understand inner workings of the engine and draw the wrong conclusions from their measurements.)

No, you did not demonstrate anything. You only linked to the unlagged documentation which is not itself demonstrating anything (at least about sv_fps). The rest is argumentation, and argumenting the usefulness is not demonstrating.

The UrT guys did several technical demonstrations with a concrete and evaluable result. I don't care if the pop or my 8-year-old neighbour did that, as long as it follows the scientific method, it is worth investigating for me.

Quote from: 7
Quote
7- Unlagged is nice, but it doesn't work for : projectile weapons (at least in this implementation), movements, other game's events (flag capture, domination, etc.). So I think that a better synchronization would be quite a good idea here.

Exactly, you need cl_timenudge for that, because negative timenudge decreases the built-in lag by processing snapshots earlier (and doing more extrapolation).

No you don't, as you said, you have interpolation/extrapolation/prediction/lag compensation. And I do think that a better prediction is better than an earlier snapshot. Several studies on the human brain proved that consistency is what matters most, it can easily accomodate lag (even important lags) as long as it is consistent.


Title: Re: Connection Icon
Post by: 7 on September 04, 2011, 01:46:49 PM
Our posts have crossed because I was reediting my previous post, but anyway:
Good point :) But if I am not mistaken, the goal of g_synchronousClients is to synchronize clients between them.

But by synchronization, I meant that each clients should be synchronized with the server as much as possible, but independantly, according to their own schedule.

The point is that the server has only one clock, so by synchronizing each client to the server individually, they'll be all synchronized amongst each other too.

Quote
If a different approach would have been adopted avoiding these discrete steps, we would not meet the "built-in lag" as you call it.

The problem is not the discrete steps but the amount of prediction that has to be done when you completely do away with built-in lag: you'll have to extrapolate every client frame and hence the players will have lots of screen glitches because the constant extrapolation predicts fast players positions wrongly.

Quote
This was in response to the "built-in lag" statement, I was not talking about interpolation. A lag is a delay in the processing of the network data because of a congestion. This is not the case, and in plus it's too bold to say that it's 50 ms, this would mean that the player's client stops any transaction with the server during this time, which is plainly false. You get updated each 50 ms, but your actions are registered each 8 ms as I demonstrated earlier, so this is not a simple "built-in 50 ms lag delay".

The point is that what you see on your monitor has a built-in delay, so whatever you're reacting too has already happened at least 50ms ago on the server.

Quote
Um, if I get to understand rightly what you are trying to say, I think that we just told the same thing. The network code needed to be asynchroneous because of the needs. A gaming application is not the same as a business calendar for example. Anyway nowadays, synchroneous and asynchroneous applications doesn't mean much, now every modern network technologies tend to be both at the same time, bringing the best of both worlds.

The point is that the network, with even nowadays typical roundtrip times (pings) of about 35ms, is much slower that the average graphics card, which can easily produce a frame each 8ms (=125 fps). Synchronizing these 8ms events over a 35ms line would inevitably involve waiting, which to players is simply lag.

Quote
Anyway, you say that the client fps can't be coupled with server fps ? That's already the case, clients receive exactly the same number of packets from the server than sv_fps, and server receive exactly the same number of packets from the clients than their com_maxfps (assuming they have cl_maxpackets >= com_maxFPS and snaps >= sv_fps).

When server fps and client fps would be coupled, this would mean that changing sv_fps on the server would influence com_maxfps on the clients, or that changing com_maxfps on a client would influence sv_fps on the server, or both. This is clearly not the case, so the settings are totally independent of one another.

Quote
If this was note the case, snaps and cl_maxPackets should work a lot different than what they are now by processing packets in an ineven interval of frames (not each 2 frames for example but each 1.5 frames etc.).

That the engine can't send a packet in between frames is because the duration of a frame is the atomic amount of time for the engine. This has more to do with the engine being built and running as a single thread: basically the whole engine runs in one big loop, so if something can't be done every pass trough the loop it has to be done every second pass (and if that's still to fast every third pass, etc.).

Quote
I repeat myself: imagine that we change the default settings for the next release of OpenArena, so that every new player will get snaps = 21 and sv_fps = 21, where's the problem?

For one, all the the noobs installing it from an old linux repo would still have problems, and secondly fromhell seems to be targeting low-end hardware with OA3, so I don' t know if it's a good idea to set defaults which are more demanding on the hardware or the network connection. Thirdly and most importantly, it has worked like a charm for more then 10 years with sv_fps 20, so why change?

Quote
You summarised well my approach. But I don't agree with your point of view, I think that the server will render full frames and not semi frames, though you're making me doubt now.

:) It doesn't render half-frames, that's exactly the problem. The client engine hast to render a full frame every X ms, so if the timestamp of the last snapshot is in the past and a new snapshot hasn't arrived yet, it has to render a full frame without the necessary data to interpolate, so it has to extrapolate.

Quote
No I did not say you were stupid because of that, you can play whatever way you want (who would be mad enough to tell you otherwise?). It's just that this setting has be abandonned since long now with the unlagged code and cg_projectileNudge, and because of the problems in prediction it brought.

:) Well the OA players abandoned cl_timenudge in part because of my writings on the wiki. There was a bug in 0.85 where timenudge and unlagged didn't work well together because g_trueping didn't show the amount of timenudging a client did as it should. However this now works perfectly at least since oaxB48, so there is no more reason to not use a little timenudging (-15 max).

The QL players abandoned cl_timenudge because ArQon's delagging code doesn't work well with timenudging and never will, ArQons 'laghax' is basically a server assisted timenudge so when you use manual timenudging you're doing double timenudging and are deep in the woods.

Quote
What I mean anyway is that this setting is not the point here : cl_timeNudge is a workaround for latency, when here I talk about an optimization of the consistency.

What timenudge really does is force the engine to drop old snapshots sooner (negative values) or later (positive values), which in turn forces the engine to process new snapshots sooner (negative values) or allows the engine to linger longer on old snapshots (positive values). So yes it's a workaround for latency, but what it really does is to decrease the built-in lag at the expense of doing more extrapolation by simply processing the snapshots sooner.

Quote
I'm not, I told already told to Cacatoes that these settings were not optimal with com_maxFPS = 60.

Yeah, but we can't really force players to use the com_maxfps we as server admins would like now, can we? Combine this with fromhell aiming at low-end hardware, and we should probably optimize for com_maxfps 62 ;)

Quote
To summary, I state :
snaps = cl_maxPackets = com_maxFPS
and all the rules in a previous post

And I would advise nearly any cable/dsl player to set snaps to 40 and cl_maxpackets to 150. There aren't going to be servers with sv_fps > 40 anytime soon, and with cl_maxpackets 150 you'll always put out more than 100 packets per second to the server independent of your com_maxfps setting (assuming its faster than 91), which should be accurate enough for even the most sensitive mouse handed and trigger fingered player.

Quote
I advise :
sv_fps = 21 if you want everyone to be happy
sv_fps = 25 if you want advanced users to be happy (and use sets, motd and/or console messages to warn users about this setting)

I advise:
leave sv_fps at 20 and spare yourself and us all the trouble.

Quote
snaps 125 is insane ? First, I doubt any server will set this value, it would crash before the client would even lag. Secondly, 125 packets per second is already what the client send with cl_maxPackets = 125, if a client can upload this much, it can download at least the same.

They put the snaps cvar in the engine so a client can avoid getting flooded by a server with too high sv_fps for the clients connection, right? So what use does the snaps cvar have if you advise players to set it to a value that almost certainly will get them flooded, should they ever connect to a server configured by a madman? (Remember that the snapshots a server sends to the clients contains much more data than the packets a client sends to the server, so the clients sending the smaller packets faster isn't much of a bandwidth problem.)

Quote
Anyway, snaps = com_maxFPS is an easy way to:

Get yourself flooded off the internet by every H4x0rb0i who decides to set up a malicious OA server and lure you on to it?

Quote
No, you did not demonstrate anything. You only linked to the unlagged documentation which is not itself demonstrating anything (at least about sv_fps). The rest is argumentation, and argumenting the usefulness is not demonstrating.

I demonstrated that what the network code does if com_maxfps is not a multiple of sv_fps is not a bug or an oversight from the coders, because they put lines and lines of code in to deal with just this situation. (I can show you the code if you insist.)

Edit:
On second thought I can do even better, because Id built a display of the interpolation and extrapolation process of client frames into the lagometer: interpolated frames are blue lines on the lagometer, extrapolated frames are yellow lines and the length of these lines represents the time in ms from the most recent snapshot the client is interpolating/extrapolating. (The length of the green lines represents the delay in ms with which the snapshots arrive on the client, IOW the clients lag.)

What the UrT guys are whining about, is the tiny, nearly invisible yellow dots you see on the lagometer with com_maxfps 125 on a sv_fps 20 server with good ping!

To see what cl_timenudge does, watch what happens to the number of yellow lines and to the length of both the yellow and blue lines with different positive and negative timenudge values.

Quote
The UrT guys did several technical demonstrations with a concrete and evaluable result. I don't care if the pop or my 8-year-old neighbour did that, as long as it follows the scientific method, it is worth investigating for me.

Well scientifically speaking, experimentation is done to confirm or falsify an existing theory and not blindly. What the UrT guys did was attaching lost of clocks and meters to the engine without a consistent theory of what they were going to measure and what this would prove or disprove. Hence the measurements are perfect, but their conclusions as to what causes these results simply stink.

Edit:
Added the lagometer story.


Title: Re: Connection Icon
Post by: Graion Dilach on September 05, 2011, 06:32:56 AM
I have nothing to add to this lag story but I noticed GrosBedo thinks nobody uses 56K nowadays. I guess he either lives in West Europe or in America to think this because what I know, this isn't entirely true. I have an Indonesian friend, who just shown me his tests of Speedometer on the other day (0.09/0.07 Mbpses) which after the calculations, turns into a 128K conn.... and Speedometer said it's slower than ~60%, which means that the remaining ~40% also uses a 128K or worse. (And those who doubts his conn being that bad, I can clearly tell you that he has plenty issues of Red Alert 2 multiplayer because his network speed isn't enough for lagfree gaming, not even 1v1 while my 1 Mbps (which halfly get used by my brother's YouTubing and FBing) still works like a charm).

What am I trying to imply... that no matter what do you expect... the third world still uses extinct technology because they have no money to invest it into better.


Title: Re: Connection Icon
Post by: Gig on September 08, 2011, 03:13:56 PM
After all that discussions, do you think we can do something of these?

I'm not sure about the best sv_fps value, anyway our DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]server config example (http://([b) uses 25.

@7, for the moment, I did DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Tweak&action=historysubmit&diff=8901&oldid=8726]this change (http://([b) (fix it if needed), but I'd like to write something more complete to DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Multiplayer]this page (http://([b) (where I added DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Manual%2FMultiplayer&action=historysubmit&diff=8910&oldid=8907]this (http://([b) in the meanwhile), and I would appreciate your help.
I think we should cover:
- How to calculate how many players are supported starting from a certain upload bandwidth (including how to convert from Mbps to kBps), at maximum rate (25000) and at another rate, and to what sv_maxrate one should not go under.
- How to do the inverse calculation (how one should set sv_maxrate to support the needed number of players).
- Remember to the user to set sv_maxclients taking in account the calculations above.
- That sv_maxrate should be set to 25000 to have VoIP feature working correctly.
- Difference with "kilo" and "kibi" etc. measures, saying that bandwidth is expressed in SI decimal prefixes (see Wikipedia (http://en.wikipedia.org/wiki/Binary_prefix#Data_transmission_and_clock_rates)), explaining that's why we divide by 1000 instead of 1024.
- Some words about sv_minrate, too?
- Anything else you think would be useful for a server admin to know about bandwidth management.

In the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]server config example (http://([b), I would simply add how many players are supported for each MBps of upload bandwith, in the line about sv_maxrate, at 25000.



Title: Re: Connection Icon
Post by: 7 on September 08, 2011, 11:54:09 PM
I'll have a look at it tomorrow, I thought it better to weather the storm before we start an edit war on the wiki. I won't touch the configuration examples but I'll stick to the technical explanations and calculations instead and leave it to the server admins to decide what works best amongst themselves. Don't worry, I already checked the sv_maxrate calculation you added and its A-OK.


Title: Re: Connection Icon
Post by: Gig on September 09, 2011, 12:54:58 AM
I'll have a look at it tomorrow, I thought it better to weather the storm before we start an edit war on the wiki. I won't touch the configuration examples but I'll stick to the technical explanations and calculations instead and leave it to the server admins to decide what works best amongst themselves. Don't worry, I already checked the sv_maxrate calculation you added and its A-OK.

Well, the controversial points were about best fps and packets values, right? Bandwidth calculation wasn't a problem between you and GrosBedo, or I remember wrong?


Title: Re: Connection Icon
Post by: 7 on September 09, 2011, 01:21:24 AM
Right, what I meant is I'm not going change the values in the example configs. GrosBedo and I don't disagree about what snaps and cl_maxpackets values are right for a certain connection (there is a little more disagreement about sv_fps in relation to com_maxfps).

We generally disagree about what values you should set in an example config: GrosBedo wants values that give real gamers with expensive gear and good internet connections the best gaming experience, while I'm for values that give (almost) all people a reasonable gaming experience regardless of how good their hardware is (and explain how to tune the values for the real gamers). As a matter of fact that's my main concern with sv_fps too, so I'm not going to touch those issues because I think its more of a community thing: all of us should decide what's better together, not just GrosBedo or I.

Also, I'm not very familiar with the voip stuff so I can't really write much about it.


Title: Re: Connection Icon
Post by: Gig on September 09, 2011, 05:35:54 AM
Also, I'm not very familiar with the voip stuff so I can't really write much about it.
Also I tested it only once, when I wrote the (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Voice_chat page. I followed the instructions on the ioquake voip readme (these, at the time (http://svn.icculus.org/quake3/trunk/voip-readme.txt?revision=1640&view=markup)). I tested running both dedicated server and client on my computer (with no other players than me, but after setting everything following the instructions, the volume meter appeared when I talked in the microphone)....
Anyway, the wrote about the need to use high "rate" reading (from the readme linked above) this sentence: <<The game will refuse to enable VoIP support if your have your network settings lower than "Cable/xDSL/LAN", just in case.>>


OT: I suppose I should point out to someone (Sago? Fromhell?) of a change that ioquake3 guys did recently to a voip variable... maybe there may be need to tune something in OA... Developers, please check here: http://svn.icculus.org/quake3/trunk/voip-readme.txt?r1=1640&r2=2102


Title: Re: Connection Icon
Post by: sago007 on September 09, 2011, 08:36:11 AM
OT: I suppose I should point out to someone (Sago? Fromhell?) of a change that ioquake3 guys did recently to a voip variable... maybe there may be need to tune something in OA... Developers, please check here: http://svn.icculus.org/quake3/trunk/voip-readme.txt?r1=1640&r2=2102
Openarena bt defaylt sets cl_voipSendTarget to the list of players on your team. I don't remember if spartial or all are used in free-for-all.


Title: Re: Connection Icon
Post by: Gig on September 09, 2011, 11:02:59 AM
Openarena bt defaylt sets cl_voipSendTarget to the list of players on your team. I don't remember if spartial or all are used in free-for-all.
It seems "spatial" has been added (and set to new default) recently (at least, they updated that help file a little more than one month ago. I don't know when they changed the actual code!).

I don't understand why they did a such thing: it seems to me quite strange, in a game like this (where players have to roam always running in a large arena) to allow people to hear others only when they are near each other... I would not have set that as default! A feature like the one introduced by OpenArena (speaking to your team-mates) seems to me much more useful than that (I don't understand why they did not implement it by themself).

If you can, I would suggest to allow the new value in OA, but to keep "all" as default (but if it would mean that you will have to manually change it each time you import updated code from ioquake3, keep the same of theirs).


Title: Re: Connection Icon
Post by: sago007 on September 09, 2011, 11:12:58 AM
(I don't understand why they did not implement it by themself).
Because the engine does not know about teams. It can take a guess by assuming that the mod author has not changed the client struct.


Title: Re: Connection Icon
Post by: 7 on September 11, 2011, 06:56:32 AM
I've added a DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Bandwidth]Bandwidth (http://([b) section to the wiki Servers page. I've made it as easy as I can, is this ok?


Title: Re: Connection Icon
Post by: Gig on September 11, 2011, 05:44:04 PM
Very good, thank you! :-)

There are a couple of things I want to ask you... but tomorrow. Going to bed. Bye!


Title: Re: Connection Icon
Post by: Gig on September 12, 2011, 11:48:22 AM
Great formulas. Also good idea the one about efficiency. :) Good job, 7!

Now, the questions:
- I'm unsure about the VoIP part you wrote. You wrote "If you intend to enable the servers VoIP features you should add 2 kB/s so the practical minimum bandwidth per player for a VoIP enabled server becomes 7 kB/s", and ioquake3 voip readme (http://svn.icculus.org/quake3/trunk/voip-readme.txt?revision=1640&view=markup) says that each client uses about 2 kB/s for VoIP data when speaking, and server has to broadcast it to other users (so 2 * number of users that should ear the message).... so your "7kB * players" indication may seem good... but they also say that "The game will refuse to enable VoIP support if your have your network settings lower than "Cable/xDSL/LAN", just in case."... Doesn't this mean that with a rate <25000, VoIP would not work at all? In this case, talking about 7 kB would have no sense. Note: they do not specify if they are referring to network settings for client, for server, or for both! We should do some tests... EDIT: I just did a rapid test creating a fake server, and the client shows the volume meter when I press the right key not counting if I set rate or sv_maxrate to 5000 only (server is dedicated 2 and sv_lanforcerate is 0)... but, accordingly to what I previously wrote to that "Optimize for LAN" section (see here below), rate limit is ignored when connecting from the same machine, and I have only one computer here... someone else should do the test! My test doesn't count!

- sv_lanforcepackets ? I thought it was sv_lanforcerate. And from a previous thread (probably this one (http://openarena.ws/board/index.php?topic=3919.msg35286#msg35286)), time ago I summarized it into DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Multiplayer#Optimize_for_LAN]Optimize for LAN (http://([b) section... and it seems to mean that with a "dedicated 2" server, lan force rate does not work, regardless of how you set its variable (unless you are connecting from the same machine, in that case it should work even if you disable it).

- Between the "minimum" of 5kB/s and the maximum of 25kB/sec, there is great difference... Can some server admins around here suggest a value between them that they think gives a good player experience? In practice, what rate values (approx) do server admins really use?

- About bandwidth, I think once I red something about why it was possibile to use sv_maxrate and sv_minrate to keep users experience as aligned as possible, to prevent fast-connection users from causing slow-connection users to lag. But I don't remember exactly what they said (and I don't remember if it was on this forum, or anywhere else on internet!)... do you have any opinion about this?


Title: Re: Connection Icon
Post by: 7 on September 12, 2011, 12:26:04 PM
Doesn't this mean that with a rate <25000, VoIP would not work at all? In this case, talking about 7 kB would have no sense. Note: they do not specify if they are referring to network settings for client, for server, or for both! We should do some tests...

The voip-redame.txt is in the OA source also, I've read it. What they mean is you can't enable VoIP on the client if the client has a low rate setting, while the 2kB/s story is meant for server admins.


Quote
- sv_lanforcepackets ? I thought it was sv_lanforcerate. And from a previous thread (probably this one (http://openarena.ws/board/index.php?topic=3919.msg35286#msg35286)), time ago I summarized it into DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Multiplayer#Optimize_for_LAN]Optimize for LAN (http://([b) section... and it seems to mean that with a "dedicated 2" server, lan force rate does not work, regardless of how you set its variable.

You're right, its sv_lanforcerate, my mistake. The text I wrote still holds though, it's a bad idea to have it set to 1 if you're running an internet server from behind a NAT/router, even if the 25kB/s rate cap is mandatory for public internet servers.

Quote
- Between the "minimum" of 5kB/s and the maximum of 25kB/sec, there is great difference... Can some server admins around here suggest a value between them that they think gives a good player experience? In practice, what rate values (approx) do server admins really use?

In practice you give the players as high rate as possible (that's why I added the efficiency example), only if you're setting up a server for hi-pingers you should probably optimize for lower rates.

Quote
- About bandwidth, I think once I red something about why it was possibile to use sv_maxrate and sv_minrate to keep users experience as aligned as possible, to prevent fast-connection users from causing slow-connection users to lag. But I don't remember exactly what they said (and I don't remember if it was on this forum, or anywhere else on internet!)... do you have any opinion about this?

The lag part is what happens when you don't set a sv_maxrate while allowing more players on the server than the servers bandwidth is capable of hosting at maximum rate. Because the players with the good connections will accept packets from the server quicker than the players with the bad connections, the network will prefer sending packets to them so the players with the slow connections will lag. I always set sv_minrate to 5000 to enforce a reasonable minimum rate.


Title: Re: Connection Icon
Post by: Gig on September 12, 2011, 12:38:32 PM
Doesn't this mean that with a rate <25000, VoIP would not work at all? In this case, talking about 7 kB would have no sense. Note: they do not specify if they are referring to network settings for client, for server, or for both! We should do some tests...

The voip-redame.txt is in the OA source also, I've read it. What they mean is you can't enable VoIP on the client if the client has a low rate setting, while the 2kB/s story is meant for server admins.
Then, it should be clearer...

Quote
Quote
- sv_lanforcepackets ? I thought it was sv_lanforcerate. And from a previous thread (probably this one (http://openarena.ws/board/index.php?topic=3919.msg35286#msg35286)), time ago I summarized it into DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Multiplayer#Optimize_for_LAN]Optimize for LAN (http://([b) section... and it seems to mean that with a "dedicated 2" server, lan force rate does not work, regardless of how you set its variable.

You're right, its sv_lanforcerate, my mistake. The text I wrote still holds though, it's a bad idea to have it set to 1 if you're running an internet server from behind a NAT/router, even if the 25kB/s rate cap is mandatory for public internet servers.
Uh? It may affect only "hidden" internet servers (dedicated 1, not published on master server) behind a NAT, that I suppose should be a quite rare case (not the NAT, but the hidden internet server)... I think we should mention this in some way, because a standard dedicated 2 server does not need to change it from its default. Something like "If you are running an internet-accessible server behind a NAT/router, but not published on master server listings (not using "dedicated 2" mode), you should set it to 0; else, you can leave it to 1."

Quote
Quote
- About bandwidth, I think once I red something about why it was possibile to use sv_maxrate and sv_minrate to keep users experience as aligned as possible, to prevent fast-connection users from causing slow-connection users to lag. But I don't remember exactly what they said (and I don't remember if it was on this forum, or anywhere else on internet!)... do you have any opinion about this?

The lag part is what happens when you don't set a sv_maxrate while allowing more players on the server than the servers bandwidth is capable of hosting at maximum rate. Because the players with the good connections will accept packets from the server quicker than the players with the bad connections, the network will prefer sending packets to them so the players with the slow connections will lag. I always set sv_minrate to 5000 to enforce a reasonable minimum rate.
Do you wanna write two words about this there?


Title: Re: Connection Icon
Post by: 7 on September 12, 2011, 12:58:10 PM
Then, it should be clearer...

The client has a nice user interface with "Cable/xDSL/LAN" in the network settings,  the server doesn't ;)

Quote
Uh? It may affect only "hidden" internet servers (dedicated 1, not published on master server) behind a NAT, that I suppose should be a quite rare case (not the NAT, but the hidden internet server)... I think we should mention this in some way, because a standard dedicated 2 server does not need to change it from its default. Something like "If you are running an internet-accessible server behind a NAT/router, but not published on master server listings (not using "dedicated 2" mode), you should set it to 0; else, you can leave it to 1."

There is no way to find out how many private servers there are out there, but I for one run one so there is at least one... Feel free to change any text I wrote on the wiki, I wouldn't write on a wiki if I thought no one ought to change my contributions. If I think the changes are incorrect I'll open a discussion on the wiki.

Quote
Do you wanna write two words about this there?

Will do tonight.


Title: Re: Connection Icon
Post by: Gig on September 19, 2011, 11:22:22 AM
HI 7... then, if you have the availablity to do it, could you please make the test to see what happens to VoIP when server or client set rate < 25000, but connecting from the internet instead of locally as I could only test?

PS: is DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Servers&action=historysubmit&diff=9044&oldid=9005]this (http://([b) okay?