Чому Windows і Linux можуть давати різний FPS на одному процесорі

FPS — це симптом; фреймтайм — це хвороба

«Різний FPS» зазвичай служить скороченою назвою для набору окремих проблем:

• Середній FPS (легко хизуватися, легко підлаштувати під бенчмарки).
• 1% / 0.1% найнижчі значення (наскільки погано стає, коли ОС і драйвери не погоджуються з вашим навантаженням).
• Подача кадрів (стабільна доставка кадрів проти рваного, нестабільного потоку).
• Затримка від вводу до пікселя (скільки часу ваша кнопка чи клік потребують, щоб стати пікселем на екрані).

Дві системи можуть мати однаковий середній FPS і водночас відчуватися кардинально по-різному, бо одна має більш щільний розподіл часу кадру. ОС важлива, бо вона вирішує, хто запускається коли, на якому ядрі, на якій частоті й з якими перериваннями, які можуть втрутитися у найгірший момент.

Ось операційний підхід: ігровий кадр — це міні-конвеєр виробництва. Є основний потік, потоки рендера, робочі потоки, відправка в драйвер, виконання на GPU, презент, композитинг і часом шари перекладу. Якщо будь-яка стадія зупиняється, увесь конвеєр підхоплює ривок.

ОС — це менеджер конвеєра. Інший менеджер — інші вузькі місця.

Цікаві факти та історичний контекст

Це не дрібниці заради дрібниць. Вони пояснюють, чому деякі проєктні вибори існують і чому їх складно «полагодити» сьогодні.

1. Ігрові API Windows сформували пріоритети драйверів. DirectX домінував у PC-іграх десятиліттями, і вендори оптимізували драйвери та інструменти під Windows.
2. Графіка в Linux пройшла кілька епох. Модель X11, потім композитори, потім Wayland; кожна зміна покращувала деякі шляхи затримки й ускладнювала інші.
3. Планувальник Windows довго налаштовувався під інтерактивність десктопа. Підсилення foreground-процесів і мультимедійне планування існують, бо десктопні додатки (а пізніше й ігри) вимагали відгуку.
4. CFS у Linux оптимізував чесність та пропускну здатність. Він відмінний для змішаних навантажень, але «чесно» не завжди означає «найменша затримка прямо зараз».
5. Таймери високої роздільної здатності змінили відладку продуктивності. Коли таймери стали точнішими, розробники почали використовувати busy-wait і опитування з високою частотою; це вибухівка для енергоспоживання й планування.
6. Сучасні CPU ускладнили політики енергоспоживання на рівні ОС. Turbo, E‑ядра/P‑ядра, CPPC, глибокі C‑стани — це точки прийняття рішень, де налаштування ОС відрізняються за замовчуванням.
7. Моделі драйверів різняться. WDDM у Windows наголошує на прекемпції, плануванні й контролі ОС; у Linux інша розподілена модель між kernel DRM, Mesa і закритими бінарними модулями вендора.
8. «Повноекранний ексклюзивний режим» став полем бою. Windows ввів «оптимізації повноекранного режиму», щоб зменшити зміну режимів; іноді це добре, іноді погано. Політика композитингу в Linux знову інша.

Звідки беруться відмінності ОС (реальний список)

1) Планування CPU: хто працює, де й як довго

Ігри не рівномірно паралельні. Багато з них все ще обмежені основним потоком або парою «гарячих» потоків з жорстким порядком. Це робить рішення планувальника помітними.

• Windows має зрілий набір евристик для foreground-додатків, мультимедійного класу та «дати активному процесу кращий шанс запуститися». Це не ідеально, але це навмисно.
• Linux з CFS відмінний у чесності й використанні ресурсів. Але чесність може означати, що ваш гарячий потік ділить час більш «демократично» з фоновою роботою, яку ви не помічали (наприклад, композитор, вкладка браузера або білдер шейдерів).

Коли ви бачите стрибки часу кадру кожні кілька секунд, запідозрійте інтерференцію планувальника: системний потік ядра, шторм переривань, подія звільнення пам’яті або фоновий сервіс, що виконує «корисну» роботу.

2) Керування живленням: турбо, губернатори та податок затримки

Відмінності політик живлення — одна з найпоширеніших причин, чому той самий CPU поводиться по-різному.

• У Linux ви можете застрягти в режимі powersave або на консервативному EPP (energy performance preference) і ніколи не досягти очікуваних частот.
• У Windows «Збалансований» часто все ще агресивно підвищує частоти на сучасних системах, але утиліти виробника можуть це перекрити, а прошивка ноутбука може обмежувати стійку потужність.

Керування живленням — це не просто «нижчий FPS». Це може бути джиттер: виведення ядер із глибоких C-станів, запізніле підвищення частоти, парковка/розпарковка ядер і міграція потоків по холодних кешах.

Думка: для тестування продуктивності не бенчмарьте на «збалансованих» налаштуваннях. Спочатку зафіксуйте режим продуктивності і зніміть невизначеність. Потім уже цілеспрямовано налаштовуйте живлення вниз.

3) Роздільна здатність таймера й точність сну

Ігри залежать від сну, очікування й пейсингу. Різниця між пробудженням через 1 мс і 15,6 мс — це різниця між «плавно» і «чому це схоже на вівсянку».

Windows давно підтримує запити на зміну роздільної здатності системного таймера. Linux теж має таймери високої роздільної здатності, але поведінка залежить від конфігурації ядра, частоти тікера й того, чи не тримає щось CPU від переходу в простій режим.

Переклад: дві ОС можуть запускати той самий код і по-різному тлумачити «спати 1 мс» під навантаженням.

4) Графічний стек і накладні витрати драйверів

У Windows більшість нативних ігор налаштовані під DirectX і поведінку WDDM. У Linux ви можете використовувати:

• Нативний Vulkan
• OpenGL
• Proton/Wine + DXVK (D3D9/10/11 → Vulkan)
• vkd3d-proton (D3D12 → Vulkan)

Кожен шар перекладу має накладні витрати на CPU і поведінку кешування. Це може бути мінімально або спалювати кілька мілісекунд на кадр у невдалих випадках (компіляція шейдерів, трансляція станів, синхронізаційні вишукування).

5) Композитори, менеджери вікон і шляхи презенту

У Windows DWM завжди активний, але шлях презенту відрізняється між рамковим вікном, ексклюзивним повноекранним і «оптимізаціями повноекранного режиму». У Linux ви маєте X11 vs Wayland і політики вашого композитора (KWin, Mutter тощо).

Композитинг може додати затримку, ввести додаткові буфери або змусити синхронізуватися в невдалих точках. Або ж сховати розриви й згладити подачу кадрів. Головне: ваш робочий стіл — частина рендер-пайплайна.

6) Обробка переривань і поведінка DPC/softirq

Переривання — це маленькі надзвичайні події. Їх надто багато або вони неправильно розташовані — і ваш основний потік втрачає квант часу саме тоді, коли він необхідний.

• Windows проявляє це як проблеми з DPC-латентністю, часто пов’язані з драйверами (мережа, аудіо, сховища, утиліти RGB — так, насправді).
• Linux проявляє це як час softirq, пробудження ksoftirqd, проблеми з IRQ affinity або некоректно працюючі модулі ядра.

Якщо ваш FPS падає, коли ви щось завантажуєте, стрімите чи використовуєте Bluetooth-аудіо, швидше за все, ви дивитесь на переривання і планування драйверів.

7) Управління пам’яттю і фонове звільнення

Обидві ОС мають складні системи віртуальної пам’яті. Обидві можуть вам нашкодити. Linux може вирішити, що саме час звільнити пам’ять або скомпактити сторінки. Windows може вирішити, що саме час індексувати, сканувати або оновити додатки зі сховища. Конкретика різна, але режим відмови виглядає однаково: випадкові паузи 30–200 мс.

Ігри, які агресивно стрімлять ресурси, чутливі до поведінки page cache і планування I/O. Якщо ви одночасно запускаєте браузери, лаунчери та оверлеї, ви фактично побудували невелику розподілену систему — в одній коробці.

8) Поведінка файлової системи та стеку зберігання

Так, сховище може впливати на FPS — особливо на стрибки часу кадру — бо сучасні ігри стрімлять текстури, шейдери й геометрію. Windows NTFS проти Linux ext4/btrfs/xfs — це не лише про пропускну здатність. Це політики кешування, накладні витрати на метадані, фонові завдання (наприклад, btrfs scrub) і стек драйверів NVMe.

Думка: якщо ви діагностуєте стутер, розглядайте сховище як першокласного підозрюваного. Стрибки часу кадру часто корелюють із очікуваннями I/O.

9) Засоби безпеки та пом’якшення вразливостей

Міри пом’якшення для спекулятивного виконання й функції жорсткої захищеності ядра можуть змінювати вартість системних викликів, накладні на контекстні перемикання та поведінку бар’єрів пам’яті.

Іноді вплив незначний. Іноді це різниця між «CPU-bound» і «GPU-bound». Чесна відповідь: вимірюйте у вашому навантаженні.

10) Утиліти вендорів і «корисне» програмне забезпечення

У Windows: демони живлення OEM, аудіо-суїти, програми для запису, контролери RGB, телеметрія материнської плати. У Linux: розширення робочого столу, фоновий індексатор, демони живлення, інструменти laptop-mode, модулі ядра поза деревом.

Нічого з цього не є априорі злим. Але кожна жива служба — кандидат на джиттер.

Цитата, яку варто приклеїти на монітор: «Сподівання — не стратегія.» — Генерал Гордон Р. Салліван

Цей вислів корисний операційно, бо змушує припинити гадати. Бенчмаркуйте, профілюйте й змінюйте одну змінну за раз.

Жарт #1: Якщо ви не можете відтворити стутер — вітаю: ви створили квантовий бенчмарк. Спостереження змінює явище.

Швидкий план діагностики

Це порядок триажу, який я використовую, коли хтось каже «Linux дає нижчий FPS ніж Windows на тому самому CPU» або «Windows відчувається ривким, а Linux плавний». Це не філософія. Це те, що швидко знаходить вузьке місце.

Спочатку: підтвердіть, який саме тип проблеми у вас

• Якщо середній FPS нижчий: підозрюйте політику живлення, накладні драйверів, шари перекладу або обмеження частоти CPU.
• Якщо 1% найнижчі гірші (стриби): підозрюйте фонові завдання, переривання, звільнення пам’яті, компіляцію шейдерів, очікування I/O, композитинг або проблеми з VRR/present.
• Якщо затримка вводу гірша: підозрюйте буферизацію, композитинг, режими vsync і глибину черг у графічному стеку.

По-друге: визначте CPU vs GPU vs I/O

• GPU-bound: GPU на високому завантаженні; зменшення роздільності майже не підвищує FPS; CPU має запас.
• CPU-bound: одне або два CPU‑ядра гарячі; зниження роздільності мало допомагає; вищі тактові частоти CPU дуже допомагають.
• I/O-stall bound: стрибки часу кадру корелюють з читаннями диска, pagefaults чи записами кешу шейдерів.

По-третє: усуньте шум, потім додайте його назад

• Вимкніть оверлеї та програми для запису.
• Використайте зафіксований профіль живлення.
• Спробуйте інший режим вікна (ексклюзивний/безрамковий) і налаштування композитора.
• Заміри повторіть. Лише потім починайте налаштовувати складні речі, як IRQ affinity.

Практичні завдання: команди, виводи та рішення

Ці завдання написані як SRE‑runbook: команда, що ви можете побачити, що це означає і що робити далі. Більшість прикладів — для Linux, бо він інспектований без сторонніх інструментів, але кілька перевірок Windows теж важливі.

Завдання 1: Підтвердити поведінку частоти CPU (Linux)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|MHz'
Model name:                           AMD Ryzen 7 5800X3D 8-Core Processor
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
CPU MHz:                              3387.000

Що це значить: CPU MHz — це знімок, а не абсолютна істина. Але він показує, чи застрягли ви на низьких частотах.

Рішення: Якщо частоти низькі під навантаженням, перевірте governor/EPP далі.

Завдання 2: Перевірити governor і EPP (Linux)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference
balance_power

Що це значить: Ви просите CPU «зберігати енергію», а потім дивуєтеся, чому він не мчить.

Рішення: Для тестування перемкніть на performance (або встановіть EPP у performance) і перезапустіть бенчмарк.

Завдання 3: Тимчасово встановити performance governor (Linux)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7

Що це значить: Ви зменшуєте затримки підвищення частоти і піднімаєте стійкі частоти.

Рішення: Якщо FPS суттєво покращився, ваша «різниця ОС» була здебільшого політикою живлення.

Завдання 4: Перевірити, чи активний turbo/boost (Linux, приклад Intel)

cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/no_turbo
0

Що це значить: 0 означає, що turbo дозволено.

Рішення: Якщо значення 1, увімкніть turbo і протестуйте знову. Якщо не виходить — перевірте BIOS або обмеження OEM.

Завдання 5: Піймати фонових «крадіїв» CPU (Linux)

cr0x@server:~$ top -o %CPU -b -n 1 | head -n 15
top - 10:41:02 up  3:12,  1 user,  load average: 2.31, 1.88, 1.25
Tasks: 312 total,   2 running, 310 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.4 us,  2.1 sy,  0.0 ni, 84.9 id,  0.4 wa,  0.0 hi,  0.2 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2441 cr0x      20   0 6729348 688144 212000 R  95.0   4.3   2:10.31 game.bin
1882 cr0x      20   0 1492256 102332  52944 S  12.0   0.6   0:20.02 shadercache
1120 root      20   0       0      0      0 S   4.3   0.0   0:11.55 kswapd0

Що це значить: Якщо ви бачите kswapd0 або інтенсивну активність shadercache під час гри — очікуйте стрибків.

Рішення: Якщо тиск пам’яті реальний — додайте ОЗП або зменшіть фонові додатки. Якщо йде компіляція шейдерів — прогрійте кеші або зачекайте завершення першого запуску.

Завдання 6: Перевірити тиск пам’яті і звільнення (Linux)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 512348  82344 6021840   0    0    12    55 3210 8120 18  3 79  0  0
 1  0      0 498120  82344 6030100   0    0     0   102 3120 7900 21  4 75  0  0
 3  1      0  88240  82344 6029900   0    0  5120  4200 9800 22000 35  8 49  8  0
 2  1      0  70120  82344 6028800   0    0  6200  3900 10200 24500 32 10 46 12  0
 1  0      0 110220  82344 6029200   0    0   140   180 4100 9000 20  4 76  0  0

Що це значить: Стовпець b (blocked), а також стрибки в wa (I/O wait) і велика активність bi/bo свідчать про те, що мають місце затримки, які може бути видно як стрибки часу кадру.

Рішення: Якщо ви бачите це під час просідань, дослідіть сховище й розміщення кешу шейдерів; переконайтеся, що гра на швидкому SSD; перевірте файлову систему та вільне місце.

Завдання 7: Виявити I/O-стали (Linux)

cr0x@server:~$ iostat -xz 1 3
Linux 6.6.8 (server) 	01/10/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.10    0.00    4.80    6.30    0.00   66.80

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1         180.0   8200.0     2.0   1.10    5.40    45.6     90.0   6100.0    9.80    67.8    1.22  92.0

Що це значить: Високий %util і підвищені r_await/w_await під час стутеру = сховище частково відповідає за історію часу кадру.

Рішення: Перенесіть гру й кеш шейдерів на найшвидший SSD, переконайтеся, що немає фонового сканування, індексування або завантажень; перевірте теплове обмеження NVMe.

Завдання 8: Помітити теплове тротлінг (Linux)

cr0x@server:~$ sensors | egrep 'Tctl|Package|Core|Composite'
Tctl:         +87.5°C
Package id 0:  +91.0°C
Composite:     +78.2°C

Що це значить: Високі температури можуть спричиняти зниження частот. Деякі системи тротлінгують CPU, деякі — GPU, деякі тихо обмежують обидва.

Рішення: Якщо температури близькі до точок тротлінгу під час тестів — виправте охолодження, профілі вентиляторів, пил, правильність кріплення або ліміти живлення ноутбука перед тим, як звинувачувати ОС.

Завдання 9: Підтвердити драйвер GPU і шлях рендерингу (Linux)

cr0x@server:~$ glxinfo -B | egrep 'OpenGL vendor|OpenGL renderer|OpenGL version'
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 4070/PCIe/SSE2
OpenGL version string: 4.6.0 NVIDIA 550.54.14

Що це значить: Ви справді на бажаному драйвері GPU, а не на запасному рендері.

Рішення: Якщо ви бачите LLVMpipe або неправильну GPU — виправте інсталяцію драйвера, налаштування PRIME offload або вибір пристрою.

Завдання 10: Перевірити вибір пристрою Vulkan (Linux)

cr0x@server:~$ vulkaninfo --summary | egrep 'GPU id|deviceName|driverName|apiVersion' -m 8
GPU id : 0 (NVIDIA GeForce RTX 4070)
driverName = NVIDIA
apiVersion = 1.3.280
GPU id : 1 (AMD Radeon(TM) Graphics)
driverName = RADV
apiVersion = 1.3.275

Що це значить: Системи з кількома GPU можуть обрати неправильний пристрій (інтегрований замість дискретного), особливо в ноутбуках.

Рішення: Якщо гра працює на iGPU — примусово вказуйте dGPU через змінні середовища або ваш механізм перемикання графіки і перетестуйте.

Завдання 11: Перевірити композитор / тип сесії (Linux)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland
cr0x@server:~$ echo $XDG_CURRENT_DESKTOP
GNOME

Що це значить: Wayland vs X11 може змінити затримку й поведінку VRR залежно від композитора й драйверів.

Рішення: Якщо ви діагностуєте стутер — протестуйте обидві сесії Wayland і X11 (по черзі). Ведіть нотатки.

Завдання 12: Спостерігати навантаження IRQ і softirq (Linux)

cr0x@server:~$ cat /proc/interrupts | head -n 8
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  0:         22          0          0          0          0          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0          0          0          0          0          0   IO-APIC   1-edge      i8042
 24:      88210       1200        980       1100       1050       1001       1122       1088   PCI-MSI 327680-edge      nvme0q0
 32:     190220       3100       2990       3050       3010       2975       3090       3002   PCI-MSI 524288-edge      nvidia

Що це значить: Одне CPU, що отримує більшість переривань, може спричиняти локалізований джиттер, якщо ваш гарячий потік також потрапляє туди.

Рішення: Якщо одне ядро — магніт для переривань, розгляньте конфігурацію балансування IRQ або відв’яжіть гру від цього ядра (досить просунутий підхід; тестуйте уважно).

Завдання 13: Перевірити навантаження по ядрах і підозру на міграцію (Linux)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.8 (server) 	01/10/2026 	_x86_64_	(16 CPU)

12:10:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %idle
12:10:02 PM  all   24.2    0.0    5.1    1.2    0.0    0.7   68.8
12:10:02 PM    0   12.0    0.0    3.0    0.0    0.0    6.0   79.0
12:10:02 PM    5   78.0    0.0    5.0    0.0    0.0    0.0   17.0
12:10:02 PM    6   65.0    0.0    6.0    0.0    0.0    0.0   29.0

Що це значить: Одне або два «гарячі» ядра типові для основних потоків гри; але якщо «гаряче» ядро постійно змінюється, ви платите за пропуски кеша й витрати на міграцію.

Рішення: Якщо міграція корелює зі стрибками — протестуйте з прив’язкою процесу до ядер (CPU affinity) для гри (обережно; не робіть це «за інерцією»).

Завдання 14: Перевірити індикатори затримки планувальника ядра (Linux)

cr0x@server:~$ cat /proc/schedstat | head -n 5
version 15
timestamp 18273648590
cpu0 0 0 0 0 0 0 1234567890 0 0
cpu1 0 0 0 0 0 0 1134567890 0 0
domain0 0 0 0 0 0 0 0 0 0

Що це значить: Цей файл сирий, але це канареєчка: якщо ви йдете глибоко — ви вимірюєте поведінку планувальника і черг запуску, а не здогадуєтеся.

Рішення: Використовуйте це тільки якщо готові профілювати за допомогою perf. Інакше дотримуйтесь більш високорівневих індикаторів.

Завдання 15: Швидко профілювати «гарячі точки» CPU (Linux)

cr0x@server:~$ sudo perf top -g --call-graph fp
Samples: 5K of event 'cycles', 4000 Hz, Event count (approx.): 1200000000
  22.15%  game.bin             [.] UpdateWorld
  14.02%  libnvidia-glcore.so   [.] glDrawElements
   9.88%  dxvk-native.so        [.] dxvk::Presenter::present
   6.41%  [kernel]              [k] schedule

Що це значить: Ви можете побачити, чи ви CPU‑bound у коді гри, накладні драйвера, шар перекладу або витрати на планування.

Рішення: Якщо планувальник ядра помітний — зменшіть фонове навантаження і переривання. Якщо домінує драйвер/переклад — протестуйте інші версії драйвера або нативний API.

Завдання 16: Виявити використання swap (Linux)

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file  16G  2G   -2

Що це значить: Використання swap під час ігрової сесії може спричиняти періодичні паузи, особливо на повільнішому сховищі.

Рішення: Якщо swap істотний під час гри — зменшіть тиск пам’яті: закрийте додатки, додайте RAM або відрегулюйте swappiness (і переконайтеся, що ви не маскуєте реальний дефіцит ОЗП).

Завдання 17: Знайти pagefaults під час гри (Linux)

cr0x@server:~$ pidof game.bin
2441
cr0x@server:~$ ps -o pid,comm,min_flt,maj_flt,rss,vsz -p 2441
  PID COMMAND   MINFLT  MAJFLT    RSS     VSZ
 2441 game.bin  912345     210 6812200 6820000

Що це значить: Major faults (maj_flt) означають звернення до дисково-забезпечених сторінок — часто видно як стутер, якщо це відбувається під час дії.

Рішення: Якщо major faults ростуть під час провалів — перевірте тиск пам’яті, поведінку стрімінгу ассетів і продуктивність сховища.

Завдання 18: Швидка перевірка плану живлення Windows (Windows)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Що це значить: Ви на Balanced. На деяких системах це нормально. На інших — це прихований тротлінг.

Рішення: Переключіться на високопродуктивний план для бенчмарку; якщо це вирішує FPS — причина в політиці, а не в ядрі.

Жарт #2: Програмне забезпечення для керування RGB має унікальну здатність знижувати FPS й одночасно підвищувати «кількість кадрів на секунду» ваших вентиляторів.

Три корпоративні міні-історії з польових робіт

Міні-історія 1: Інцидент, спричинений хибним припущенням

Студія мала внутрішній набір бенчмарків для шутера від першої особи. Суїта запускалася щовечора на кількох ідентичних десктопах: dual-boot Windows і Linux, ті самі налаштування BIOS (так вони думали), та сама гілка драйвера GPU (так вони думали), та сама збірка гри.

За місяць показники Linux почали повільно падати — не катастрофічно, але поступово зменшувалися 1% lows. Інженери збірки припустили, що «драйвери Linux нестабільні» і почали фіксувати баги на команду рендерингу. Команда рендерингу зробила те, що рендер-команди роблять під тиском: додала інструментування. Воно показало періодичні паузи, що корелювали зі стрімінгом ассетів і записами кешу шейдерів.

Після тривалого розслідування хтось нарешті подивився логи системи. Доброзичливий опс-технік увімкнув щотижневе сканування файлової системи і тривалі SMART‑тести для Linux‑розділу. Планування цих робіт припало саме на запуски бенчмарків. Windows не мала тієї самої розкладу обслуговування. CPU був ні при чому; латентність зберігання — так.

Виправлення було неефектне, але ефективне: перемістили обслуговчі роботи поза час бенчмарків, прив’язали кеш шейдерів до швидкого локального NVMe і ввели «режим бенчмарк» згідно з runbook. Продуктивність Linux повернулася. Команда рендеру отримала свій час. Ops отримали нагадування, що «однакові» середовища перестають бути однаковими там, де існує cron.

Міні-історія 2: Оптимізація, що повернулась бумерангом

Підрозділ IT хотів зробити Linux-станції «швидшими» в демонстраційній лабораторії. Хтось прочитав, що агресивне масштабування частоти CPU економить енергію «без впливу на користувача». Вони розгорнули конфігурацію, яка змістила EPP у бік енергозбереження і дозволила глибші стани простою. Їхні дашборди виглядали чудово: менше ват в режимі простою, нижчі температури, задоволена інфраструктура.

Потім настав тиждень демонстрацій. Лабораторія запустила VR‑титул, який надзвичайно чутливий до фреймтайму. Середній FPS не був жахливим, але досвід у гарнітурі мав періодичні ривки — саме ті, що викликають нудоту й обурення керівництва. Команді дісталося звинувачення в бік VR‑рантайму, GPU‑драйвера, ОС. Всі помилилися.

Профілювання показало затримки підвищення частоти: CPU не прискорювався достатньо швидко, коли основний потік гри цього вимагав. Система «ефективно» запізнювалася. Вони повернули політику на продуктивність під час демонстрацій і зберегли енергозберігаючий режим у простої.

Урок не в тому, щоб ніколи не економити енергію. Урок у тому, що політика живлення — це контракт навантаження. Якщо ваше навантаження чутливе до затримок — не прикидайтеся, що це таблиця Excel.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Компанія експлуатувала кросплатформений клієнт для симуляційного тренування. Клієнт мав високе графічне навантаження, але справжня проблема була в консистентності: інструктори вимагали ідентичного досвіду на Windows і Linux кіосках. Невеликі джиттери спричиняли помітне розходження в синхронізованих сценаріях.

Вони зробили радикально нудну річ: написали runbook і примусово його виконували. Ті самі версії драйверів GPU, той самий графік патчів ОС, ті самі налаштування композитора, той самий план живлення, той самий список фоновых служб. Бенчмарки запускали з чистого завантаження з відключеною мережею, логи збиралися в централізоване сховище, і будь-яка зміна вимагала порівняння до/після з перцентилями часу кадру.

Коли оновлення вендора регресувало подачу кадрів у Linux, вони виявили це за день, бо метрики були стабільні, а середовище — контрольоване. Відкотити драйвер було простим. Геройства не знадобилося, не довелося сперечатися про «відчуття». Графіки були грубі і прозорі.

Оце й правда нудна: більшість «таємниць продуктивності ОС» зникають, якщо ви ставите ваш ігровий ПК як продакшн-систему і перестаєте дозволяти випадковим демонам імпровізувати на сцені.

Поширені помилки: симптом → корінь проблеми → виправлення

1) «Linux FPS нижчий у всіх випадках»

Симптом: Середній FPS на 10–30% нижчий, ніж у Windows, послідовно.

Корінь: Governor/EPP CPU встановлено в енергозберігаючий режим, turbo вимкнено або вмикаються обмеження OEM для ноутбука під Linux.

Виправлення: Встановіть performance governor для тестування; перевірте boost; перевірте терміни й ліміти потужності; переконайтеся, що активний правильний драйвер CPU (intel_pstate/amd_pstate).

2) «FPS в порядку, але кожні кілька секунд стутер»

Симптом: Стабільний середній FPS, але погані 1% lows і періодичні стрибки часу кадру.

Корінь: Фоновий I/O (кеш шейдерів, індексування, служби оновлень), звільнення пам’яті, активність swap, або планові обслуговчі завдання.

Виправлення: Моніторьте iostat/vmstat; зупиніть фонові роботи; перенесіть гру/кеш шейдерів на швидкий SSD; додайте RAM, якщо відбувається пейджинг; тримайте достатньо вільного місця.

3) «Безрамковий режим гірший за повноекранний» (або навпаки)

Симптом: Режими вікна істотно змінюють FPS/затримку між ОС.

Корінь: Різні шляхи презенту/композитингу: поведінка DWM і оптимізації повноекранного режиму у Windows; політики композитора у Linux (Wayland/X11), gating VRR, додаткове буферування.

Виправлення: Тестуйте ексклюзивний повноекранний, безрамковий і віконний режими на кожній ОС. У Linux тестуйте X11 vs Wayland. Обирайте режим, який дає стабільну подачу кадрів, а не лише піковий FPS.

4) «Linux відчувається повільним з vsync, а Windows ні»

Симптом: Затримка вводу зростає більше, ніж очікується при увімкненому vsync.

Корінь: Різні значення буферизації за замовчуванням (подвійна vs потрійна буферизація), примус vsync композитора або різниця в глибині черги драйвера.

Виправлення: Налаштуйте in-game vsync, limiter і режими низької затримки. Розгляньте VRR. Уникайте накладання кількох обмежувачів (гра + драйвер + композитор).

5) «Після оновлення драйвера FPS змінився»

Симптом: Раптова зміна продуктивності після оновлення GPU‑драйвера або ядра.

Корінь: Інвалідація кешу шейдерів, нова поведінка планування, інші значення за замовчуванням або регресії.

Виправлення: Перебудуйте кеші (перший запуск може стутерити), порівняйте версії драйверів, зберігайте шлях відкату до відомої доброї версії і фіксуйте базові результати бенчмарків.

6) «Мережева активність вбиває FPS»

Симптом: Завантаження/стрімінг викликає провали кадрів.

Корінь: Шторм переривань і витрати CPU в мережевому стеку; погіршений розподіл IRQ; баги в драйверах.

Виправлення: Перевірте розподіл IRQ; переконайтеся, що драйвер/прошивка NIC сучасні; протестуйте з мережею вимкненою, щоб підтвердити; розгляньте балансування IRQ і CPU affinity тільки після вимірювань.

7) «Гірше на гібридних CPU»

Симптом: Джиттер або нестабільний FPS на CPU з ядрами продуктивності/ефективності.

Корінь: Проблеми з розміщенням потоків, міграція між типами ядер або невідповідність політики живлення.

Виправлення: Оновіть ОС/ядро; забезпечте підтримку планувальника; у Windows перевірте Game Mode; у Linux розгляньте новіші ядра й перевірте поведінку CPUfreq/CPPC.

Чеклісти / покроковий план

Чекліст A: Зробіть бенчмарк чесним (зробіть це перед тим, як сперечатися онлайн)

1. Використовуйте ту саму версію гри, ту саму карту/сцену, ті самі налаштування, ту саму роздільність, ті самі налаштування апскейлера.
2. Прогрійте кеші: прогріть сцену один раз, потім робіть заміри другого запуску (або записуйте обидва: холодний vs прогрітий).
3. Виправте політику живлення:
   • Windows: встановіть високопродуктивний план для тестування.
   • Linux: встановіть governor/EPP у performance для тестування.
4. Вимкніть оверлеї/рекордери та «корисні» утиліти вендора для тестового прогону.
5. Вимкніть фонове обслуговування: оновлення, індексування, планові завдання, scrub‑и.
6. Збирайте метрики часу кадру, а не лише середній FPS.

Чекліст B: Якщо Linux має нижчий FPS, порядок дій

1. Перевірте, що використовується дискретний GPU і правильний драйвер (glxinfo -B, vulkaninfo).
2. Перевірте CPU boost і governor/EPP.
3. Перевірте терміни під навантаженням.
4. Переконайтеся, чи ви CPU‑bound (використовуйте perf top або графіки часу кадру CPU/GPU в грі).
5. Якщо використовуєте Proton: протестуйте нативну гру на Vulkan, щоб ізолювати накладні витрати перекладу.
6. Тестуйте Wayland vs X11 і налаштування композитора, що впливають на VRR/vsync.

Чекліст C: Якщо Windows ривка, а Linux плавний

1. Перевірте план живлення Windows і утиліти вендора, що можуть обмежувати потужність CPU/GPU.
2. Перевірте драйверні функції, які змінюють планування (наприклад, апаратне прискорення, режими низької затримки).
3. Перевірте фонові служби: механізми оновлення, телеметрію, індексування.
4. Перевірте сховище: чи щось сканує або завантажує під час гри?
5. Підтвердіть чистим завантаженням і мінімальними елементами запуску для ізоляції.

Чекліст D: Коли підозрюєте I/O і кеш шейдерів

1. Підтвердіть, що гра і кеш шейдерів розміщені на швидкому локальному SSD.
2. Спостерігайте iostat -xz і vmstat під час стутеру.
3. Переконайтеся, що достатньо вільного місця; SSD поводяться дивно, коли заповнені.
4. Очікуйте, що перший запуск з компіляцією шейдерів стутеритиме. Міряйте другий запуск.

Поширені запитання

1) Якщо CPU однаковий, хіба FPS не має бути однаковим?

Ні. CPU — це компонент; ОС вирішує планування, стани живлення, поведінку таймерів, маршрутизацію переривань і взаємодію з драйверами. Це змінює ефективну поведінку CPU.

2) Чому середні значення збігаються, але 1% lows різняться?

Тому що стрибки походять від конкуренції й затримок: фоновий I/O, звільнення пам’яті, переривання, компіляція шейдерів і синхронізація композитора. Середнє ховає біль.

3) Чи Linux завжди повільніший для ігор?

Ні. Нативні проєкти на Vulkan можуть працювати винятково добре. Але шари перекладу (DXVK/vkd3d), поведінка композитора і відмінності драйверів можуть зміщувати результати в будь-яку сторону.

4) Чи «performance governor» завжди допомагає в Linux?

Часто він покращує стабільність часу кадру, зменшуючи затримки підвищення частоти. Але він може збільшити тепло і спричинити тротлінг, що може анулювати виграш. Міряйте при стійкому навантаженні.

5) Чи більше ОЗП зменшить стутер?

Якщо у вас є пейджинг або агресивне звільнення — так, драматично. Якщо запас ОЗП вже є — більше пам’яті не вирішить накладні витрати драйверів або латентність композитора.

6) Чому перехід з Wayland на X11 змінює FPS?

Тому що різні композитори й шляхи презенту. Підтримка VRR, примусове vsync і управління буферами відрізняються за композитором і драйвером — і ці відмінності проявляються як затримка і подача кадрів.

7) Чи CPU-вразливості й пом’якшення — реальний фактор FPS?

Іноді. Вони можуть підвищувати вартість системних викликів і контекстних переключень та впливати на бар’єри пам’яті. Ефект залежить від CPU, ядра й навантаження. Не сперечайтесь — бенчмаркуйте.

8) Чи справді сховище пов’язане з FPS?

Для середнього FPS зазвичай ні. Для стрибків часу кадру — однозначно, особливо в іграх з інтенсивним стрімінгом ресурсів і під час активності кешу шейдерів. Якщо ви бачите I/O wait під час просідань — сховище в справі.

9) Чи варто прив’язувати гру до конкретних ядер?

Тільки після того, як ви довели проблему планування/переривань. Прив’язка (affinity) може допомогти або шкодити, заштовхнувши гру на ядро з високою активністю переривань або позбавивши робочі потоки ресурсів.

10) Чому Proton іноді випереджає Windows?

Таке трапляється, коли Vulkan‑шлях ефективніший за нативний DirectX на Windows або коли поведінка драйвера сприятливіша. Це залежить від навантаження, а не є універсальним правилом.

Наступні кроки, які справді дають результат

Якщо ви хочете дійсних результатів замість нескінченних дебатів «Windows vs Linux», зробіть таке:

1. Міряйте фреймтайми, а не лише FPS. Слідкуйте за середніми та перцентилями. Стрибки — вороги.
2. Зафіксуйте політику живлення для тестування. Спочатку режим продуктивності, потім цілеспрямовано знижуйте налаштування.
3. Доведіть, чи ви CPU‑bound, GPU‑bound чи I/O‑stall. Використовуйте perf, графіки використання і iostat/vmstat.
4. Контролюйте середовище. Ті самі драйвери, той самий режим композитора, ті самі фонові служби. Ставте це як вікно змін у продакшні.
5. Змініть тільки одну річ за раз. Якщо ви за раз змінюєте ОС, драйвер, ядро, governor, композитор і налаштування гри — ви не тестуєте, ви кидаєте кості.

Windows і Linux — це не просто «шкіри» на одному CPU. Це різні операційні філософії з різними налаштуваннями за замовчуванням. Ваша різниця FPS — це рахунок за ці налаштування. Добра новина: більшість позицій у рахунку деталізовані, і ви можете оскаржити їх — якщо приходите з вимірюваннями.