Poziom wyjścia: jak wyglądają spadki FPS i zły frametime w Microsoft Flight Simulator
FPS a frametime – dwa różne wskaźniki tej samej płynności
FPS i frametime opisują to samo zjawisko z dwóch stron. FPS (klatki na sekundę) to liczba wygenerowanych klatek w ciągu sekundy. Frametime to czas, ile milisekund zajmuje wyrenderowanie pojedynczej klatki. 60 FPS to frametime około 16,6 ms, 30 FPS to około 33,3 ms. Najważniejsza różnica praktyczna: FPS może być „ładny” na liczniku, a frametime poszarpany, co skutkuje mikroprzycięciami.
W Microsoft Flight Simulator typowa sytuacja: licznik pokazuje stabilne 50–60 FPS, ale przy szybkim obrocie kamery obraz „rwie”. To znak, że kolejne klatki nie dochodzą w równych odstępach czasu. Dwie sekundy mogą wyglądać tak: kilka klatek po 10 ms, potem nagle jedna po 40 ms, za chwilę znów seria po 15–20 ms. Średni FPS utrzyma się na przyzwoitym poziomie, ale wrażenie płynności będzie słabe, szczególnie w VR i na monitorach z niskim input lagiem.
Drugi scenariusz: niski, ale stabilny FPS. Przykład: stałe 30 FPS z blokadą w RTSS lub w grze, bez większych skoków frametime. W locie IFR na trasie, przy braku gwałtownych manewrów, taki setup bywa znacznie przyjemniejszy niż „pływające” 45–60 FPS z ciągłymi drobnymi szarpnięciami. Kryterium jakości płynności: nie sama wartość FPS, ale stabilność frametime.
Punkt kontrolny: jeśli gołym okiem widać szarpanie mimo liczników pokazujących „ładne” FPS, należy natychmiast przejść na analizę frametime. Jeżeli natomiast FPS jest konsekwentnie niski w każdej sytuacji (małe lotnisko, pustynia, ocean), zwykle chodzi o ogólny brak mocy lub źle dobrane globalne ustawienia, a nie pojedyncze wąskie gardło.
Typowe objawy w MSFS: stuttering, doczytywanie, opóźniony kokpit
Microsoft Flight Simulator generuje specyficzne obciążenia: fotogrametria, AI traffic, streamowanie danych z sieci, dynamiczna pogoda, skomplikowane kokpity. Każdy z tych elementów daje inny wzór frametime, co widać w logach.
Charakterystyczne symptomy:
Stuttering przy zakrętach – szybki obrót kamery przez obszar z gęstą zabudową (Londyn, Nowy Jork, fotogrametria) powoduje sekwencję ostrych pików frametime. FPS może spaść o kilka–kilkanaście klatek tylko na ułamek sekundy. Sygnał ostrzegawczy: widoczna „drabinka” w wykresie frametime, mimo stabilnego obciążenia GPU.
Przycięcia przy podejściu do lądowania – w okolicach krótkiej końcówki podejścia symulator intensywnie doładowuje teren, AI traffic, tekstury lotniska i pojazdy naziemne. To klasyczny moment, gdy I/O i CPU nagle dostają skokowego obciążenia. W logach widać wtedy pojedyncze klatki z frametime kilkukrotnie wyższym niż średnia.
Szarpy przy zmianie pogody – dynamiczna pogoda, szczególnie burze i gęste chmury, gwałtownie podbijają obciążenie GPU. Na frametime pojawia się wyraźna fala: kilka–kilkanaście sekund z wyższymi wartościami, potem stabilizacja. Jeśli GPU wchodzi na 99–100%, a VRAM zbliża się do limitu, problem jest głównie po stronie karty graficznej.
Mikroprzycięcia przy doczytywaniu fotogrametrii – krótkie, ale częste „szarpnięcia” co kilka–kilkanaście sekund nad dużymi miastami. Licznik FPS niemal się nie zmienia, ale frametime co jakiś czas wyskakuje w górę. W logach widać szpilki użycia dysku i sieci, podczas gdy CPU i GPU pozostają na zbliżonym poziomie.
Jeśli takie objawy występują tylko w określonych sytuacjach (zawsze na dużym lotnisku, nigdy nad oceanem), pierwszym krokiem diagnostycznym powinno być odtworzenie ich w kontrolowanych warunkach i zapis logów frametime. Bez tego każda korekta ustawień będzie strzałem na ślepo.
Stały niski FPS kontra nagłe dropy – inne podejście do diagnozy
Stały niski FPS w MSFS sugeruje, że konfiguracja jest zbyt ambitna dla danego sprzętu lub istnieje stałe ograniczenie: słaby CPU w scenariuszu MainThread, GPU pracujące non stop na 100%, zbyt agresywny render scaling. Charakterystyczny wzór: frametime dość równy, ale wysoki (np. 30–40 ms) przez cały lot.
Nagłe dropy FPS wyglądają inaczej: przez długi czas płynność jest akceptowalna, po czym pojawiają się krótkie epizody spadków: z 50 do 15 FPS przez jedną–dwie sekundy, często z towarzyszącym „przyklejeniem” obrazu. W frametime rejestruje się to jako pojedyncze lub serię skoków do wartości kilkukrotnie wyższych niż średnia. Ich przyczyny to często:
doczytywanie zasobów z dysku (słaby HDD, brak miejsca, fragmentacja, przepełniony NVMe),
skoki obciążenia CPU przy generowaniu AI traffic, streamowaniu danych lub obsłudze dodatków,
thermal throttling CPU lub GPU – w logach widać nagłe obniżenie taktowań i wzrost frametime.
Punkt kontrolny: jeśli FPS jest stale niski, priorytetem jest dostosowanie globalnych ustawień do możliwości sprzętu. Jeśli FPS jest zazwyczaj dobry, lecz co jakiś czas następują gwałtowne dropy, nie ma sensu od razu obniżać wszystkiego; potrzebna jest precyzyjna identyfikacja momentów szarpnięć w logach frametime oraz powiązanie ich z aktywnością CPU, GPU, dysku i sieci.
Minimalny zestaw narzędzi diagnostycznych: co jest konieczne, a co opcjonalne
Warstwa symulatora: DevMode i wbudowany FPS counter
Microsoft Flight Simulator ma rozbudowane narzędzie diagnostyczne w postaci DevMode i panelu „Display FPS”. Jest to pierwszy punkt kontrolny przed instalacją czegokolwiek z zewnątrz. DevMode pokazuje, czy ograniczeniem jest MainThread, GPU czy inny komponent wewnątrz symulatora.
Kluczowe cechy DevMode:
Minimalny narzut – wpływ na wydajność jest niewielki, więc pomiary są wiarygodne.
Bezpośrednie wskaźniki MSFS – pola MainThread, GPU, manipulatory i inne pokazują dokładnie, w którym etapie pipeline’u renderowania występuje opóźnienie.
Tryb obserwacyjny – pozwala na szybkie tworzenie i odtwarzanie scenariuszy testowych (ten sam samolot, lotnisko, pora dnia, warunki pogodowe).
Jeśli użytkownik nie korzysta z DevMode i diagnozuje wyłącznie na podstawie ogólnego licznika FPS (np. z GeForce Experience), przeoczy kluczowy sygnał: czy wąskim gardłem jest CPU (MainThread), GPU, czy np. manipulatory związane z kokpitem. Brak tej informacji utrudnia każdą dalszą decyzję optymalizacyjną.
Drugi poziom monitoringu to warstwa systemowa. MSI Afterburner wraz z RivaTuner Statistics Server (RTSS) umożliwia podgląd oraz logowanie do pliku szeregu metryk: FPS, frametime, zużycie GPU, CPU, RAM, VRAM, temperatury i taktowania. Kluczowy jest tu nie tylko overlay, ale też możliwość precyzyjnego logowania w tle.
Do dokładniejszej analizy frametime przydaje się CapFrameX lub podobne narzędzie, które potrafi:
wczytać pliki CSV z Afterburnera,
pokazać szczegółowy wykres frametime,
wyliczyć wskaźniki typu 1% low, 0.1% low, percentyle frametime,
porównać dwa przebiegi testowe (np. przed i po zmianie ustawień).
Dodatkowo HWInfo umożliwia bardzo szczegółowy podgląd parametrów sprzętowych, w tym:
rzeczywiste taktowania wszystkich rdzeni CPU,
wskazania thermal throttling, power limit, voltage limit,
przepustowość magistral, transfery dyskowe, temperatury poszczególnych komponentów.
Punkt kontrolny: pełna diagnoza spadków FPS jest możliwa dopiero, gdy obok DevMode działają logi z Afterburnera/HWInfo lub CapFrameX. Jeśli użytkownik opiera się tylko na jednym wskaźniku (np. obciążenie GPU), istnieje wysokie ryzyko fałszywej diagnozy.
Warstwa systemu Windows i sterowników
Trzeci komponent diagnostyki to wbudowane narzędzia Windows oraz panele sterowników GPU. Menedżer zadań pozwala szybko sprawdzić, czy tło nie jest obciążane przez procesy niezwiązane z symulatorem: aktualizacje systemu, skanowanie antywirusem, overlay innych programów.
Podgląd zdarzeń w kategorii „System” i „Aplikacja” pomaga zidentyfikować krytyczne błędy sterowników GPU, problemy z dyskiem czy stabilnością systemu, które mogą objawiać się losowymi stutterami lub krótkimi freezami.
globalne limity FPS lub tryby zarządzania energią,
profil specyficzny dla MSFS, który może nadpisywać ustawienia gry.
Punkt kontrolny: jeśli narzędzia systemowe wskazują wysokie obciążenie dysku lub nieoczekiwane procesy CPU podczas lotu, dalsza optymalizacja ustawień gry bez uporządkowania systemu będzie nieskuteczna.
Kryteria wyboru narzędzi monitorujących i logujących
Przed zainstalowaniem stosu programów monitorujących sensownie jest nałożyć kilka wymagań jakościowych:
Możliwość logowania do pliku – absolutne minimum. Overlay jest przydatny, ale do szczegółowej analizy potrzebne są dane historyczne, nie subiektywne wrażenia.
Dokładność pomiaru frametime – narzędzie musi rejestrować próbki z wystarczającą częstotliwością (rzędu kilkudziesięciu pomiarów na sekundę) i nie może nadmiernie wygładzać danych.
Niski narzut na wydajność – jeżeli samo narzędzie monitorujące powoduje spadek FPS o kilka–kilkanaście klatek, wyniki są zafałszowane. W takiej sytuacji należy ograniczyć zakres monitorowanych metryk lub użyć innego programu.
Overlay z możliwością konfiguracji – ważne, aby dało się wybrać tylko kluczowe wskaźniki, zmniejszyć rozmiar czcionki oraz ustawić overlay tak, by nie zasłaniał istotnych części kokpitu.
Punkt kontrolny: jeżeli narzędzia nie oferują logowania frametime do pliku, a jedynie prosty licznik FPS, diagnoza spadków będzie oparta na domysłach. Jeżeli overlay monitorujący zajmuje dużą część ekranu i sam generuje spadki wydajności, trzeba go natychmiast uprościć lub ograniczyć wyłącznie do logowania w tle.
Źródło: Pexels | Autor: Martin Lopez
DevMode i Display FPS w Microsoft Flight Simulator: konfiguracja i odczyt
Włączanie DevMode i przygotowanie scenariusza testowego
Aby DevMode był użyteczny diagnostycznie, musi działać w powtarzalnych warunkach. Pierwszy krok to włączenie DevMode w ustawieniach symulatora (General Options → Developers → Developer Mode → On). Po włączeniu, w górnej części ekranu pojawi się pasek menu developerskiego.
Następnie należy:
otworzyć z menu DevMode pozycję Options i upewnić się, że ścieżki do zapisów projektów nie kolidują z typową pracą gry,
w menu DevMode wybrać Options → Display FPS, co uruchomi w lewym górnym rogu okno z rozbudowanymi statystykami FPS i czasów w ms,
przygotować „profil testowy”: ten sam samolot (np. domyślny A320), to samo duże lotnisko (np. EGLL), ta sama pora dnia i warunki pogodowe (Clear Skies lub ustalone preset). To będzie scenariusz bazowy do wszystkich porównań.
Ważny punkt kontrolny: minimum jedna trasa testowa powinna być identycznie odtwarzana przed i po każdej zmianie ustawień. Bez takiego baseline trudno jednoznacznie stwierdzić, czy konkretna korekta przyniosła poprawę czy nie.
Interpretacja kluczowych pól w panelu Display FPS
Display FPS prezentuje kilka pól, które są absolutnie kluczowe przy diagnostyce:
FPS – ogólna liczba klatek na sekundę.
Frame time (ms) – czas na wygenerowanie pojedynczej klatki; to ten wskaźnik powinien być monitorowany w pierwszej kolejności.
MainThread (ms) – czas przetwarzania głównego wątku symulatora (logika, fizyka, AI, część renderowania CPU). Gdy MainThread ma najwyższy czas, w panelu często pojawia się etykieta „Limited by MainThread”.
GPU (ms) – czas pracy karty graficznej na klatkę. Jeśli GPU jest najwolniejszym elementem, zobaczysz „Limited by GPU”.
Manipulators – czas związany z obsługą kokpitu, interakcji, instrumentów; jego skoki mogą wskazywać na ciężkie dodatki lub nieoptymalne panele.
Latency – ogólne opóźnienia, przydatne głównie w analizie VR i input lagu.
Rozpoznawanie limitu CPU, GPU i problemów z I/O na podstawie DevMode
Display FPS potrafi bardzo precyzyjnie wskazać, co faktycznie hamuje symulator. Zanim zostanie uruchomiony zewnętrzny monitoring, trzeba wyciągnąć maksimum informacji z tego jednego okna.
Podstawowy podział wygląda następująco:
Limited by MainThread – główny wątek CPU jest przeciążony; typowe przy gęstym ruchu AI, ciężkim lotnisku i dużej ilości dodatków.
Limited by GPU – karta graficzna pracuje na granicy możliwości; często przy wysokiej rozdzielczości, wysokim TLOD/LOD i ostrym antyaliasingu.
Brak wyraźnej etykiety limitu przy jednoczesnych skokach frametime – sygnał, że może chodzić o I/O (dysk, streamowanie danych) lub procesy w tle.
Przy diagnozie nie chodzi tylko o to, kto jest „limiterem”, ale jak wygląda stabilność poszczególnych pól:
jeżeli MainThread (ms) rośnie skokowo w pobliżu lotnisk lub przy zmianie widoku, a GPU (ms) pozostaje stosunkowo stabilne, to klasyczny przypadek wąskiego gardła po stronie CPU,
jeżeli GPU (ms) stale oscyluje wokół jednej wartości, ale cały wykres jest „poszarpany”, trzeba szukać dodatkowego stutteru w I/O lub w overlayach,
jeżeli oba czasy (MainThread i GPU) mają losowe piki, a jednocześnie widać dogrywanie tekstur/terenów, często w tle działa przeładowany dysk lub brakuje wolnej pamięci RAM/VRAM.
Punkt kontrolny: jeżeli Display FPS konsekwentnie wskazuje „Limited by MainThread”, obniżanie wyłącznie ustawień graficznych (cieni, filtrowania, AA) przyniesie niewielki zysk. Jeżeli z kolei „Limited by GPU” pojawia się w każdej sytuacji, dalsze zwiększanie rozdzielczości renderowania lub TLOD to prosta droga do niestabilnego frametime.
Łączenie obserwacji DevMode z odczuwalnością stutterów
Czyste liczby to jedno, a subiektywne szarpnięcia podczas lotu – drugie. Zestawienie obu źródeł informacji pozwala szybko ocenić, czy problem dotyczy stałego przeciążenia, czy krótkich, ale dokuczliwych dropów.
Przy każdym zauważalnym „szarpnięciu” dobrze jest zwrócić uwagę na trzy elementy w okienku Display FPS:
czy nastąpił nagły pik w MainThread (ms) o kilka–kilkanaście ms,
czy jednocześnie pojawiła się zmiana w Manipulators (np. otwarcie ciężkiego panelu w kokpicie, przełączenie widoku),
czy w momencie stutteru nastąpiło dogranie fotogrametrii, zmian pogodowych lub gęstego ruchu online.
Jeżeli każde szarpnięcie jest powiązane z dużymi skokami MainThread, mamy do czynienia głównie z przeciążeniem CPU. Jeśli natomiast wartości czasów CPU/GPU są względnie stałe, a stuttery pojawiają się np. przy dolotach do miast fotogrametrycznych, zwykle wina leży po stronie I/O lub sieci.
Punkt kontrolny: jeżeli stuttery pojawiają się bez wyraźnej reakcji w polach MainThread/GPU, trzeba wyjść poza DevMode i przejść do logowania zewnętrznego – inaczej ryzyko błędnej diagnozy (np. obwiniania „silnika gry”) jest bardzo wysokie.
Typowe błędy przy korzystaniu z DevMode i jak ich uniknąć
DevMode jest narzędziem diagnostycznym, ale niewłaściwie używany sam potrafi wprowadzić zamieszanie. Kilka nawyków znacząco poprawia wiarygodność odczytów:
Nadmiar otwartych okien DevMode – wiele paneli (Scenery Editor, Aircraft Editor, konsola) otwartych jednocześnie generuje zbędny narzut. Do diagnostyki FPS wystarcza wyłącznie panel Display FPS.
Testy bez pełnego załadowania sceny – ocena FPS tuż po załadowaniu lotu, gdy w tle dogrywają się tile’e fotogrametrii i AI, pokaże gorszy obraz niż stabilny lot po kilku minutach. Minimum to 2–3 minuty stabilnego lotu przed oceną.
Zmiany ustawień „w locie” bez restartu sesji – niektóre parametry (np. TLOD, traffic) wymagają pełnego przeładowania, aby wynik był rzetelny. Brak restartu prowadzi do mylnych wniosków o faktycznym wpływie danego suwaka.
Punkt kontrolny: jeżeli panele DevMode są otwierane „na żywioł”, a testy wykonuje się tuż po starcie lotu, logika „przed/po zmianie ustawień” staje się niewiarygodna. Minimum to jeden prosty, powtarzalny scenariusz i pojedynczy aktywny panel Display FPS.
MSI Afterburner i RTSS: konfiguracja krok po kroku pod kątem frametime
Instalacja i pierwsze uruchomienie w trybie „minimum ingerencji”
MSI Afterburner i RTSS muszą być skonfigurowane tak, aby monitorować, a nie wpływać na pracę symulatora. Pierwsze uruchomienie trzeba potraktować jak audyt narzędzia:
podczas instalacji zaznaczyć zarówno MSI Afterburner, jak i RivaTuner Statistics Server,
po instalacji uruchomić Afterburnera i przejść do Settings → General,
wyłączyć automatyczne podkręcanie/korekcję napięć – celem jest monitoring, nie overclocking,
zaznaczyć opcję uruchamiania z Windows (jeśli diagnoza ma być prowadzona wielokrotnie) i działanie w tle.
Na tym etapie nie ma sensu ustawiać skomplikowanych profili. Narzędzie ma zbierać dane i nie dotykać zegarów GPU/CPU, dopóki nie zostanie zidentyfikowany problem.
Punkt kontrolny: jeżeli Afterburner jest używany jednocześnie do podkręcania i monitoringu w fazie diagnozy, każda niestabilność (crashe, freezy, power limit) stanie się trudna do przypisania jednemu źródłu. Minimum to stabilny, domyślny profil GPU/CPU podczas zbierania pierwszych logów.
Wybór metryk do monitoringu: co jest kluczowe przy spadkach FPS
Afterburner oferuje dziesiątki wskaźników, ale ich nadmiar w overlayu generuje więcej szkody niż pożytku. Dla MSFS wystarcza kilka podstawowych grup danych:
CPU: użycie całkowite i użycie wybranych rdzeni (jeśli planowana jest analiza per-core), temperatura, taktowanie,
Pamięć: zajętość RAM (systemowej),
Frametime i FPS: kluczowa para dla oceny płynności,
I/O (opcjonalnie): obciążenie dysku, jeśli Afterburner lub inne narzędzie to wspiera; w przeciwnym razie uzupełnienie przez HWInfo.
Na poziomie ustawień Afterburnera:
w zakładce Monitoring zaznaczyć interesujące metryki,
dla każdej z nich odznaczyć opcję „Show in On-Screen Display” tam, gdzie dane są zbędne w overlayu, ale przydatne w logach,
jako kluczowe w overlayu pozostawić wyłącznie: FPS, frametime, GPU usage, GPU memory usage, CPU usage (ew. kilka rdzeni), temperatury w skróconej formie.
Punkt kontrolny: jeżeli overlay zaczyna zajmować 1/4 ekranu, a odczyt wymaga „czytania tabeli”, narzędzie przestaje być użyteczne w trakcie lotu i zwiększa ryzyko własnego wpływu na wydajność. Minimum to 6–8 zwartych, kluczowych wskaźników na ekranie i reszta danych w logach.
Konfiguracja logowania do pliku CSV
Bez logowania do pliku frametime analiza kończy się na wrażeniach wizualnych. Afterburner umożliwia precyzyjne zapisywanie danych w stałych odstępach czasu.
Podstawowy zestaw kroków:
w zakładce Monitoring na dole okna zaznaczyć opcję Log history to file,
wskazać ścieżkę do katalogu przeznaczonego wyłącznie na logi z MSFS (np. osobny folder „MSFS_Logs”),
ustawić rozsądną częstotliwość próbkowania w zakładce General → Hardware polling period – zwykle w zakresie 500–1000 ms; jeśli priorytetem jest dokładny frametime, można zejść niżej, ale kosztem rozmiaru pliku,
nadać spójny schemat nazewnictwa logów (np. data_godzina_scenariusz.csv), aby później łatwo kojarzyć je z konkretnym lotem/testem.
Punkt kontrolny: jeżeli logi lądują w losowych katalogach, a ich częstotliwość próbkowania jest ustawiona zbyt rzadko (np. co 5 s), nie da się odtworzyć realnego przebiegu frametime. Minimum to osobny katalog, logiczne nazwy plików i okres odpytywania pozwalający uchwycić szybkie piki.
Ustawienia RTSS: overlay i ewentualny limiter FPS
RivaTuner Statistics Server przejmuje odpowiedzialność za wyświetlanie overlayu oraz, jeśli zostanie tak skonfigurowany, za limitowanie FPS. W kontekście diagnostyki należy zacząć od neutralnych ustawień:
uruchomić RTSS i upewnić się, że MSFS jest widoczny jako proces (jeśli nie, dodać ręcznie profil dla FlightSimulator.exe),
ustawić Application detection level na Medium lub Low, aby uniknąć konfliktów z innymi overlayami (Steam, GeForce Experience),
w sekcji „On-Screen Display” wybrać umiarkowaną czcionkę (np. 10–12 pt), jednolity kolor i pozycję, która nie zasłania istotnych elementów kokpitu,
pozostawić Framerate limit wyłączony lub ustawiony na wartość testową tylko wtedy, gdy celem jest porównanie zachowania przy limitowaniu po stronie RTSS, a nie gry.
Sygnałem ostrzegawczym jest sytuacja, w której po włączeniu RTSS pojawiają się crashe lub gra przestaje reagować na Alt+Enter/zmianę rozdzielczości. Wtedy trzeba zmniejszyć Application detection level albo tymczasowo wyłączyć overlay i pozostawić samo logowanie.
Punkt kontrolny: jeżeli limit FPS jest jednocześnie ustawiony w RTSS, panelu NVIDIA/AMD i w samej grze, diagnoza przyczyny frametime spike’ów staje się niejednoznaczna. Minimum to jeden aktywny limiter na czas testów (często wygodnie jest zacząć od wbudowanego limitu w MSFS lub RTSS, ale nie obu naraz).
Konfiguracja HWInfo do wsparcia diagnozy (opcjonalnie, ale zalecane)
HWInfo uzupełnia luki Afterburnera, szczególnie przy analizie throttlingu i zachowania poszczególnych rdzeni CPU. Jego konfiguracja powinna być równie „lekka” jak Afterburnera.
Kluczowe kroki startowe:
uruchomić HWInfo w trybie Sensors-only, bez panelu Summary,
w ustawieniach włączyć Logging Start ręcznie – bez auto-logowania przy każdym starcie systemu,
wybrać w zakładce „Configure Sensors” wyłącznie te czujniki, które są istotne (rdzenie CPU, temperatura CPU/GPU, VRM, dyski, RAM); resztę ukryć, aby ograniczyć obciążenie,
ustawić czas odświeżania sensorów na zakres 500–1000 ms, spójnie z Afterburnerem.
HWInfo przydaje się szczególnie wtedy, gdy MSFS w DevMode zgłasza „Limited by MainThread”, a jednocześnie wykresy CPU sugerują, że żaden rdzeń nie osiąga 100% w Task Managerze. W logach HWInfo można wtedy sprawdzić:
czy nie występuje Thermal Throttling na którymś z rdzeni,
czy nie pojawia się Power Limit lub Current Limit na CPU/GPU,
czy zegary CPU nie spadają okresowo z powodu zbyt agresywnych planów zasilania.
Punkt kontrolny: jeżeli HWInfo raportuje sporadyczne zadziałanie thermal/power limitów w momentach stutterów, dalsza optymalizacja samych ustawień graficznych nie ma sensu. Minimum to stabilne zegary i brak throttlingu – inaczej każda konfiguracja będzie losowo „dławiona” przez hardware.
Przykładowa sesja testowa: krok po kroku z DevMode + Afterburner + HWInfo
Dla spójności diagnozy warto przeprowadzić jedną kompletną sesję według stałego schematu. Przykładowy, praktyczny scenariusz:
Uruchom HWInfo (Sensors-only) i włącz logowanie do nowego pliku o nazwie np. MSFS_HW_YYYYMMDD_HHMM.csv.
Uruchom MSI Afterburner, upewnij się, że logowanie do pliku jest aktywne i overlay działa wyłącznie z kluczowymi wskaźnikami.
Uruchom MSFS, załaduj wcześniej zdefiniowany scenariusz testowy (to samo lotnisko, samolot, pogoda).
Włącz DevMode i Display FPS, zamknij inne panele DevMode.
Odczekaj 2–3 minuty w jednym miejscu (np. przy gate), obserwując stabilizację FPS i frametime.
Wykonaj krótki lot według z góry ustalonego planu (np. start, krótki krąg nad miastem, podejście do lądowania), przez cały czas nie zmieniając ustawień graficznych.
Po zakończeniu lotu wyłącz logowanie w HWInfo i Afterburnerze, a następnie zamknij MSFS.
Dane z takiej sesji pozwalają na pełne powiązanie momentów stutterów z:
Korelacja logów z odczuwanymi stutterami
Surowe pliki CSV bez kontekstu czasowego niewiele mówią. Kluczowe jest powiązanie konkretnych momentów z lotu (np. wjechanie w gęstą chmurę, dolot nad fotogrametrię miasta, krótkotrwały freeze na finalu) z tym, co pokazują logi Afterburnera, HWInfo i DevMode.
Praktyczny sposób pracy z danymi:
zaznaczać w głowie (lub na kartce) orientacyjny czas wystąpienia problemów: „około 12. minuty po starcie, nad centrum”,
po locie otworzyć log Afterburnera w arkuszu kalkulacyjnym (Excel, LibreOffice, Google Sheets) i przejść do wskazanego przedziału czasu,
równolegle otworzyć log HWInfo i dopasować go czasowo (sekundy/minuty) do logu Afterburnera,
korzystać z kolumn zawierających frametime, FPS, użycie CPU/GPU, VRAM, RAM oraz ewentualne flagi throttlingu.
W pierwszym kroku chodzi wyłącznie o znalezienie wspólnego mianownika dla momentów stutterów. Przykładowo:
jeśli w każdym odnotowanym „szarpnięciu” frametime skacze z 20–25 ms do 80–120 ms, a jednocześnie GPU usage spada z ~95% do 40–50%, to sygnał, że problem może być po stronie CPU lub I/O,
jeśli frametime rośnie, ale GPU usage trzyma 98–100%, a VRAM i RAM są na granicy, można podejrzewać dławienie przez pamięć lub bandwidth,
jeśli w logu HWInfo dokładnie w tych chwilach pojawiają się wpisy „Thermal Throttling: Yes” dla CPU lub „GPU Power Limit: Yes”, mamy wskazanie na ograniczenia sprzętowe, a nie konfigurację gry.
Jeżeli te zależności nie są widoczne przy pierwszej analizie, warto wydzielić krótkie odcinki logów (np. 2–3 minuty wokół stutterów) i prześledzić je osobno. Jeśli w każdym problematycznym fragmencie powtarza się ten sam wzór (np. nagły skok zajętości RAM i intensywne użycie dysku), kierunek kolejnych testów jest jasny.
Punkt kontrolny: jeżeli stuttery są odczuwalne, ale w logach nie widać żadnych wyraźnych zmian frametime, obciążenia CPU/GPU ani pamięci, trzeba w pierwszej kolejności zweryfikować poprawność logowania (zbyt rzadkie odpytywanie sensorów, błędna strefa czasowa, brak synchronizacji plików). Minimum to korelacja widocznego spadku płynności z co najmniej jednym parametrem w logach.
Źródło: Pexels | Autor: Maurício Mascaro
Interpretacja danych: jak rozpoznać, czy ogranicza CPU, GPU, I/O czy VRAM
Wskaźniki ograniczenia po stronie GPU
Typowy scenariusz „GPU-bound” w MSFS pojawia się przy wysokich rozdzielczościach (4K, VR), mocno podniesionych ustawieniach grafiki i stosunkowo nowym procesorze. Charakterystyczne objawy w logach:
GPU usage utrzymujące się stale w przedziale 95–100% w normalnym locie,
CPU usage relatywnie niższe, często z wąskim gardłem na pojedynczym rdzeniu, ale całościowo poniżej 80–90%,
frametime stabilny, ale w okolicy minimalnej wartości, jaką dany GPU jest w stanie utrzymać przy bieżących ustawieniach,
DevMode FPS Counter wskazuje „Limited by GPU” przez większość czasu, również w gęsto zabudowanych obszarach.
W takim scenariuszu spadki FPS przy stałym, wysokim użyciu GPU oznaczają po prostu, że karta graficzna nie wyrabia przy danym presecie graficznym. Nie jest to „problem do naprawienia” narzędziami, tylko sygnał do korekty ustawień (skalowanie renderowania, cienie, odbicia, TLOD/OLOD). Jeżeli jednak GPU usage spada przy tych samych spadkach FPS, ale VRAM jest „dobity” do 100%, może to wskazywać na ograniczenia pamięci.
Punkt kontrolny: jeżeli DevMode wskazuje „Limited by GPU”, a w logach GPU usage spada regularnie poniżej 80% w momentach stutterów, nie można mówić o klasycznym „GPU-bound”. Minimum to rozróżnienie: stałe 99% (naturalne ograniczenie GPU) vs skoki z 99% do 50–60% (szukanie winy poza samą kartą).
Wskaźniki ograniczenia po stronie CPU / MainThread
MSFS bardzo często jest ograniczany przez główny wątek (MainThread), zwłaszcza w gęstym ruchu AI, na złożonych lotniskach lub przy dużym TLOD. Typowe sygnały:
DevMode niemal ciągle zgłasza „Limited by MainThread”,
w logu widać, że jeden rdzeń CPU (lub logiczny wątek) okresowo osiąga 100%, podczas gdy reszta rdzeni pozostaje znacznie niżej,
GPU usage spada w tych momentach, mimo braku zmian w scenerii,
frametime rośnie skokowo, a FPS spadają w pobliżu dużych miast, hubów, przy włączeniu złożonego kokpitu lub zewnętrznych dodatków (np. zaawansowanych paneli, narzędzi ATC).
W takim układzie samo obniżanie ustawień stricte „GPU-owych” (antyaliasing, cienie, tekstury) często daje niewielki efekt. Dużo większy wpływ mają:
obniżenie Terrain LOD i Object LOD,
redukcja ruchu AI (samoloty, pojazdy, łodzie),
wyłączenie lub ograniczenie zewnętrznych narzędzi działających w tle i komunikujących się z simem (np. zaawansowany ruch offline, niektóre klienty sieciowe),
ograniczenie ruchu online i elementów streamowanych (w skrajnych przypadkach test bez fotogrametrii).
Jeżeli logi HWInfo dodatkowo pokazują spadki częstotliwości CPU przy rosnącej temperaturze, problem nie kończy się na konfiguracji gry – to już kwestia chłodzenia, BIOS-u, planu zasilania lub zbyt agresywnego undervoltu.
Punkt kontrolny: jeżeli w momentach spadków FPS GPU usage utrzymuje się w okolicy 60–70%, a jednocześnie jeden z rdzeni CPU dochodzi do 100%, problem nie leży po stronie karty graficznej. Minimum to dostosowanie obciążenia MainThread (TLOD, AI, ruch online) przed dalszym grzebaniem w ustawieniach GPU.
Ograniczenia pamięci RAM i VRAM
Niedobór pamięci to częsty powód nagłych stutterów, doczytywania terenu i „czkawki” przy dolocie do gęstych obszarów. Objawy w logach:
systemowy RAM zbliżony do 100% użycia (w HWInfo i Task Managerze),
rosnąca liczba operacji pagefile (odczyty/zapisy na dysku, rosnące obciążenie dysku systemowego),
VRAM usage dochodzące do 100% przy wysokich ustawieniach tekstur, dużej rozdzielczości i wielu dodatkach scenerii,
frametime skaczący w momentach dolotu do nowych obszarów lub szybkich obrotów kamery w gęstym mieście.
W RAM-owym „przyduszeniu” system zaczyna agresywnie korzystać z pliku stronicowania, co wprost przekłada się na I/O i czas odpowiedzi. Przy braku zapasu VRAM sterownik karty graficznej musi przenosić dane tekstur i buforów częściej niż zwykle. Każda z tych operacji widoczna jest jako spike frametime.
Minimalne kroki naprawcze:
obniżenie jakości tekstur (Textures, Anisotropic Filtering, Texture Supersampling) i ewentualnie rozdzielczości lub skalowania renderingu,
wyłączenie części dodatków scenerii w obszarach testowych, by obniżyć presję na VRAM,
upewnienie się, że system ma wystarczający plik stronicowania na szybkim dysku (NVMe / SSD),
w dłuższej perspektywie – rozbudowa RAM w przypadku konfiguracji 16 GB używanych z rozbudowanymi addonami.
Punkt kontrolny: jeżeli VRAM w logach stale pracuje w zakresie 95–100% i każdy obrót kamery nad dużym miastem generuje stutter, redukowanie ruchu AI lub cieni nie rozwiąże problemu. Minimum to ustawienia tekstur dopasowane do fizycznie dostępnej pamięci karty.
Wąskie gardło I/O: dysk i sieć
MSFS mocno polega na strumieniowaniu danych (fotogrametria, Bing, Live Weather). Dodatkowo, duże dodatki scenerii instalowane na wolnych dyskach mogą generować opóźnienia przy doczytywaniu. Typowe oznaki w logach i w zachowaniu gry:
nagłe stuttery przy dolocie do nowego obszaru, którym towarzyszy pik wykorzystania dysku (HWInfo, menedżer zadań),
relatywnie niskie użycie CPU i GPU w tych samych chwilach,
płynny lot nad wodą i terenami pustymi, za to problemy nad miastami z fotogrametrią i gęstymi addonami,
zmienność jakości streamowanych obiektów przy fluktuacjach łącza internetowego.
Do diagnozy I/O często trzeba dołożyć monitor sieci (np. wbudowany Resource Monitor lub zewnętrzne narzędzie), ale już same korelacje „stutter + 100% dysku” są istotne. Jeśli MSFS zainstalowany jest na wolnym HDD wraz z dużą biblioteką dodatków, wąskie gardło jest oczywiste.
Kroki minimalizujące problem:
przeniesienie MSFS i kluczowych dodatków na szybki SSD/NVMe,
wyłączenie fotogrametrii i streamowania danych w celach testowych (offline cache),
ograniczenie aktywności dysku w tle (backup, skanowanie AV, aktualizacje),
dla łączy niestabilnych – testy na stałych serwerach, ewentualnie bez ruchu online, by rozdzielić problemy sieciowe od typowo lokalnych.
Punkt kontrolny: jeżeli każde „doczytanie” nowego obszaru w locie powtarzalnie zgrywa się z maksymalnym obciążeniem dysku i brakiem obciążenia CPU/GPU, regulacja TLOD/OLOD i cieni ma ograniczony sens. Minimum to stabilny, szybki nośnik i względnie czyste tło systemowe.
Weryfikacja ustawień MSFS na podstawie logów i DevMode
Dobór scenariuszy testowych pod konkretne wąskie gardła
Jedna sesja testowa rzadko pokaże kompletny obraz. Dobrze jest zbudować zestaw powtarzalnych scenariuszy, z których każdy obciąża inny element konfiguracji:
Scenariusz GPU: wysokie ustawienia grafiki, wysoka rozdzielczość, proste lotnisko, umiarkowany ruch AI – sprawdza wydolność karty przy minimalnej presji na MainThread i I/O,
Scenariusz CPU/MainThread: gęste duże lotnisko hubowe, wysoki ruch AI, złożony samolot (np. z rozbudowanym systemem FMS), średni preset grafiki – wyciąga na wierzch ograniczenia CPU,
Scenariusz I/O/streaming: lot z pustych terenów nad duże miasto z fotogrametrią, z włączonym ruchem online i danymi Bing,
Scenariusz pamięci: dłuższy lot z wykorzystaniem kilku gęstych scenerii po drodze, z dużą liczbą addonów i wysokimi teksturami.
Dla każdego z nich warto stosować identyczne zasady: ten sam czas logowania, to samo narzędzie, stałe warunki pogodowe i porę dnia, a przede wszystkim – brak zmian ustawień „w locie”. Jeżeli zmiana ma być testowana (np. obniżenie TLOD o 50 punktów), należy to odnotować i powtórzyć cały scenariusz, a nie wprowadzać korekt w środku trasy.
Punkt kontrolny: jeżeli każdy test jest wykonywany w innym miejscu, innym samolotem, przy zmiennych warunkach online, korelacja wyników jest iluzoryczna. Minimum to dwa–trzy scenariusze bazowe, które można powtarzać po każdej większej zmianie konfiguracji.
Praca z DevMode FPS Counter: co konkretnie obserwować
DevMode w MSFS potrafi być przytłaczający, ale kilka prostych zasad pozwala wyciągnąć z niego kluczowe informacje bez nadmiernego chaosu:
skupiać się głównie na trzech linijkach: GPU, MainThread, Manipulators (opcjonalnie CoherentGT),
notować, która z nich częściej świeci się na czerwono lub pomarańczowo i w jakich warunkach (lotnisko, wysokość, gęstość chmur, miasto vs pustynia),
porównywać wartości ms z DevMode z frametime z Afterburnera – przy poprawnej konfiguracji powinny być zbliżone,
przecinać dane: jeśli DevMode sygnalizuje „Limited by MainThread”, sprawdzać równolegle użycie CPU i temperatury konkretnych rdzeni w HWInfo.
Dobrym nawykiem jest krótkie zatrzymanie się (pauza lub statyczne stanie na płycie) i odnotowanie stabilnych wartości: ile ms ma GPU, ile MainThread, ile FPS. Następnie mała zmiana – np. obniżenie TLOD lub wyłączenie ruchu AI – i ponowne odczytanie wartości w identycznym miejscu. W ten sposób powstaje „profil reakcji” ustawień na konkretne wąskie gardło.
Punkt kontrolny: jeżeli DevMode i Afterburner pokazują zupełnie różne wartości frametime/FPS, najpierw trzeba doprowadzić do spójności narzędzi (aktualizacja, konfiguracja, identyczne limity FPS). Minimum to pewność, że mierzony jest ten sam przebieg klatek, inaczej wnioski z kalibracji ustawień będą losowe.
Systematyczna korekta ustawień na podstawie danych
Zamiast chaotycznie „kręcić wszystkim naraz”, skuteczniejsze jest podejście iteracyjne oparte na danych z logów. Przykładowa sekwencja:
Najczęściej zadawane pytania (FAQ)
Jak rozpoznać, czy w Microsoft Flight Simulator problemem jest FPS czy frametime?
Jeśli licznik pokazuje „ładne” 50–60 FPS, a mimo to obraz przy obracaniu kamerą rwie, winny jest frametime. Sygnał ostrzegawczy: płynny licznik FPS, ale widoczne mikroprzycięcia, szczególnie w VR lub na monitorach z niskim input lagiem.
Gdy FPS jest niski, ale stabilny (np. zablokowane 30 FPS bez skoków), a obraz nie szarpie nawet przy szybszych ruchach kamery, frametime jest równy i akceptowalny. Punkt kontrolny: jeśli gołym okiem widzisz szarpanie przy dobrym FPS – przechodzisz do analizy frametime; jeśli FPS jest stale niski w każdym scenariuszu – diagnozujesz ogólny brak mocy lub zbyt wysokie ustawienia.
Jak sprawdzić frametime i spadki FPS w MSFS – jakie narzędzia są absolutnym minimum?
Minimalny zestaw to DevMode w MSFS z panelem „Display FPS” oraz MSI Afterburner z RTSS do logowania FPS/frametime. DevMode pokaże, czy ograniczeniem jest MainThread, GPU czy inne elementy pipeline’u, a Afterburner zapisze dane do pliku, który można przeanalizować później.
Punkt kontrolny: pełna diagnoza wymaga jednoczesnej obserwacji (1) wykresu frametime, (2) obciążenia CPU/GPU i (3) logów z czasu wystąpienia szarpnięcia. Jeśli korzystasz tylko z „gołego” licznika FPS (np. z GeForce Experience), diagnoza będzie w dużej mierze zgadywaniem.
Dlaczego mam stabilne FPS w MSFS, a obraz i tak „rwie” przy obracaniu kamerą?
To klasyczny przykład dobrego średniego FPS i złego frametime. Kolejne klatki nie dochodzą w równych odstępach czasu – kilka jest generowanych szybko, po czym pojawia się jedna bardzo „ciężka” klatka. Efekt: licznik FPS prawie się nie zmienia, ale oko rejestruje drgania obrazu.
Sygnał ostrzegawczy na wykresie: regularne „zęby” lub pojedyncze piki frametime przy normalnym obciążeniu GPU. Jeśli tak wygląda frametime przy szybkich ruchach kamery nad gęstą zabudową (fotogrametria, duże miasta), trzeba szukać przyczyn w doczytywaniu zasobów, pracy CPU lub dysku, a nie tylko w samej liczbie FPS.
Jak zdiagnozować, czy spadki FPS przy podejściu do lądowania to wina CPU, GPU czy dysku?
Najpierw odtwórz sytuację w kontrolowanych warunkach: ten sam samolot, to samo lotnisko, podobna pogoda, to samo podejście. Włącz DevMode (Display FPS) oraz logowanie w MSI Afterburner/HWInfo. Kluczowy moment do analizy to krótka końcówka podejścia, gdy zwykle pojawiają się przycięcia.
Jeśli w DevMode rośnie czas MainThread, a CPU ma skoki użycia – winny jest CPU i logika świata (AI traffic, pojazdy, kokpit).
Jeśli GPU wskakuje na 99–100%, VRAM zbliża się do limitu, a frametime rośnie falowo – problemem jest GPU i/lub ustawienia grafiki.
Jeśli pojawiają się szpilki użycia dysku i sieci przy względnie stałym CPU/GPU – ograniczeniem jest I/O (dysk, streamowanie danych).
Punkt kontrolny: jeśli dropy występują tylko w pobliżu dużych lotnisk, a nie nad oceanem czy pustynią, głównego źródła szukasz w doczytywaniu zasobów i obciążeniu CPU, nie w „za słabej karcie” jako takiej.
Stały niski FPS vs. nagłe dropy w MSFS – jak to odróżnić i co wtedy robić?
Stały niski FPS to sytuacja, gdy frametime jest równy, ale wysoki (np. 30–40 ms przez cały lot). Typowe przyczyny: zbyt wysokie ustawienia globalne, słabszy CPU w scenariuszu MainThread, render scaling ponad możliwości GPU. Działanie: racjonalne obniżenie kluczowych suwaków (render scaling, jakość chmur, teren, ruch AI) i ponowny test.
Nagłe dropy FPS to krótkie epizody spadków (np. z 50 do 15 FPS na sekundę–dwie) przy ogólnie dobrej płynności. Na wykresie frametime widać wtedy pojedyncze lub serię ostrych pików. Częste źródła: doczytywanie z dysku, skoki obciążenia CPU, thermal throttling. Punkt kontrolny: jeśli FPS jest zwykle dobry, a problemy to tylko sporadyczne szarpnięcia, korekta powinna być celowana (dysk, temperatury, dodatki), a nie polegać na hurtowym zbijaniu wszystkich ustawień graficznych.
Jak korzystać z CapFrameX przy diagnostyce frametime w Microsoft Flight Simulator?
CapFrameX służy jako „lupa” do szczegółowej analizy frametime. Najpierw w MSI Afterburner włączasz logowanie FPS/frametime do pliku CSV podczas powtarzalnego scenariusza testowego w MSFS. Następnie importujesz ten plik do CapFrameX i oglądasz wykres frametime oraz statystyki 1% low i 0.1% low.
Punkt kontrolny: jeżeli średni FPS wygląda dobrze, ale 1% low i 0.1% low są mocno zaniżone (duża różnica względem średniej), frametime jest niestabilny i to on psuje płynność. Wtedy szukasz w logach korelacji między pikami frametime a skokami użycia CPU, GPU, dysku lub sieci – dopiero na tej podstawie zmieniasz ustawienia lub konfigurację.
Czy do diagnozy spadków FPS w MSFS wystarczy sam licznik z karty graficznej (np. GeForce Experience)?
Licznik z panelu GPU pokazuje jedynie ogólny FPS, ewentualnie obciążenie GPU. To za mało, aby rzetelnie ocenić płynność w MSFS, ponieważ nie widzisz ani frametime, ani tego, czy wąskim gardłem jest MainThread, dysk czy sieć. Taki monitoring nadaje się do szybkiej orientacji, ale nie do precyzyjnej diagnostyki.
Minimum do sensownej analizy to: DevMode z „Display FPS” po stronie symulatora oraz logi z MSI Afterburner/HWInfo lub CapFrameX po stronie systemu. Punkt kontrolny: jeśli diagnoza opiera się na jednym wskaźniku (np. tylko FPS lub tylko GPU%), ryzyko błędnej interpretacji przyczyn spadków FPS jest bardzo wysokie.
