Pages: 1 [2] 3
  Print  
Author Topic: Connection Icon  (Read 51592 times)
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #25 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.
« Last Edit: September 02, 2011, 10:07:32 AM by GrosBedo » Logged
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #26 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

?
Logged

Todo: Walk the cat.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #27 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 Wink

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.
« Last Edit: September 02, 2011, 04:49:24 PM by 7 » Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #28 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. 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 to inform users about some server settings, but it would be quite intrusive and would still rely on admins' good will.
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #29 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.
« Last Edit: September 03, 2011, 08:02:18 PM by GrosBedo » Logged
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #30 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.
« Last Edit: September 04, 2011, 03:55:37 AM by 7 » Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #31 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.
« Last Edit: September 04, 2011, 10:08:34 AM by GrosBedo » Logged
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #32 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.
« Last Edit: September 04, 2011, 11:18:39 AM by 7 » Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #33 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 Smiley 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.
Logged
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #34 on: September 04, 2011, 01:46:49 PM »

Our posts have crossed because I was reediting my previous post, but anyway:
Good point Smiley 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.

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

Smiley 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 Wink

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.
« Last Edit: September 04, 2011, 04:41:50 PM by 7 » Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Graion Dilach
Member


Cakes 12
Posts: 403



« Reply #35 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.
Logged

One shall remind what have he left behind... to actually realize that it's still cool.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #36 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 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.

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #37 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.
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #38 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?
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #39 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.
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #40 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). 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
« Last Edit: September 09, 2011, 06:12:40 AM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #41 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.
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #42 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).
« Last Edit: September 09, 2011, 11:39:23 AM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #43 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.
Logged

There are nothing offending in my posts.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #44 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 section to the wiki Servers page. I've made it as easy as I can, is this ok?
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #45 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!
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #46 on: September 12, 2011, 11:48:22 AM »

Great formulas. Also good idea the one about efficiency. Smiley 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 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), 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 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?
« Last Edit: September 12, 2011, 12:16:52 PM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #47 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), 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 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.
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #48 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), 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 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?
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #49 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 Wink

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

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Pages: 1 [2] 3
  Print  
 
Jump to: