Connection Icon

[The Geez]

How is it possible to turn off that annoying connection icon above people's heads on my server? lol

 

[Gig]

What? Could you please post a screenshot?

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

[Cacatoes]

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*

[Gig]

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. 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.

[7]

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.

[Gig]

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).

[7]

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

[Gig]

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.

[The Geez]

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.

[pulchr]

i don't run a server, but a quick google search suggests something in the range of 20 to 30 sv_fps.

[Gig]

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 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 (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 (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 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), 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, I would simply add how many players are supported for each MBps of upload bandwith, in the line about sv_maxrate, at 25000.

[Cacatoes]

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.

[sago007]

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.

[Gig]

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 used 25? Do you think it's better to change it to 20?

[sago007]

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 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. 

[7]

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 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.)

[GrosBedo]

=> 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 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.

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.

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 .

[7]

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!

[Gig]

- 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.

[7]

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.

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).

[sago007]

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.

[Gig]

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 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...

[GrosBedo]

- 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.

[7]

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).

[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.