Merci a damdam pour l'info


http://www.cs-fusion.com/netcode_02.php


et surtout downloadez ca pour comparer le touchage d'un server lan et un mauvais server internet :|

http://tyrazr.free.fr/ftp/dossier%20cs-fusion/dispersion.avi

Paye ton bluf

C'est pas le netCode qui fait disperser les balles.
Les chokes font que tu tires à blanc (patouchage) mais pas de travers. Puis il me semble que les impacts sont gérer côté client depuis quelques temps déjà.

Et la seule chose qui fait disperser les balles c'est le recul de l'arme
=> la fréquence de tir
=> ou le fait de courir en tirant

On peut facilement se rendre compte sur la vidéo que le gars est immobile.
Par contre, sur le net il vide son chargeur plus vite que en LAN.

Elle est nulle la vidéo

toujours la meme histoire quand on vise comme un pied c 'est la faute du serveur ,de la souris qui deconne ou de l'ecran qui est pas allumer

En plus dans la suite des articles ils sortent des choses magnifiques les bonhommes :



C'est TOUT le CONTRAIRE

Je m'incline et je crois ASy

plus ou moins

d'apres les sources d'HL² (j'ai pas encore celles d'HL3)

le cl_cmdrate est le nombre de paquet de commande envoyé au serveur par seconde
ensuite il faut savoir que le serveur ne vous envoi un paquet que lorsque vous lui en avez envoyé un, et apres avoir attendu 1/cl_updaterate seconde

l'autre chose à savoir est que le cl_updaterate est bloquée à 60 par defaut sur les serveurs (mais souvent auguementé par les admins)

je ne suis pas certain que le cl_updaterate et cl_cmdrate est un impact direct sur le Choke, en fait je pense même que c'est les trois paramêtres (rate, cl_cmdrate et cl_updaterate) couplés aux caractéristiques de la ligne qui influencent le Choke

le rate est la limite en octet/seconde pour les transferts client/serveur
dans le net_graph (3) à coté des in/out on a la taille des paquets échangés ainsi que le débit utilisé

à voir en fonction des conditions de jeux et de la config de chacun, mais la taille des paquets tourne autour de 160~200 octets (max)
donc avec un cl_cmdrate à 100 il faut un rate qui tourne entre 16000 et 20000
si la bande passante n'est pas suffisante => Choke

en reduisant le cl_updaterate, le serveur envoi moins de paquet, donc on utilise un peu moins de bande passante ...

je croyais que le dossier fait par bds des SK était la référence en matière de netcode... faudrait que je le retrouve..

le problème des études du net_code est la source des données

celles réalisées à partir de données empiriques sont faussées par le carractères subjectif de certaines données (touchage) et par les bug des instruments de mesure (net_graph)

Valve n'a jamais à ma connaissance publié les sources officiel de son net_code ni même d'explication détaillée sur les échanges clients/serveurs

Les sources non officielles d'HL² donnent également des informations, mais on ne sait pas vraiment si elles sont applicables à CS 1.6

en gros le mieux reste encore de tester

Moi j'veux bien, mais si cl_updaterate influence uniquement sur le temps de réponse du serveur, on devrait pouvoir tous jouer avec cette valeur à 101 =>

Puis sinon j'ai un updaterate plus bas que cmdrate, et de même moins d'informations échangées en OUT que en IN.

D'ailleurs les connections sont souvent asymériques Upload < Download et les valeurs par défaut de updaterate et cmdrate sont respectivement de 20 et 30.

J'vois bien ça comme ça :
updaterate = émission : CLIENT -----------------> SERVEUR
cmdrate = réception : CLIENT <---------------- SERVEUR





Tips : ressortez vos 56k pour les tests
Je crois pas qu'en adsl on voit de grosses différences

la valeur 101 est une valeur étrange

essaye avec 100

mais oui, toutes personnes en ADSL peu jouer avec un cl_updaterate à 100, le tout étant de regler convenablement son rate
deplus il ne faut pas oublier que l'updaterate est bridé par le serveur par la cvar sv_maxupdaterate qui n'est pas interrogeable par le client sans un acces rcon

EDIT: mais dans les sources d'HL², apres traitement du paquet de commande envoyé par le client, le serveur repousse l'envoi de la reponse de 1/min(cl_updaterate, sv_maxupdaterate) seconde ...
je ne me souviens plus si il calcul la réponse et differe son envoi, ou s'il differe le calcul de la réponse

J ai trouvé sur un site quelque chose qui dit le contraire d'Asy:

cl_updaterate rate packets are received
cl_cmdrate rate packets are sent
rate amount of data per packet

http://www.cstrikerun.com/hints.html

ET puis rendez a César, ou plutot a Ang-L d avoir traduit Bds...

pour une fois que les DG servent à quelque chose

http://d-g.phidji.com/site/articles.asp?id=1

C'est pas ma question

Si l'updaterate n'influence QUE sur le temps que va mettre le serveur à nous répondre.
(sachant qu'il ne répond qu'àprès avoir reçu un paquet de notre part - c'est ce que tu as dit avant) et que donc il n'a rien à voir avec la connection,

pourquoi un 56k comme moi ne peut pas jouer sans avoir 100 de chokes sur un serveur avec un updaterate à 100 (ou 60 si tu veux, mais même à 30 c'est kiff kiff).

L'updaterate à bien un rapport avec le débit

en influencant le temps d'attente du serveur, il influence le nombre de données envoyées ...
moins il va attendre avant d'envoyer la réponse, plus il pourra t'envoyer de réponse ...

s'il attend 100 ms avant de t'envoyer une réponse, il ne pourra pas envoyer plus de 10 réponse par seconde
s'il attend 10 ms il pourra en envoyer 100 ...

donc oui le cl_updaterate doit lui aussi être regler en fonction de ta connexion. Dans la pratique, on peu le voir comme le nombre max de paquet par seconde envoyé par le serveur ...

J'ai compris

Alors les valeurs par défaut ont été choisie en lançant des dés, merci valve

Si notre BP supporte un envoie de données à 30 (cmdarate par défaut)
elle devrait largement supporter un cl_updaterate supérieur ou égale à 30.
Pourtant c'est 20 par défaut. C'est pour alléger la cahrge côté serveur ?

En même temps même si c'est pas ça, ça change pas le fait que la vidéo ressemble à rien.
Tu peux faire les 2 mêmes vidéos en LAN.
Y en a juste une où tu tires ou attend bien entre chaque tir que ton viseur rétrécisse, et sur la 2e tu tires rapidement pour avoir une belle dispersion.

Tu fais un montage des 2 vidéos en la nommant soigneusement dispersion.avi et rajoutant les textes LAN QUI TOUCHE STYLE HQ d'un côté & WAIB GAMIKZONE DE MERDE de l'autre.

les valeurs par defaut de Valve sont des valeurs passe partout

quelque soit ta connexion, cela marche

apres on peu ameliorer

la première chose à regler est ton rate, cad la limite max de bande passante en octets par secondes que tu accorde à CS, il ne faut pas qu'elle soit superieur à la limite de ta bande passante
tu peux par exemple faire un test pour mesurer ta bande passante effective : http://mire.ipadsl.net/speedtest/speedtest4.php

mais attention, pour les lignes à debit assymetrique c'est l'upload qui va bloquer
j'avais trouvé des test d'upload ... mais perdu ... sinon, y a grenouille.com

donc tu prends ton débit réel en octet par seconde ... et tu as ton rate, par exemple pour du 1024/128kbps cela donne du 128*1000/8=16000
pour un modem ... bah ... faut déjà mesurer ta bande passante

ensuite il faut regler cl_cmdrate et cl_updaterate
pour cela on va utiliser le net_graph 3, et sur un serveur moyen et peuplé tu observe les nombre à coté de in et out et principalement leurs valeurs max
(histoire de prendre un exemple on va prendre 160/80)
tu va donc echanger avec le serveur au maximum :
160 * cl_cmdrate + 80 * min(cl_updaterate,cl_cmdrate)
et donc ben à toi de trouver des valeurs pour que cela reste sous la valeur de rate

enfin bon, a verifier car depuis la suppression cl_rate, je ne sais plus si le rate est la limite upload et download ou la limite du cumul des 2

Bah va falloir creuser

aller un petit coup de main

j'ai remarqué quelques trucs jsais pas si sa va vous aider mais bon.Je m interesse pas mal au reglages de mon modem 56k suxX donc j essaye d avoir le meilleur
si tu met ton cl_cmdrate 30 et cl_updaterate 20 ton cmdrate aura en realité une valeur proche de celle de l updaterate (en l ocurence 20)

la commande cl_rate est a 9999 a chaque debut de partie si tu la met a 0 tu gagne legerement en plus elle ne serre pu a grand chose

je possede un 56 g essayer a peu pres tout les valeurs pour le rate (de 1000 a 4000)pour cmdrate (10 a 30) et cl_updaterate (10 a 30) aucune de ces commandes n a d influence sur mon choke perpetuellement bloquer a 30/40
(thx de me corriger si je me trompe )

Bizarre j'ai pas tout vaux probleme moi avec mon 56K

Peut-etre mon chit

Bah je confirme, si ce n'est que j'arrive un brin à baisser le choke en montant le rate ou diminuant le cl_updaterate.
rate 4000
cl_updaterate 20
cl_cmdrate 30

Pareil 30/40 de choke (pas toujours mais régulièrement, jamais 0 de choke très longtemps), des pointes à 60-80.

Avec le rate de base à 3500, c'était pareil mais avec des pointes à 80-100

c'est blasant j ai fait le test de connexion de nosferatu (thx pour le lien)
test bande passante
alors ma bande passante est de 5Ko dans le meilleur des cas
meme apres avoir utilisé befaster alors que sur
Banswitch je suis a 7Ko limite 64K
jpossede un abonement aol illimité (comme Tyran) sauf que lui a jamais de choke alors que moi j ai un plus petit ping que lui mais plus de choke
les 56k faut qu on se mette au boulot pour trouver comment calculer une bonne config

Moi j'ai jamais de choke ni de loss

Et moi j'ai jamais de chocs ni de loques


Oops...désolé , c'est le pastis...je m'auto tête

Topic reserver au 56 k

le problème des 56k c'est que ce type de connection est tellement lié à moultes détails que chaques connection réagit différemment (pc = personnal computeur, mais on pourrait dire personnal connection aussi )

le meilleur exemple :

moi: AOL 56k illimité, ligne neuve, modem olitekV92, rase campagne...
mon cousin: AOL 56k illimité, ligne neuve, modem olitek V90, rase campagne (à a peine 4 Km à vol d'oiseau...)

a config égaux, lui avait sytémaiquement 20 ms de moins que moi sur le même serveur, et on chokaient jamais en même temps...

ya pas de miracle, faut tester et en rester pas a l meilleure config, mais la moins pire (et tout comme en adsl, prévoir des modif suivant les serveurs)

***établir une théorie précise quand la base est aussi stable qu'une platrée de guacamol n'est que pure hérésie petit scarabée***

les tests de bande passante ne sont pas tous équivalent, ni fiable

quand tu fais du developpement reseau, tu sais vite que la taille des paquets échangés influence grandement la bande passante

CS fonctionne par echange UDP de petits paquets donc dispose toujours d'un peu moins de bande passante que la bande max

si j'ai un peu de temps, (ce qui ne serais tarder), je vais vous pondre un test de bande passante spécial CS

comme je l'ai dit sur cloubicé, je trouve qu'ils raisonnent un peu vite pour ce qui est de leur choix des FAI (sauf pour aol ) et pour le choix des fournisseurs de serveurs...

On sent que la recherche a été difficile et les tests vraiment très partiaux pour passer à des arguments du type

machin c'est cacaboudin

Bah, je pensais aussi à l'UDP à cause des commandes 'ping' du jeu.

Mais l'autre jour Fluf m'a fait réalisé un truc :


Alors UDP ? TCP ? ou un mélange des 2 ?


-----------------------------------------

Sinon pour les 56K, bah pareil que neur0ne, j'suis blazé.
Certains on une connection nickel : Tyran, #Bvht.tk | Halo (maintenant en adsl)
Et les autres choquent en folie : Neur0ne, Venom, moi même...

En même temps j'ai une ligne qui plafonne à 38666 bauds

ba on peut dire ce que l on veut de AOL mais n fait avec le bon numero d accés sa marche bien comme FAI en 56k en tous cas

http://steampowered.com/index.php?area=faq...915705,97731900

en sachant que par defaut les serveurs sont sur le port 27015 ...

le risque de désordre un UDP existe, mais pas sous CS

quand on désire utiliser un transmission client serveur rapide, on gere nous même l'acknowledge ... j'ai pas été voir dans le client, mais coté serveur on sait que ce dernier n'envoi des données que suite à la reception d'un paquet client ... la reception du paquet serveur est donc un acknowledge du paquet client

ensuite on peu indiquer un numéro d'ordre dans les paquets pour les débrouiller, mais quand le retard à prendre pour attendre un paquet perdu est trop grand ... on le jete ... ho une définition du LOSS

et "accusé de réception" c'est trop français ?

c'est moins high tech ctou

Apres avoir fait un petit test avec kerio, les échanges client serveur se font bien en UDP

regle n°7, ctou

Là je suis perdu

Avant tu disais, le serveur envoie des paquets toutes 1/min(cl_updaterate, sv_maxupdaterate) secondes.
Donc + on monte l'updaterate, plus on a de chance d'avoir du choke (surtout en petite connection et/ou avec un 'rate' trop faible).
En gros l'updaterate influence le nombre de message serveur vers client.
(notion de quantité ... débit)


Et tu as dis aussi :


Là, je comprends que le serveur répond plus rapidement à un paquet envoyé.
(notion de temps de latence ... ping)



Après tu dis le serveur n'émet qu'àprès avoir reçu un paquet de notre part.
Donc là je comprends que si j'émets peu, cl_cmdrate faible, le serveur devrait me répondre peu aussi ; ce qui ne devrait rien changer à mon taux de choke, quelque soit mon cl_updaterate ?

ce dont je suis sûr (d'apres les sources d'HL²) :
le serveur n'envoi un paquet au client, qu'apres avoir reçu un paquet de se dernier et avoir attendu 1/min(cl_updaterate, sv_maxupdaterate) seconde

faudrait que je regarde comment fonctionne l'envoi coté client, et que j'arrive à trouver une definition valable du CHOKE

sinon le ping (celui du net_graph), c'est le temps en miliseconde qui s'écoule entre l'envoi d'un paquet par le client et la reception de la reponse du serveur moins 1000/cl_updaterate
(d'où au passage une erreur du ping lorsque cl_updaterate est superieur à sv_max_updaterate)