Sunday, August 29 2004, 02:55:58 #10795 Quake III : CL_MAXPACKETS, SV_FPS and COM_MAXFPS explained
Taken from
ukgamer > gaming served with sauce
Another snippet lovingly thrown at my door by coder guru arQon from the Promode team, this time regarding cl_maxpackets and com_maxfps settings. Now I've been using the settings he hints at, 100/100, along with 0 timenudge for between six months and a year now, and the difference was quite marked at first and has certainly improved my consistancy over time. It's very noticeable with rail, but then coming from a Quake 2 background I'm the type of player so rail dependant that I'd notice it quicker.
Either way, here's the mail in full, enjoy.
> and cl_maxpackets give you the ability to send an update every frame or
> every 2 frames, 3 frames, or 4 frames (and so-on) which means that the
> amount of packets you send is still roughly connected to your frames per
> second.
Yeah, pretty much.
> If this is correct, someone receiving (and capping) at a constant 125 fps
> (com_maxfps 125), with maxpackets 100, is sending 1 update to the server
> every 2 client frames - i.e. they receive no difference in connection as
> someone with settings between cl_maxpackets 63 and 100 (inclusive) so long
> as their FPS remains constant - they will always send 63 updates to the
> server a second. IOW, for com_maxfps 125, cl_maxpackets 63 = cl_maxpackets 100
FAIK, yeah. Conceivably, it could slice them as half 1-move (see below) and half 2-move, but I've never really looked into it.
> Therefore, for com_maxfps 125, cl_maxpackets 30 will send 1 update every 5
> client frames - i.e. cl_maxpackets 30 can = cl_maxpackets 25.
Traduzco para pelotudos:
el com_maxfps y el cl_maxpackets van de la mano...
Si usas 125 fps, y 125 packets, mandas 1 packet por frame.
si usas 125 fps y 63 packets, mandas 1 packet cada 2 frames
y asi....
Otro post:
cl_maxPackets y com_maxFPS
Para maximizar la eficiencia entre la conexion, cl_maxpackets y com_maxfps tienen que ser elegidos los valores de una manera que respeten la relacion entre el cl_max_packets y el framerate. El cl_maxpackets tiene que ser de la forma int(Framerate/N) que ya esta explicado arriba. todo lo que sea distinto no es eficiente.
Vamos a un ejemplo asi vemos bien como es el tema...
La cantidad actual de paquetes que uno puede mandar al servidor en cada frame, o en 2 frames, o en 3 frames y asi sucesivamente.Es decir ..si uno esta corriendo a 125 fps los posibles paquetes por segundo son :
125/1 = 125
125/2 = ~63
125/3 = ~42
125/4 = ~32
Entonces..si vos estas usando maxpackets a 100 con 125 fps..uno no esta mandando 100 paquetes por segundo..uno va a mandar 1 paquete cada 2 frames que es 62.5 porque no le alcanza los 100 del maxpackets para mandar todo el frame entero.
Si el framerate baja a 100 fps..entonces de repente estamos permitidos a mandar 1 paquete por frame..y obtendremos un salto de cl_maxpackets de 63 a 100 paquetes por segundo
100/1 = 100
100/2 = 50
100/3 = ~34
Entonces, si uno esta usando cl_maxpackets seteados a 100 y usando 125 fps entonces estaremos mandando 62.5 paquetes por segundo al servidor...pero si baja a 100 los fps entonces podremos mandas 100 paquetes por segundos. Si la conexion no es capaz que manejar 100 paquetes por segundo entonces el ping va a subir o se va a disparar. Es mejor que los paquetes por segundo se mantengan constantes sino la latencia va a fluctuar. Toda esa informacion solo es necesario cuando uno tiene un muy bajo upstream y cuando no puede llegar a usar el maximo de 125. Si uno tiene el cl_maxpackets en un numero "no valido" entonces uno malgasta ancho de banda de la conexion y tambien puede llegar a tener un potencial lag o inestabilidad.
---------- Post added at 09:48 ---------- Previous post was at 09:44 ----------
PD: osea mandando 1 packet por frame, a mi me funciona mal....... no me pregunten porque pero no me funciona como deberia.
usando 63 mandando 1 packet cada 2 frames, me funciona perfecto....
Igual en qlive, esta el cl_packetdup, k manda duplicado los packets........ osea si usas 125 con packetdup, tas mandando 2 packetes por frames y anda a saber bien bien como lo maneja id eso... pero sin lugar a dudas yo sacandole el duplicado o poniendoselo es lo mismo , me funciona MAL.
El rate y el snaps tambien influyen pero no se como y ni ganas de buscar,
lo mismo el sv_fps.
usen google.
---------- Post added at 09:50 ---------- Previous post was at 09:48 ----------
despues desde windows, podes twikear mas la conexion, borrando algunos parametros de no me acuerdo que (lo hice en su momento), k manda info duplicada tambien...
en fin Por internet hay muchisimos factores que influyen en la jugabilidad, cada player se adapta y busca algo optimo para el.
a mi con 63 NO ME TRASPASAN las cosas, NO me warpeo. Me funciona PERFECTO.
En lan ES DISTINTO. Mismos SO. Misma Conexion, Misma Config inet. GG? INET = CRYMORE.
---------- Post added at 10:19 ---------- Previous post was at 09:50 ----------
"rate" - This setting controls packets to ensure a good connection. If you have an ISDN modem (128K) then this can be set to around 8000. If you have a 56K modem then this should be around 3000-4500 begin_of_the_skype_highlighting**************3000-4500******end_of_the_skype_highlighting depending on your connection speed. If you are on a LAN or have ADSL modem, then this can be around 24000 or perhaps even higher. Experimentation is required to find the optimal setting.
"snaps" - This is possibly the most important setting for getting a good connection. As everyone knows, in Quake 2, your gameworld updates depended on your current FPS so slower computers were at a disadvantage. Now, in Quake 3, your snaps setting determines how many updates you recieve from the server. 56K modems should have a setting of around 20. ISDN modems (128K) should be around 40 as should any other fast connection devices (LAN, T1 etc....). Remember to read my cg_lagometer section for tips on "snaps".
"cl_packetdups" - As the name suggests, this setting is used to send multiple packets to compensate for lost packet drops. This setting should be set at 1 unless you have a VERY good connection in which case set this to 0. Use the lagometer to decide on which setting to use.
---------- Post added at 10:20 ---------- Previous post was at 10:19 ----------
pb_sv_cvar rate IN 2500 25000
Players using a setting below 2500 will be very jerky and possibly forcing warping or making themselves very hard to hit. 2500 is the default for 56k modems and really is very low, a 56k modemer should really try 3000 even on a poor 4kps connection to get better gameplay. Maybe more of an issue is scripts setup to change between rate settings, using a low setting while reloading to minimise weakness. 25000 is the upper limit as the Q3 code itself has a cap of 25000. A broad range of rate settings are therefore allowed to cover all those perfectly reasonable while not allowing those which are unnecessary.
Clan-related organisations should consider 3000 at a minimum, or if you would rather have players who have at least an ISDN-equivalent connection, then 5000 should be the lower value, to allow some room for low-quality voice comms. 56k players can play fine (better!) with rate 3000, but on a public you cannot really expect these players to have a clue about changing the default connection settings by opening the console and typing in commands.
Note another possible misuse of the connection settings is to make ping look very bad, in order to demand clanwar takes place on a server where they have an advantage, rather than the one best overall.
Note: connection setting restrictions are possibly unnecessary for servers running ETPro with b_antiwarp 1. These restrictions should not cause any negative side effects however. Further, a large portion of players perceive issues with low connection settings, so it's probably a good idea to leave them on even if just to hedge your bets, satisfy ignorance or whatever.
Revision, 22/4/5: increased the minimum rate to 3200 for ETPro restrictions only. This should be fine for 56k modem and ETPro's restriction system will automatically correct any lower values, so this restriction range not allowing for a default value should not be any problem. I'd suggest 7000 for public servers if you don't care about 56k players or ISDN'ers having voice comms.
pb_sv_cvar snaps IN 20 40
Snaps should only be 20 or 40, nothing else makes any sense to use (see exception, below). If you want to know what snaps actually does, lets quote reyalP, who is also backed up by Bani and Rain in this convenient thread:
Snaps is how many snapshots you want the server to send you, per second. The server can only generate a snap each server frame, since a snap is defined by the state generated in the server frame. So for the server to send you more than sv_fps snaps wouldn't make any sense. Now, the ET code has bee known to do things that don't make sense, but if it did something dumb like sending you 2 identical snaps per frame, it should show up in network traffic and likely weirdness on your client. By observation, it doesn't.
Since sv_fps should definately always be left as 20, it only makes sense for players to use snaps at 20.
[...] there will definitely be problems (some not necessarily visible) if sv_fps is not set to 20. We definitely now recommend that all servers (especially league servers) run with sv_fps 20 set.
- SD lead game designer Loki
However many players do state a preference for snaps 40 (perhaps due to the placebo effect). The worst possible effect of snaps 40 is duplication of transmissions, which would eat up a bit more rate allowance, and ping information on the scoreboard can become even more incorrect (scoreboard pings are very unreliable and easily manipulated, they are calculated and not simple results of an OS 'ping' command). None of this is a real problem for anyone else so you might as well let them use it, although for competition use it may be smart to require snaps of 20 when teams are checking servers for acceptable connections (just check this via /players output).
If your server specifically caters for 56k dialup users, you might want to except the norm and allow snaps of 10. This setting is overly warpy for normal servers (and dialup users should still be able to use 20 without problem), but 10 may play better for 56k as it results in a lower bandwidth usage, the primary issue for such connections.
I am aware of various supposed literatire on the topic giving various contrasting explanations of snaps, most of which also contradict each other:
According to the Keen cvar page, which for starters is Quake3, says "server run[s] at 40Hz, so use 40, 20, or 10". Another interpretation which basically amounts to the same thing as far as this article is concerned is that sv_fps is always set to 20, and the client's snaps should be a multiple of the server's sv_fps, see Upset Chaps. A further interpretation says client's actual snaps will reduce (but cannot increase) to server's sv_fps, so players who have the bandwidth should set snaps 40 even if a server has set sv_fps to 30, for example (dig around here for info). I'm yet to see a Wolf server running sv_fps at anything other than 20 however, if you DO change it on your server then consider setting pb_cvar snaps IN 40, maybe, but expect a lot of players to be getting kicked.
Even if you subscribe to these Quake3 snaps explanations, there is a common denominator which still results in there being no apparent reason for players to use a snaps setting other than 20 or 40.
ETPro Note: connection setting restrictions are possibly unnecessary for servers running ETPro with b_antiwarp 1. These restrictions should not cause any negative side effects however. Further, a large portion of players perceive issues with low connection settings even with b_antiwarp, so it's a good idea to leave them on even if just to hedge your bets, satisfy ignorance or whatever.
pb_sv_cvar cl_maxpackets IN 15 100
A third connection setting, and again the reasons are associated with laggy, warping players. the maxpackets setting, as the name suggests, sets "set the transmission packet size or how many packets are sent to client" (Keen). The higher your maxpackets, the more is sent and the smaller each packet of data is - hence, the more frequently they arrive. Each packet however wastes some of your rate in the form of for example packet headers, so players on a low rate setting (modemers) should have a fairly low cl_maxpackets setting. Since the packets go both ways, players on low maxpackets will not only find other players are jerky to them, but all other players will also find this player to have jerky movements, which can make them hard to shoot. If that sounds reasonably easy to understand, there's a contradictory explanation of cl_maxpackets on Upset Chaps, but the end result is still cl_maxpackets IN 15 100: "the default setting for cl_maxpackets is 30, usable range is 15 to 100 on the Internet", although there is a caveat in what appears to be an edited update "maximum 125 under [Q3] point release 1.32 or above", and ET does appear to include the Q3 engine update related to Q3 1.32 point release.
Whichever you buy into, 15 is the default setting for "modem", and there is no good reason for any players to use a lower setting, infact most modem players should try a higher setting to around 20-30 anyway, and see if it works better for them. In a cup or league environment where good connections are more important -- and players are much more likely to have them -- cl_maxpackets IN 30 100 is probably a better setting, although an upper limit of 125 is arguable. Modem players participating in clan play are also likely to understand how to adjust their settings appropriately.
Note the punkbuster.cfg provided with ET suggests IN -15 100: the -15 can safely be assumed to be a typo!
Note: connection setting restrictions are possibly unnecessary for servers running ETPro with b_antiwarp 1. These restrictions should not cause any negative side effects however. Further, a large portion of players perceive issues with low connection settings, so it's probably a good idea to leave them on even if just to hedge your bets, satisfy ignorance or whatever.
Revision, 22/4/5: increased minimum to 20, to equal server snapshot frequency. I'd only recommend this by default when using ETPro's cvar restriction system however, since a default setting is outwith this range (ETPro will adjust the cvar for the client).
---------- Post added at 10:24 ---------- Previous post was at 10:20 ----------
por lo k comprendo:
Snaps is how many snapshots you want the server to send you, per second. The server can only generate a snap each server frame, since a snap is defined by the state generated in the server frame.
Snapshot o copia instantánea de volumen. Es una función de algunos sistemas que realizan copias de seguridad de ficheros almacenándolos tal y como fueron capturados en el pasado.
Si mal no comprendo es la informacion k te manda el sv a vos. Y esta relacionada con los sv_fps k use el server, Archiva y manda el duplicado a vos. Ahi refrescas tu informacion. 40 snaps y el sv funciona a sv_fps 30 = al pedo... no vas a recibir mas de 30....
si el sv esta en 60 con 40 vas a recibir 40 nomas de los 60 k te podria mandar el sv. (si estoy ekivocado corrijanme)
---------- Post added at 10:25 ---------- Previous post was at 10:24 ----------
12.1. What is a snapshot?
A snapshot represents a frozen image of a volume. The source of a snapshot is called an "original." When a snapshot is created, it looks exactly like the original at that point in time. As changes are made to the original, the snapshot remains the same and looks exactly like the original at the time the snapshot was created.
The snapshot feature is very useful for performing data backups. In order to perform a consistent backup, the volume that is being backed up should not change while the backup is running. This often means the volume must be taken offline during the backup, which can be a significant inconvenience to users. With snapshots, the volume can be kept online. A snapshot of the volume is created and the backup is taken from the snapshot, while the original remains in active use.
Iniciado por bichoreload
Osea que estaba hecha de changos?
![Enviar un mensaje por ICQ a [Xe]GigA](style6/misc/im_icq.gif)
![Enviar un mensaje por Yahoo a [Xe]GigA](style6/misc/im_yahoo.gif)
Re: Mira mira Aim Perfecto y sin aimbot!!
29/09/2010, 08:46A bue... no voy a leer todo esto...
.
Citar
Permisos de Publicación