ORG

(Based on http://www.gameadmins.com/guides/q3/q3lagometer.htm).



Zalecam czytać ten artykuł wraz z artykułem Więcej O Komendach Połączenia.

Żeby przeprowadzić efektywną grę na publicznym serwerze konieczna jest dobra jakość połączenia, czyli niski i stabilny ping. Jeśli ping jest stabilny, to za niski uważa się w okolicach 40-80. Ważniejsza jest właśnie stabilność niż wysokość, ponieważ zdecydowanie lepiej gra się na stałym pingu 150 niż na skokach 40-200. Przeglądarka serwerów Quake'a3 używa czterech kolorów określających wysokość pingu:

1. 
   
2. 1-200 - ping najniższy.
   
3. 200-400 - ping średni, chociaż w rzeczywistości za wysoki do gry.
   
4. 400-999 - ping zbyt wysoki do gry.
   
5. 376 - kolor niebieski informuje o tym, że nasz ping jest wyższy od maksymalnego dozwolonego pingu na serwerze, określonego komendą sv_maxping (domyślnie 0).
   

Quake3 jest wyposażony w kilka komend mogących poprawić jakość połączenia, oczywiście w rozsądnych granicach, np. cl_maxpackets, rate, snaps. Więcej o nich można doczytać w osobny artykule, jednak nie ma jednoznacznej reguły na poprawienie pingu dla każdego rodzaju połączenia i trzeba sporo eksperymentować, żeby osiągnąć jakieś wyniki.
Bardzo dobrym narzędziem diagnostycznym do badania jakości połączenia w czasie gry jest wbudowany w Quake3 tzw. lagometer. Jest on uaktywniany poleceniem cg_lagometer 1, które wyświetla w prawym dolnym rogu HUD'a podwójny wykres pingu, kiedy gramy jako klient (w osp też jeśli gramy jako serwer). Jest to urządzenie skomplikowane, ale postaram się je w zarysie przybliżyć.
Do jego zrozumienia konieczna jest znajomość kilku pojęć i komend (wyróżnionych slashem):

• 
  
• fps - frames per second, liczba klatek na sekundę, renderowana na ekranie naszego komputera, zależna od jakości sprzętu.
  
• /com_maxfps - komenda ograniczająca maksymalną ilość klatek na sekundę; domyślnie 85.
  
• snapshot - klatka stanu gry wysyłana przez serwer; ilość wysyłanych klatek na sekundę jest określona poleceniem sv_fps, domyślnie 20, a ilość klatek przyjmowanych przez klienta kontroluje komenda snaps, domyślnie również 20.
  
• /sv_fps - określa ilość snapshotów na sekundę, jaką będzie wysyłał serwer, domyślnie 20.
  
• /snaps - określa liczbę snapshotów na sekundę, jaką będzie akceptował klient, domyślnie 20.
  
• /sv_maxrate - określa maksymalną szybkość wymiany danych między serwerem a klientem, domyślnie 0 (bajtów na sekundę); dot. serwera.
  
• /rate - określa szybkość wymiany danych między klientem a serwerem, domyślnie 3000 bajtów na sekundę.
  
• ping - ilość milisekund jaką potrzebuje wysłany przez klienta pakiet informacji na dojście do serwera i powrót.
  
• hitch - jest to ping właściwy serwerowi, jednak nie umiem go dokładnie zdefiniować.
  

Lagometer składa się z dwóch wykresów - górnego i dolnego:

Górny wykres

Górny wykres dotyczy zarówno serwera i klienta i mogą na nim wystąpić jedynie dwa kolory - niebieski i żółty. Prawidłowa sytuacja to szybko płynąca niebieska linia, kiedy klatki na komputerze klienta (fps) są zsynchronizowane w czasie z otrzymywanymi snapshotami serwera - klatkami stanów gry. Niebieska część wykresu biegnie zawsze pod linią bazową. Jeśli odbiega daleko od linii bazowej znaczy to, że snapshoty nie są zsynchronizowane z renderowanymi klatkami. W przypadku szybkich komputerów z wysokim com_maxfps będzie to normalne, ponieważ ilość snapshotów otrzymywanych na sekundę od serwera wynosi domyślnie 20, a aktualny fps może przekraczać 70 i liczba snaps nie musi być zawsze dzielnikiem aktualnego fps. Odbiegająca niebieska linia nie ma jednak prawie wpływu na obecność laga.

Żółte fragmenty wykresu oznaczają, że snapshoty są gubione przez serwer, co nie zależy od klienta. W takim przypadku powinno pomóc obniżenie snaps. Jeśli serwer gubi snapshoty, obniżenie snaps do 10 spowoduje, że klient będzie akceptował tylko co drugi snapshot (zaleca się używanie wielokrotności 10 w tej komendzie lub dzielnika sv_fps), co przywróci synchronizację. Podobny skutek, chociaż inny mechanizm będzie miało zwiększenie średniej ilośći klatek na sekundę, czyli zwiększenie wydajności komputera, co jednak zwykle nie jest to już możliwe lub też zmniejszenie wartości com_maxfps. Żółte fragmenty górnego wykresu mogą posiadać kształt trójkątny lub prostokątny, jednak nie jest wyjaśniona różnica między tymi kształtami.
Wykres zawsze przesuwa się o jeden piksel na jedną renderowaną klatkę, czyli szybkość przesuwania jest wprost proporcjonalna do aktualnego fps naszego komputera.

Niewłaściwe funkcjonowanie serwera w praktyce obrazują poniższe przypadki i jak widać pociągają one za sobą również lagi po stronie klienta:

	1. Prawidłowa sytuacja po stronie serwera - gra ciągła.			2. Zgubiony snapshot, który odbił się w postaci laga po stronie klienta.
	3. Całkowicie zgubiona seria snapshotów, co wyraźnie odbija się na lgu klienta.			4. Podobna sytuacja, ale bardziej wyraźna.
	5. Długa seria gubionych snapshotów, co powoduje efekty 'warpowania' modeli.			6. Serwer zatrzymany - brak akcji.

Dolny wykres

Dolny wykres jest odpowiedzialny za połączenie klienta, co określają trzy kolory - zielony, żółty i czerwony. Stabilność pingu obrazuje równa zielona linia, natomiast jego wysokość odzwierciedla wysokość zielonej linii. Żółta linia oznacza, że pakiety wysyłane przez klienta są odrzucane. Jeśli jest to stałe zjawisko, można mu zapobiec zwiększając rate lub obniżającsnaps. Czerwona linia oznacza utracony pakiet (czyli wyraźny lag) i jest wynikiem złej jakości połączenia, na co nie mamy wpływu. Można jeszcze eksperymentować w takim wypadku z komendami opisywanymi w poprzednim artykule, ale z pewnością nie damy rady przywrócić wykresu lagometru do zielonego.

Wykres przesuwa się o jeden piksel na jeden otrzymany snapshot. Ponieważ domyślnie klient otrzymuje 20 snapshotów, a aktualny fps jest zwykle większy od 20, więc górny wykres będzie przeważnie przesuwał się szybciej.

Na poniższych przykładach widać, że funkcjonowanie serwera jest prawidłowe, natomiast wszelkie problemy leżą po stronie klienta.

	1. Idealna sytuacja - gra lokalna z pingiem 0-10.			2. Stabilny ping poniżej 100.
	3. Stabilny ping poniżej 100 oraz wymiana ognia między graczami.			4. Stabilny ping w okolicach 100, dynamiczna akcja.
	5. Niewielki lag.			6. Niewielki lag o charakterze statycznym.
	7. Stabilny ping poniżej 200.			8. Stabilny ping w okolicach 300.
	9. Lag o charakterze dynamicznym.			10. Bardzo dynamiczny lag.
	11. Klient ledwo utrzymuje połączenie, ping w okolicach 900.			12. Ostrzeżenie o rozłączeniu, ping powyżej 999.

Efekt zmiany opisywanych wyżej komend jest natychmiastowy, więc od razu widać czy obniżenie snaps, rate czy com_maxfps spowoduje ustabilizowanie się lagometru. Moje osobiste doświadczenia pokazują, że w niewielkim stopniu można stabilizować ping przy ich użyciu.



© by [RvG]Rozz 2000-2002