Netsettings bei 6MBit

1 Stunde 1 Tag 1 Woche 1 Monat Immer
Einloggen mit Benutzername, Passwort und Sitzungslänge

Weiss zufällig jemand die Einstellungen bei CS:S für eine 6 MBit Leitung?
Habe leider bisher nirgends etwas gefunden.
Achja, ohne Fastpath. Gibt es im Moment bei 1&1 noch nicht  

Gruß Pene

Was hast Du denn für einen Ping bisher?

Ich spiele mit Org. Settings auf 2 MBit und komme auf ca 80.
Ich wollte auch auf 6MBit umsteigen. Hat es schon was gebracht??

WEnn Du Ergebnisse bekommst, die hier nicht geposet sind, bitte an mich weiterleiten

Munter bleiben! B)

cl_updaterate "34" ->>Bei Servern mit Tictrate 66 auf "67" stellen
cl_cmdrate "34"-->>>Bei Servern mit Tictrate 66 auf "67" stellen
cl_smoothtime "0.02"
rate "20000"
cl_interpolate "1"

Das sind meine musst halt mal gucken-da ich Fastpath habe.

So, hier mal das was die Jungs bei TICT so gefunden haben:

rate 20000
cl_cmdrate 100
cl_updaterate 100
cl_interp 0.1
bei fp noch zusätzlich

cl_cmdbackup 30

 :band:  

cl_cmdrate 100
cl_updaterate 100
Ist unsinn denn du kannst nicht mehr empfangen als der Server hergibt-und bei Servern mit einer Tictrate von 100 solltest du es auf 101 stellen

Die Tickrate-Geschichte wird eher überbewertet. Dieses Thema kam mal auf, als es diesen sogenannten Hitbox-Bug bei Source gab.
Fakt ist allerdings, dass es kein Hitbox-Bug war, sondern ein Bug im Demoplayer. Daher diese Verschiebung der Hitboxen in diesem Video, welches seinerzeit die Runde machte. Eine knappe Woche später mit einer simplen Note im Changelog gab es ein Bugfix für den Demoplayer von Valve.

Wenn man sich nun dran macht und auf einem Server die Tickrate ändert, müsste man konsequenterweise auch noch weitere Einstellungen am Server vornehmen. Ansonsten geraten die Serversettings schnell in eine Schieflage bzw. kaum jemand hat einen Nutzen davon.

Die höhere Server-Tickrate sorgt übrigens für eine höhere CPU-Last sowohl auf dem Server wie auch auf dem Client, denn der Client läuft immer auf der selben Tickrate wie der Server.

Um auf die Netsettings zurück zu kommen. Ich persönlich habe die besten Erfahrungen mit annähernd Default-Settings gemacht.

Im übrigen ist es der Source-Netengine ziemlich egal, ob da jemand mit 1mbit oder 6mbit spielt. Weil sie ebend so konzipiert ist, dass keiner einen Bandbreiten-Vorteil hat.

Entwickler von Valve haben mal in einem Artikel die Netengine ein wenig erklärt. Ihr Fazit dabei war, wer sich nicht auskennt, solle bei den Defaultsettings bleiben.
http://www.valve-erc.com/srcsdk/general/mu...networking.html

Btw. mit hohen cl_cmdrate und cl_updaterate erhöht man sich nur unnötig seine eigene Latency, siehe Ping Netgraph.

...Fakt ist allerdings, dass es kein Hitbox-Bug war, sondern ein Bug im Demoplayer. Daher diese Verschiebung der Hitboxen in diesem Video, welches seinerzeit die Runde machte. Eine knappe Woche später mit einer simplen Note im Changelog gab es ein Bugfix für den Demoplayer von Valve.....

OK, aber ich mß da mal nachhaken, denn:

WIE kann es ein BUG im DEMOPLAYER gewesen sein, denn man die INGAME Sequenzen gesehen hat.
WARUM habe ich dann INGAME bei CS:S diesen BUG genau sehen können ??

Ich hatte mir damals den Spass erlaubt selbst einen CS:S LISTEN SERVER mit den damaligen Einstellungen zu erstellen.
Als ich dann den Bot hinzugefügt hatte, sah ich genau den Effekt den man im Video sehen konnte.
Wenn ich also die Sache INGAME sehe, dann kann es doch nicht am DEMOPLAYER hängen, denn ich hatte KEINE DEMO aufgenommen, sondenr die Sache ja direkt IM SPIEL gesehen.

Ich hab das Szenario damals auch mit einem lokalen Server durchgespielt. Bei mir war die Hitbox da wo sie hingehört. Erst als ich mit cl_interp rumgespielt habe, verschob sie sich entsprechend nach vorn oder hinten. Ich verwendete lokal Default-Settings! Irgendwo muss ich auch noch die entsprechenden Screenshots haben.

Hier das offizelle Statement eines Valve-Mitarbeiters:
There is a bug in the demo code (incorrectly interpreting client side prediction) that makes using demos to look at hit box issues invalid. You need to do a direct capture from your video card buffer.
We have a couple small fixes for the hitbox code with the next release, but the majority of the  problem is that people do not understand how client side prediction works. In particular, the server is 100 msec ahead of all the clients, so the server side hitboxes will ALWAYS lead the clients view of the work. When the client fires a weapon the server
rewinds its state to the exact tick of that button press and then computes the result (one of the bugs was that the rewind code didn't correctly reset the state of the bone cache in the player model)

Also der Bug war nicht direkt im Demoplayer, sondern im Demofile. Aber das hatte ja letztendlich die gleiche Auswirkung.

Fazit?

Alles auf "default" bzw. Standarteinstellungen belasssen?


(sry, habe k.A. von sowas)


Gruß
JOPA

 

fast Default
CS:Source spiele ich derzeit mit:

rate 9999 // default bei DSL
cl_cmdrate 35
cl_updaterate 20 // default
cl_resend 6  // default
cl_cmdbackup 20
cl_interp 0.1 // default
cl_interpolate 1.0 // default
cl_smooth 1 // default

fast Default
CS:Source spiele ich derzeit mit:

rate 9999 // default bei DSL
cl_cmdrate 35
cl_updaterate 20 // default
cl_resend 6  // default
cl_cmdbackup 20
cl_interp 0.1 // default
cl_interpolate 1.0 // default
cl_smooth 1 // default

Man Tech du bist ja sowas von gemein und fies.  

Du raubst gerade allen Netsettings Experten und Jägern die letzten Argumente so gut treffen mit Defaultsettings. Ich hoffe der Rowdy liest das hier nicht.  :clown:

Also ich spiele nicht mit Standard Settings vielleicht sollte ich das mal probieren. :oops:

Meine momentanen Settings für DSL6000 mit Fastpath sind diese hier:

cl_smooth "1"
cl_smoothtime "0"
cl_interp "0"
cl_interp_npcs "0"
cl_interpolate "1"
cl_lagcomp_errorcheck "0"
cl_lagcompensation "1"

rate "25000"
cl_cmdrate "100"
cl_cmdbackup "8"
cl_updaterate "100"
cl_dlmax "4096"

Fragt mich aber nicht was das alles ist sind aus dem Netz zusammengesucht und ich treffe ganz gut damit.


Gruß Spitz  

Danke für die Hilfestellungen und die ausführlichen Kommentare.

@ tech
Deine Netsettings für CS:S werde ich dann wohl übernehmen.
Taugen die auch für 1.6 oder sollte man verschiedene Netsettings
nutzen und jeweils eine netsetting.cfg erstellen?

achso:

Im übrigen ist es der Source-Netengine ziemlich egal, ob da jemand mit 1mbit oder 6mbit spielt. Weil sie ebend so konzipiert ist, dass keiner einen Bandbreiten-Vorteil hat.

Was mir einen Vorteil gebracht hat, ist die Umstellung auf "Interleave low" (FP).
Da hat sich mein Ping mehr als halbiert.



Gruß
JOPA
 

Ich hab das Szenario damals auch mit einem lokalen Server durchgespielt. Bei mir war die Hitbox da wo sie hingehört. Erst als ich mit cl_interp rumgespielt habe, verschob sie sich entsprechend nach vorn oder hinten. Ich verwendete lokal Default-Settings!

Ich glaube wir reden da von verschiedenen Bug und somit aneinander vorbei, denn ich hatte damals die gleichen DEFAULT EINTRÄGE beim LISTEN SERVER, allerdings hatte ich beim erstellen des BOTS dann das Phänomen das man im dem einen Video gesehen hatte.
Sprich die Hitboxes liefen der Texturfigut voraus.

Erst nachdem ich dann die Sache mit dem TICKRATE Einstellungen geändert hatte wurden die Hitboxes entsprechend auch auf das Texturmodel umgelegt.

Weiß VALVE wieder was da falsch läuft, denn so wie's ausschaut STEAM da wiede einiges nicht

Was die Netsettings angeht, ich denke das da jeder selbst mit seinen Einstellungen hantieren muß.
Es kommt entsprechend auf die Auslastung des WAN, den Provider, die Uhrzeit in der man zockt und die entsprechende Strecke zum Server an in wie weit man mit den Settings zufrieden ist.

Jemand der in der Nähe des Servers spielt wird somit auch mit anderen Netsettings spielen können als jemand der erst durch verschiedene Hops gehen muß.
An und für sich ist der PING zum Server auch nicht entscheidend, denn dieser sagt nur aus wie schnell das PING DATENPAKET zum Server und wieder zurück geschickt wurde.
Die Datenpakete die beim spielen verschickt werden sind um einiges komplexer als das PING Packet.
Man hat zwar mit FP eine schnellere Antwort, erkauft sich diese aber durch die Fehlertoleranz, sprich es kann durchaus vorkommen das man auf dem Server zockt, aber schon das virtuelle Leben ausgehaucht hat.
Vielleicht kommt das dem ein oder anderen FP Spieler noch in Erinnerung als man ein paar Schritte noch gelaufen ist und dann aus heiterem Himmel am Boden lag, weil ein Gegner oder Mitspieler Sekunden zuvor auf Ihn geschossen hat.

Lange Rede und wieder kurzer Sinn:
Die Netsettings muß JEDER FÜR SICH finden, man kann sich nur in gewisser Weise an einen Rahmen halten den man im I-Net zu Hauf findet

@ JOPA
Bei 1.6 hatte ich geringfügig andere Netsettings. Allerdings auch nahe den Default-Settings. Hab aber schon ewig kein 1.6 mehr gespielt.
Ansich hat Tomy Tom schon Recht, wenn er sagt, dass jeder seine eigenen Netsettings - alleine schon wegen unterschiedlicher Anbindungen - finden muss.
Ich bin halt nur der Meinung, dass man sich eng an den Default-Settings orientieren sollte, dann kann man nicht viel falsch machen.

Die Netengines, egal ob die von HL1 oder jetzt Source sind so ausgelegt, dass eben jeder im Internet gut spielen kann, nahezu egal, was für eine Anbindung man hat.

EDIT:
Kleines Beispiel: Mir ist da ein Fehler unterlaufen.
cl_updaterate "20" bedeutet, dass 20 Snapshots der Weltdaten pro Sekunde vom Server an die Clients gesendet werden.
/EDIT
Jeder Spieler bekommt zu diesem Zeitpunkt die gleichen kompletten Weltdaten.
Die Zeit zwischen dem Senden wird durch die Netengine vorausberechnet und die Spielermodels entsprechend interpoliert dargestellt und bewegt.
Um hier nun kein Ungleichgewicht in den Daten zu erhalten, müsste man eigentlich exakt zur Veränderung der Transferbandbreite (rate, cl_updaterate, cl_cmdrate) neue Werte für cl_interpolate, bei 1.6 ex_interp etc. berechnen. Verlässliche Formeln hat da bisher niemand geliefert.

Davon abgesehen, welchen Wert man nun für cl_cmdrate, cl_updaterate oder rate man auch nimmt, letztendlich bestimmen die Servereinstellungen dieser Werte (sv_updaterate, sv_cmdrate, sv_rate),  wie oft die Clients Daten bekommen.

Zur Tickrate:
Die Tickrate bestimmt sowohl für den Server wie auch für die Clients "lediglich", wie oft der Server pro Sekunde sein "Bild der Welt" aktualisiert, also wie oft der Server in jeder Sekunde die Bewegungen aller Spieler und Items sowie alle Aktionen berechnet. Höhere Tickrate = höhere CPU-Last bei Server und Clients.
Man müsste also dann zusätzlich die eben beschriebenen Einstellungen entsprechend mit verändern.

Mit all diesem hochgepitche der Settings hebelt man letztendlich die Fehlertoleranz der Netengine aus. Ich bezweifel mal, dass das so gewollt ist von den Programmierern.

Mein Fazit also: zurück zu niedrigen Werten.

Btw. ist mindestens genauso wichtig, die TCP-Einstellungen vom Betriebssystem zu optimieren.

@ Tomy Tom
Ich denke schon, dass wir das gleiche meinen, wir haben eben nur mit unterschiedlichen Befehlen rumgespielt.
Siehe diesen Artikel:
"Das Hitbox Video"

@ Tomy Tom
Ich denke schon, dass wir das gleiche meinen, wir haben eben nur mit unterschiedlichen Befehlen rumgespielt.
Siehe diesen Artikel:
"Das Hitbox Video"

OK dann sprechen wir von der selben Sache.
Das beweist mal wieder das viele Wege zum Ziel führen