Wissenswertes

Ich trage hier mal alles zu settings und sonstigem ein was mir so in die Finger kommt...

Also anfangen würde ich mit dem jnksfix aus dem Sourcejunkiesforum
__________________________________________________________________________

Was diese Einstellungen bewirken:

- Deaktivieren von Nagles Algorithmus (eingebaute 200ms im Netzwerkprotokoll von Windows)
- Deaktivieren des IPv6-Protokolls
- Reduzierung der standardmäßig reservierten 20% CPU-Last auf den Mindestwert von 10%
- gleichmäßigere Verteilung der CPU-Last auf alle Kerne durch Deaktivierung von CPU-Parking (Stromsparfunktion für Notebooks die auch bei jedem Desktop-Recher standardmäßig aktiviert ist)
- Beheben von kurzzeitigen Aussetzern durch den Multimedia-Klassen-Planer von Windows (Stichwort: NetworkThrottlingIndex) - http://support.microsoft.com/kb/948066
- Deaktivieren der standardmäßig reservierten 20% Bandbreite durch QoS

Wichtig:

Ihr nehmt diese Änderungen auf eigene Gefahr vor. Wir übernehmen keine Haftung für etwaige entstehende Schäden.

Wir möchten auch noch einmal besonders davor warnen, diesen Fix von anderen Quellen herunterzuladen. Es befinden sich bereits Versionen mit schadhaften Einstellungen im Umlauf. Diese können die Leistung eures PCs und eures Netzwerkzugangs negativ beeinflussen und zu schwerwiegenden System-Fehlern führen.

Diese Änderungen lassen sich nur unter Windows 7 vornehmen. Andere Windowsversionen benutzen veränderte Registrypfade, weshalb die Einstellungen dort keine Wirkung zeigen werden.

Schritt 1:

Start -> Alle Programme -> Zubehör -> Eingabeaufforderung -> Rechtsklick -> als Administrator ausführen

Jeden Befehl einzeln eingeben:

netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global congestionprovider=ctcp
netsh int tcp set global rss=enabled
netsh int tcp set global dca=enabled
netsh int tcp set global netdma=enabled
netsh int tcp set global chimney=enabled

Die Eingabe der Befehle sollte jeweils mit "OK." bestätigt werden.

Das CMD-Fenster kann nun geschlossen werden.

Um diese Änderungen wieder rückgängig zu machen, gebt ihr folgendes ein:

netsh int tcp set global autotuninglevel=normal
netsh int tcp set global congestionprovider=default
netsh int tcp set global rss=default
netsh int tcp set global dca=default
netsh int tcp set global netdma=default
netsh int tcp set global chimney=default

Schritt 2:

Ladet euch die .zip-Datei http://www.sourcejunkies.de/download/461 herunter.

Die .reg-Datei einfach doppelklicken.

Alle Registry-Einträge lassen sich mit der deinstall_fix.reg wieder auf die Standardwerte setzen.

Schritt 3:

Start -> regedit -> Rechtsklick auf regedit -> als Administrator ausführen

Durch das Menu an der linken Seite hangelt ihr euch bis zum Schlüssel

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces"

Im Schlüssel "Interfaces" müsst ihr nun den richtigen LAN-Adapter auswählen. Diesen erkennt ihr in der Regel daran, dass dieser deutlich mehr Einträge enthält als die übrigen Adapter.

Wir wollen allerdings auf Nummer sicher gehen und kontrollieren deshalb noch einmal die enthaltenen Einträge. Dazu gibt es, abhängig von eureren LAN-Einstellungen, zwei Wege.

1. Ihr bezieht euere IP-Adresse automatisch druch den Router
- Der Eintrag "DhcpIPAdress" sollte als Wert die IP eures Routers enthalten

2. Ihr habt manuell eine IP-Adresse gesetzt
- Der Eintrag "IPAdress" enthält eure eigene IP

Habt ihr den richtigen Adapter gefunden, geht ihr wie folgt vor:

1. Rechtsklick in das rechte Fenster -> Neu -> DWORD-Wert (32-Bit)
2. Neuer Wert #1 auswählen -> Rechtsklick -> umbenennen -> TcpAckFrequency eintragen
3. Doppelklick auf TcpAckFrequency -> Wert auf 1 setzen -> OK

4. Rechtsklick in das rechte Fenster -> Neu -> DWORD-Wert (32-Bit)
5. Neuer Wert #1 auswählen -> Rechtsklick -> umbenennen -> TcpDelAckTicks eintragen
6. Doppelklick auf TcpDelAckTicks -> Wert auf 0 setzen -> OK

Achtung:
Auch bei einem 64-Bit Windows wird der Wert als DWORD-Wert (32-Bit) eingetragen. Die Bitanzahl bezieht sich in diesem Fall ausschließlich auf die Länge der Wertes, NICHT auf die Windows-Version!

Der Registry-Editor kann nun geschlossen werden.

Schritt 4:

Nun geht es in die Systemsteuerung.

Start -> Systemsteuerung

Dort stellt ihr zunächst einmal oben Rechts im Fenster die Ansicht auf Große bzw. Kleine Symbole, da sich die folgenden Angaben auf diese Ansicht beziehen. Mit der Standardansicht Kategorie würden die Bezeichnungen sonst nich übereinstimmen.

Programme und Funktionen -> Windows-Funktionen aktivieren oder deaktivieren -> Haken bei Remoteunterschiedskomprimierung entfernen -> Mit OK bestätigen

Schritt 5:

Start -> Computer -> oben in der Leiste auf Systemeigenschaften -> oben links auf Geräte-Manager -> Ansicht -> Ausgeblendete Geräte anzeigen

Nun klappt ihr den Punkt Netzwerkadapter auf. Dort deaktiviert ihr folgende Einträge mit Rechtsklick -> Deaktivieren

Microsoft ISATAP Adapter
Microsoft ISATAP Adapter #2
Microsoft ISATAP Adapter #3
Microsoft 6zu4 Adapter
Teredo Tunnel

Dabei müssen nicht zwangsläufig alle Einträge vorhanden sein. Diese können sich nämlich je nach verbautem Netzwerkadapter unterscheiden.

Der Geräte-Manager kann nun geschlossen werden.

Schritt 6:

Start -> Computer -> links unten in der Leiste auf Netzwerk -> oben in der Leiste auf Netzwerk- und Freigabecenter -> oben links auf Adaptereinstellungen ändern

Dort wählt ihr euren LAN-Adapter aus. In der Regel sind diese mit "Lokales Netzwerk" oder "Local Area Connection" bezeichnet.

Rechtsklick -> Eigenschaften -> Haken bei QoS-Paketplaner und Internetprotokoll Version 6 (TCP/IPv6) entfernen -> Mit OK bestätigen

Schritt 7:

Computer herunterfahren. Wichtig: KEIN NEUSTART!!!

Nachdem der Rechner heruntergefahren ist, 5 bis 10 Sekunden warten.

Den Rechner starten. Der erste Bootvorgang kann in manchen Fällen recht lange dauern.
Je nach Windows 7 Version wird ein weiterer Reboot automatisch vorgenommen

Schritt 8:

Start -> Systemsteuerung -> Energieoptionen -> Höchstleistung auswählen -> Energiespareinstellungen ändern -> Erweiterte Energieeinstellungen ändern -> Prozessorenergieverwaltung aufklappen -> Prozessorleistung: Parken von Kernen - Kerne Minimal und Kerne Maximal auf 0 setzen -> Mit OK bestätigen -> Änderungen speichern
__________________________________________________________________________


Als nächstes die LMAA auch aus sourcejunkies (schöne bettlektüre)

von Gramma Gamingjunkiesadmin

__________________________________________________________________________

Keine Config der Welt sorgt dafür das besser oder mehr reingeht.

Sie kann:

-Eine bessere Ausgangsbasis schaffen
-Grafik auf das wesentliche ausrichten
-Eine konstantere Framerate erzielen
-Ein flüssigeres Gameplay ermöglichen.
-Bei keinem 5on5 werden mehr als 40kb/s benötigt (s. stats/netgraph) - rates über 50000/60000 sind absolut sinnfrei.
-Die FPS auf 999 zu setzen kann von keinem sachlich und technisch begründet werden.
-Die FPS stehen in einem direkten Zusammenhang mit der Client-Time und dienen als "Zeitstempel"
-Dieser "Zeitstempel" ist für die Clientseitigen Snapshots zur Tickrate und somit für die Prediction notwendig.
In vielen Uber1337 configs, Faq's oder Guides befinden sich "Urbane Legenden" die ihren Ursprung in mangelnden Englischkenntnissen haben.

Beispiel:

mat_colcorrection_disableentities - bei vielen High FPS Configs auf 0 um es "auszuschalten"

Dies ist eine "Disable" Funktion, die erst mit 1 aktiviert wird und somit ihre eigentliche Wirkung erzielt.

Der Wert 0 ist auch oft falsch genutzt, da dieser eine Funktion somit auf unendlich setzt.
Hier muss dann 0.001 bzw. 0.1 genutzt werden.


Es gibt einfach nur Netsettings.

Kein Pro der Welt hat "geht besser rein Netsettings"
Kein Pro der Welt kann mit seiner Config eure Latenz oder denn Ping verbessern.

Eure Bandbreite hat NICHTS mit eurem Ping zu tun!

Keine Manipulation von Router/Modem Firmware kann euch Fastpath oder eine bessere Anbindung ermöglichen.
Aber aber aber.... mein Ping ist dadurch um 15-20 niedriger!!!!
Falsch! Die gängigsten Router/Modemhacks machen in Wahrheit nichts anderes, als einen Schwellenwert hochzusetzen.
Dieser bestimmt ab wann ein Datenpaket vor dem Versenden nochmals kontrolliert und/oder überprüft wird.

Dadurch entlastet man die Recheneinheit im Router/Modem und lässt mehr fehlerhafte Datenpakete durch.

Die "Pingverbesserung findet somit noch vor dem eigentlichen Datenverkehr zwischen euch und dem Gameserver statt.

Sie hat keinerlei positiven Einfluss auf eure Internetanbindung. Im Gegenteil - ihr könnt sogar Probleme mit eurem Provider bekommen, da es zu Störmeldungen durch das "RAM" kommen kann. (Google: Rate Adaptive Mode)
Wenn man eine schlechte Anbindung hat:

Schrittweise die Rate um 2000 und die cmdrate um 2 runter - nicht unter die standart Werte gehen.

Sollte dies nicht ausreichen - die updaterate jeweils um 2 herunter setzen.

Passt dabei die inter_ratio an, um euren gewünschten lerp beizubehalten.
Sollte es Soundprobleme geben:

snd_mixahead schrittweite um 0.01 erhöhen.
FPSmax je nach Hardware auf 132 oder 264. ? Schaut am besten in der "Sammelsurium.txt" nach und macht euch selbst ein Bild davon.


Steamclient > Rechtsklick Counter-Strike Source > Eigenschaften > Startoptionen folgendes Eintragen:

-console -novid -32bit -nocrashdialog


Warum -32bit?

Selbst wenn ihr ein 64 Bit Betriebssystem habt, die Source-Engine ist 32Bit ONLY!!! Dieser Startparameter vermeidet einige Crashs und Bugs.


Warum -nocrashdialog?

Viele kennen und hassen ihn - den HL2.exe Bug wenn man das Game beendet. Dieser

Warum -nocrashdialog?

Viele kennen und hassen ihn - den HL2.exe Bug wenn man das Game beendet. Dieser kommt durch einen "memory could not be read" Fehler.
Dieser ist jedoch unbedeutend und einfach nur "nervig".

___________________________________________________________________________


Jetzt kommt der spannende teil LESEN UND VERSTEHEN!!

von Gramma Gamingjunkiesadmin

___________________________________________________________________________

Netcode/FPS:
Da die Source-Engine UDP und nicht TCP für die Übertragung der IP-Datenpakete verwendet und den Snapshot als Bit-Stream in einem IP-Paket versendet, kann man nicht von einem Datenstrom sprechen, vielmehr von einem sehr regelmäßigen "Bitstrom" oder "Datenimpuls".
Die Verbindung zwischen Client und Gameserver wird über die im UDP-Header eingetragene IP-Adresse und Portnummer hergestellt. Die Snapshots werden in einen Bitstrom umgewandelt und als Datensegment (UDP-OSI4) bei Tickrate 66 alle 15ms übertragen.
Da UDP zur Schonung der Latenz und Bandbreite keine Kontrollfunktionen enthält und die Datensegmente nicht Nummeriert werden, wird die Client-Frametime als Zeitstempel für die serverseitige Simulation genutzt.
Jedes einzelne Frame, das man als Client rendert, definiert die sogenannte Client-Frametime.
Nur so kann der Server durch seinen Algorithmus bestimmen, wie viel er predicten muss und vom Lag bzw. der Roundtrip-Time ausgleichen darf.
Mit cl_interp bestimmt man den Abstand zwischen dem eigentlichen "Zeitstempel" des Spielers und der Grafik, die man auf seinem Monitor sieht, in Millisekunden.
Die Client-Time abzüglich des interp ist der Wert für die Interpolation aller Objekte und Models, den sog. "World-Entities", auf der Map.
Daher sollte man die Framerate nicht nur durch fps_max möglichst gleichmäßig halten, sondern auch gerade Zahlen verwenden.
Die Urban-Legend, dass man als Ausgleich für die Anzeige im Netgraph bei fps_max immer +1 addieren soll, wurde schon mehrfach von Valve schriftlich widerlegt.
Da der Netgraph nicht auf- oder abrundet, sondern die Nachkommastellen abschneidet, entsteht dort ein Fehler in der Anzeige. (Nachprüfbar mit Consolenbefehl "Stats")


Der Server simuliert die Map bei Tickrate 66 kontinuierlich in Abständen von 15ms und erzeugt einen Tick (1000 ms : Tickrate 66 ≈ 15 ms).
Dabei werden die eingehenden Befehle durch den Spieler verarbeitet, simuliert und die neuen Informationen entsprechend auf alle Spieler, Tonnen, Waffen, usw. angewendet.
Basierend auf diesen Informationen, entscheidet der Server, ob er einen Snapshot überhaupt erst generiert und die Spieler über die Veränderungen auf der Map informiert werden.
Da ständig etwas "passiert", wird in der Regel zu jedem Tick ein Snapshot erzeugt und der Server sendet, limitiert durch die cl_updaterate, die Snapshots an den Spieler (z.B. cl_updaterate "47" = 47 von 66 Snapshots, die der Server an den Spieler schicken darf).
Durch die Tickrate bestimmt der Server, wie viele Client-Snapshots in der Sekunde von den Maus und Tastatureingaben der Spieler gemacht werden.
Als Spieler bestimmt man mit cl_cmdrate, wie viele der Client-Snapshots in der Sekunde an den Server übertragen werden (z.B. cl_cmdrate von 33 bei einer serverseitigen Tickrate von 66 = 2 Snapshots je Paket).
Durch die Latenz bzw. Roundtrip, die bei dem Senden und Empfangen der Snapshots entsteht, muss der Server immer mit "verspäteten" Daten des Spielers arbeiten.
Je grösser und je unterschiedlicher die Latenzen zwischen Spieler und Server sind, umso schwieriger wird es für die Engine, diese Unterschiede auszugleichen.
Mit jedem gerenderten Grafik-Frame wird zusammen mit dem zuletzt empfangenen Snapshot der "Zeitstempel" neu gesetzt.
Man hat zwar die Möglichkeit hohe "Rate" Werte zu setzen, diese ergeben aber im Fall von CS:S keinen Sinn. Die Rate wird in Byte die Sekunde angegeben. Der erste Wert bei in/out im Net Graph zeigt die Größe des zuletzt empfangenen Snapshots in Byte. Daneben ist die durchschnittliche Datenmenge die man in Kilobyte die Sekunde angezeigt bekommt.
In der Regel kommt man bei einem 5on5 insgesamt nicht über 25 Kilobyte die Sekunde. Selbst wenn man von 30kb/s ausgehen würde, kommt man nicht über eine Rate von 30720 hinaus.


Theoretisch ist cl_interp im Optimalfall gleich dem Zeitabstand zwischen den einzelnen Ticks.
Daher wird bei cl_interp "0" und cl_interp_ratio "1" immer durch die Engine der Wert mit 1000ms : Tickrate XX = cl_interp 0.0XX errechnet.
Praktisch hat man aber leider kein 5on5, in dem jeder Spieler den gleichen Ping, Netsettings oder eine konstante Framerate hat.
Die "Notwendigkeit" von cl_interp ist auch dafür verantwortlich, dass ein sich bewegender Spieler, einen stehenden Gegner etwas früher sehen kann.
Durch cl_predict wird eine "Wahrscheinlichkeit" der nächsten Eingabe des Spielers berechnet. Dies gleicht den Zeitverzug zwischen den Befehlen des Spielers und der grafischen Darstellung aus, die durch die Verbindung zwischen Spieler und Server entsteht.
Bei dem Thema Prediction hat der Server immer noch das letzte Wort und da man zu Gunsten der Bandbreite, immer nur über den auf dem Monitor zu sehenden Ausschnitt der Map einen Snapshot erhält, kann dies nicht auf Seiten des Spielers berechnet werden.
Dies verursacht unter anderem auch diese kurzzeitigen "Speedhack" Momente. (ka wie ich es sonst bezeichnen soll^^)
Die Wurzel allen Übels steckt jedoch in der serverseitigen Lag-Compensation.
Diese errechnet sich aus dem Zeitstempel des Spielers zwischen den zuletzt empfangenen Snapshots des Servers und der gerenderten Frames, abzüglich des angezeigten Pings in der Console.
Da der Ping durch die Paketumlaufzeit bestimmt wird, kann es besonders bei Gameservern, die weiter entfernt sind, zu einer asymmetrischen Übertragung der Datenpakete kommen.
Auf Deutsch weil die Honks östlich und westlich von Deutschland ohne Cisco-Live Support ihre Border- und Provider Gateway Protokolle nicht anständig hinbekommen, benötigt ein Datenpaket zum Server weniger Zeit, als vom Server zum Spieler zurück.
Dadurch kommt die Lag-Compensation ins "Schwitzen" und es kommt zu "Durchschüssen" und "um-die-Ecke-holen".
Jetzt stellen wir uns alle mal für einen Moment vor, wir wären ein Gameserver und könnten mit einer stromtypischen Lichtgeschwindigkeit, die Datenpakete betrachten. Da werden schon Differenzen von 10 Millisekunden, zu einer nicht zu unterschätzenden Problematik.
Ergo: Der Ping/Round-Trip-Time hat sehr wohl etwas mit der "Treffbarkeit" zu tun.

Grundsätzlich macht die Interpolation des Spiels nichts anderes, als die grafische Ausgabe der empfangenen Daten um Wert x zu verzögern und die Eingaben von Tastatur und Maus um Wert x zurückzurechnen, bevor die eigenen Daten gesendet werden.
Bei einer Tickrate von 66 berechnet der Server 66 mal pro Sekunde, was auf der Map passiert. Das heißt einmal alle ~ 15 ms.
Wenn man nun ein Vielfaches von 66 als fps_max Wert nimmt, spiegelt jedes vom Monitor dargestelle Vollbild einen Tick des Server wieder. Man erhält die Daten vom Server also wirklich zu dem Zeitpunkt, zu dem die Engine diese für die weitere Verarbeitung benötigt.
Nimmt man einen anderen Wert für fps_max, zeigt nur jedes zweite oder dritte Bild des Monitors einen echten Tick des Servers. Die grafische Darstellung der Models, die Eingaben von Maus und Tastatur usw. sind also nicht echt sondern müssen aus den Daten des vorherigen Ticks interpoliert werden.
Dabei können a) Fehler auftreten, da die errechneten Daten nicht mit den tatsächlichen Übereinstimmen oder b) Pakete zu spät oder in falscher Reihenfolge beim Server ankommen. gerade bei Gegner aus dem Ausland mit höherem Ping tritt letzteres gerne mal auf.
Wenn die Paketumlaufszeit asynchron ist (Server -> Client schneller als Client -> Server) oder der Pingunterschied zu groß wird (10 ms vs. 80 ms etc.) kommen die Pakete entweder in falscher Reihenfolge oder eben einfach nicht zur richtigen Zeit an.

_____________________________________________________________________________

Geklaut von mT:

Hat bei mir geholfen was minilaggs angeht:
____________________________________________________________________________

Ich habe merkwürdige Minilags. Aber irgendwie hängt das mit meinem XboX-Controller zusammen, glaube ich

Das stimmt. Dazu hat der Besitzer der Seite www.sourcejunkies.de (grammaton) einen interessanten Thread eröffnet: http://www.sourcejunkies.de/forum/thread/6274/page/1/
Probiert einfach mal aus, was er schreibt… XboX Controller abstöpseln und die HID-Elemente deaktivieren bzw. deinstallieren, wenn ihr euch sicher seid.

Werft auch einen Blick darauf, wenn ihr Hardware nutzt, die z.B. Displays haben (G15-Tastatur von der Logitech).


zur behebung: siehe letzter post von mir http://www.sourcejunkies.de/forum/thread/6274/page/1/

____________________________________________________________________________