ls /dev/ntsync in your terminal. If the file exists, you have it. GE-Proton 10-10 and later enable it automatically when the kernel supports it.
Something quietly changed in Linux gaming this year, and most people haven't noticed yet.
In January 2026, Wine 11 shipped with NTSYNC — a kernel driver that's been years in the making and solves a problem that esync and fsync were always just working around. The benchmarks that came out were... kind of absurd. Dirt 3 went from 110 FPS to 860 FPS in the developer tests. Resident Evil 2 nearly tripled. Call of Duty: Black Ops 1 went from unplayable to smooth.
Now, those numbers compare NTSYNC against vanilla Wine with no sync optimizations at all, so the real-world gains for most people are more modest. But here's what's not modest: this is the first time Linux has handled Windows thread synchronization correctly at the kernel level, rather than faking it with clever hacks. That matters, and I want to explain why - in plain English, not kernel patch documentation.
This article covers everything about NTSYNC for Linux gaming: what the problem was, how NTSYNC solves it, who already has it, how to enable it if you don't, and what real-world improvement you should actually expect.
The Problem NTSYNC Solves (And Why Nobody Fixed It Sooner)
Modern games don't run on one thread. They run on dozens simultaneously - one for rendering, one for physics, one for audio, one for AI, one for streaming assets from disk. All of those threads need to coordinate constantly. One thread can't render a frame until another thread has finished loading the textures for it. That coordination happens through what Windows calls synchronization primitives -mutexes, semaphores, events, and similar constructs built into the Windows NT kernel.
When you run a Windows game on Linux through Wine or Proton, those synchronization calls need to happen somehow. Wine historically did it by routing every single sync call through a dedicated background process called wineserver. The game calls a sync primitive → the call goes to wineserver → wineserver handles it → the response comes back. That's a round-trip every time. In a simple older game that barely touches threading, you'd never notice. In a modern AAA game hammering those primitives thousands of times per second, that round-trip overhead adds up fast. The result: stutters. Frame time spikes. That nagging feeling that something's wrong even when your FPS counter looks fine.
The developer community knew about this. Two workarounds emerged:
- Esync - Used Linux's
eventfdsystem call to skip some wineserver round-trips. It helped, but it gave every sync object its own file descriptor, which hit system limits in games that created hundreds of them simultaneously. - Fsync - Used Linux futexes for better performance. Faster than esync, but it required out-of-tree kernel patches that never made it into the mainline Linux kernel. You needed a custom or community-patched kernel to use it. Fine for enthusiasts on CachyOS or with Proton-GE builds - not accessible for someone on stock Ubuntu or Fedora.
Both were workarounds. They approximated Windows sync behavior using Linux primitives that weren't designed for it. Close enough for most games, but never architecturally correct.
What NTSYNC Actually Is
NTSYNC takes the only approach that can actually fix the underlying problem: add the Windows NT synchronization API directly to the Linux kernel.
Instead of mapping Windows sync calls to existing Linux primitives (which behave differently), NTSYNC adds a kernel driver that exposes a /dev/ntsync device. This driver models the Windows NT synchronization object API natively. When Wine talks to it, the kernel handles the coordination directly - proper queue management, proper event semantics, proper atomic operations. No wineserver round-trips. No approximation.
The developer behind it is Elizabeth Figura, a CodeWeavers engineer. She's the same person who wrote esync and fsync — she understood the problem at every level. She presented the NTSYNC patch set at the Linux Plumbers Conference in 2023, iterated through multiple kernel patch revisions over several years, and finally got it merged into mainline Linux with kernel 6.14 in January 2026.
That last part matters. NTSYNC is in the mainline Linux kernel. Not a custom patch, not an out-of-tree module, not something requiring a community build. Any distro shipping kernel 6.14 or later gets it. You don't need to compile anything.
Does Your System Already Have NTSYNC?
Open a terminal and run this:
ls /dev/ntsyncIf it returns the path — you have it. If it says "No such file or directory," you either need a newer kernel or the module isn't loaded yet.
NTSYNC Availability by Distro (May 2026)
Here's the current state across the major distros:
- Arch Linux / EndeavourOS - NTSYNC available since kernel 6.15 shipped to the repos. Load it with
sudo modprobe ntsync. To make it persist across reboots:echo "ntsync" | sudo tee /etc/modules-load.d/ntsync.conf - Fedora 44 - Ships with kernel 6.14+, NTSYNC module included. Same modprobe command to load.
- Bazzite - Rolling updates mean most current installs have NTSYNC-capable kernels. GE-Proton (bundled by default) enables it automatically once
/dev/ntsyncis present. - Ubuntu 25.04 — Ships with kernel 6.14. Check with
uname -r, then load withsudo modprobe ntsync. - Ubuntu 24.04 LTS - Stuck on an older kernel. You won't have NTSYNC without manually upgrading your kernel, which isn't supported for LTS installs. Wait for 26.04 LTS or consider switching to Fedora if gaming performance is a priority.
- Linux Mint 22 - Uses Ubuntu 24.04 base. Same situation — no NTSYNC on the default kernel. The community has worked around this by running the hardware enablement kernel (kernel 6.14 is available through HWE), which does include NTSYNC as a module.
- Pop!_OS - System76 controls their kernel schedule. Check
uname -r— if you're on 6.14 or higher, modprobe it in. - SteamOS — Valve stated they already ship fsync in SteamOS and considered it as fast or faster for their use case. NTSYNC arrived in SteamOS 3.7.20 beta. The stable Steam Deck experience is prioritized over bleeding-edge sync implementations.
Quick Kernel Version Check
uname -rIf the first number is 6.14 or higher, your kernel has NTSYNC support. The module just needs to be loaded.
How to Enable NTSYNC for Linux Gaming
Enabling it depends on your setup. Here are the three paths:
Path 1: GE-Proton 10-10 or Later (Easiest — Recommended)
If you're using GE-Proton 10-10 or any later version, NTSYNC enables automatically when your kernel supports it. No launch flags needed. The launcher detects /dev/ntsync and uses it.
To confirm GE-Proton is using NTSYNC, check your Steam console log:
cat ~/.steam/steam/logs/console-linux.txt | grep -i ntsyncIf you see wineserver: NTSync up and running! — it's active.
Don't have GE-Proton installed? Use ProtonUp-Qt. Install it, open it, click Download, select the latest GE-Proton version. Then in Steam: right-click game → Properties → Compatibility → Force use of → pick GE-Proton.
Path 2: Manual Kernel Module Load
If you have kernel 6.14+ but /dev/ntsync doesn't exist yet, load the module manually:
sudo modprobe ntsyncThen verify:
ls /dev/ntsyncTo make it load automatically on every boot:
echo "ntsync" | sudo tee /etc/modules-load.d/ntsync.confAfter that, GE-Proton 10-10+ picks it up automatically. No extra configuration.
Path 3: Older GE-Proton Builds (Manual Flag)
If you're on GE-Proton 10-9 specifically (not 10-10+), add this to your Steam game's launch options:
PROTON_USE_NTSYNC=1 %command%Right-click game → Properties → General → Launch Options → paste it in. From GE-Proton 10-10 onward this flag isn't needed — it's on by default.
lsmod | grep ntsync. If you see ntsync in the output, the module is loaded. If the output is blank, run sudo modprobe ntsync and try again.
NTSYNC vs Fsync vs Esync: What's the Actual Difference?
Since these three names come up constantly in Linux gaming forums, here's the clearest comparison I can write:
- Esync - Uses Linux
eventfd. Reduces wineserver round-trips. Ships in standard Proton since 2018. Works everywhere. The limitation: one file descriptor per sync object, and games that create hundreds of them can hit system descriptor limits, causing crashes or freezes. Workaround:ulimit -n 524288. - Fsync - Uses Linux futexes (specifically
futex_wait_multiple, not mainline futex). Faster than esync and no descriptor limit. Ships in Proton-GE and CachyOS kernels. The catch: required an out-of-tree kernel patch that never hit mainline. If you're on a stock distro kernel, you've never had real fsync. - NTSYNC - Kernel-level driver modeling the actual Windows NT sync API. No wineserver, no approximation. Mainline kernel since 6.14. Correct behavior, not just close-enough behavior. For most Proton users upgrading from fsync, expect stutter reduction and better frame pacing more than raw FPS gains.
The short version: NTSYNC is the right solution. Esync and fsync were smart workarounds that worked for years. They were the best option available at the time, but they were always approximations. NTSYNC is what should have existed all along - and now it does, in the mainline kernel, for everyone.
What Improvement Should You Actually Expect?
Real talk: the 678% Dirt 3 benchmark is not your benchmark. Those developer numbers are comparing NTSYNC against unpatched Wine with no sync optimizations at all. Nobody who games on Linux uses that.
Here's what NTSYNC realistically does for different situations:
If You Were Using Fsync (Proton-GE, CachyOS kernel)
Modest but real gains. Expect smoother frame delivery in heavily multi-threaded games, fewer one-frame hitches, and more consistent 1% lows. Raw FPS probably similar. The correctness improvement is more meaningful than the number improvement - games that had subtle sync-related glitches may just stop having them.
If You Were on Stock Proton with Esync Only
More noticeable improvement, particularly in newer AAA titles that hammer CPU threads hard. Frame times tighten up, stutters in dense scenes become less frequent. I'd expect 5–15% improvement in 1% lows in the titles that benefit most.
If You Were on Vanilla Wine (No Esync, No Fsync)
This is where the dramatic numbers come from. If you've been running games through bare Wine without esync or fsync for some reason, NTSYNC is going to feel like you upgraded your CPU.
Games That Benefit Most
CPU-intensive, heavily multi-threaded titles see the biggest gains. Older DirectX 9/11 games that were always a bit choppy on Linux but ran fine on Windows. Games that previously hit the descriptor limit with esync. The Call of Duty series (especially older titles) is frequently cited as a major beneficiary. Titles that felt "wrong" on Linux even when the FPS number looked right.
Games That Won't Change Much
GPU-limited games at high resolutions. Native Linux games (NTSYNC only applies to Wine/Proton compatibility). Games that were already running perfectly with Proton-GE's fsync implementation.
Troubleshooting NTSYNC on Linux
/dev/ntsync Doesn't Exist
Your kernel doesn't have the NTSYNC module, or it hasn't been loaded yet. Check your kernel version with uname -r. If it's below 6.14, you need a newer kernel. If it's 6.14+, run sudo modprobe ntsync to load the module and verify with ls /dev/ntsync.
Module Loads but Disappears After Reboot
The modprobe command only loads the module for the current session. Make it permanent with:
echo "ntsync" | sudo tee /etc/modules-load.d/ntsync.conf
Game Performance Got Worse After Enabling NTSYNC
This happens occasionally. Not every game benefits from NTSYNC, and some have actually regressed slightly in certain configurations. If a specific game runs worse, remove the PROTON_USE_NTSYNC=1 launch flag (for older GE-Proton builds) or switch back to an older Proton version that used fsync. GE-Proton 9.x series is the fallback.
32-bit Game Crashes with NTSYNC
32-bit applications sometimes need WoW64 mode alongside NTSYNC. In GE-Proton 10-9 you needed to add PROTON_USE_WOW64=1 to launch options. From GE-Proton 10-10 onward this is handled automatically — update your GE-Proton version and the crash should go away.
Game Shows NTSYNC Active in Logs but Performance Unchanged
If your game was already GPU-bottlenecked, CPU-side sync improvements won't change your frame rate. Lower your resolution or graphics settings temporarily — if performance now scales differently, the change is working but your GPU was the limiter. This is fine and expected behavior.
Frequently Asked Questions About NTSYNC
What is NTSYNC in Linux?
NTSYNC is a Linux kernel driver merged into kernel 6.14 that implements Windows NT synchronization primitives natively in the Linux kernel. It allows Wine and Proton to handle Windows thread synchronization without the performance overhead of routing those calls through a background process (wineserver). The result is better gaming performance and fewer stutters when running Windows games on Linux.
Is NTSYNC better than fsync?
Yes, architecturally. Fsync was a clever workaround that used Linux futexes to approximate Windows sync behavior — and it worked well, but it required out-of-tree kernel patches that never made mainline Linux. NTSYNC implements the correct Windows NT sync semantics directly in the kernel, is in mainline Linux (no custom kernel needed), and produces equal or better performance in most scenarios. For gaming, NTSYNC is the future; fsync was the best option until NTSYNC arrived.
Do I need to do anything to enable NTSYNC?
On most modern distros with kernel 6.14+, you just need to load the module (sudo modprobe ntsync) and use GE-Proton 10-10 or later. GE-Proton auto-detects /dev/ntsync and enables it. Older GE-Proton 10-9 needs the PROTON_USE_NTSYNC=1 launch option. Standard Proton from Valve does not yet have NTSYNC — use GE-Proton to access it.
Does NTSYNC work on the Steam Deck?
The Steam Deck runs SteamOS, which previously shipped fsync, which Valve said was "as fast or faster" for their use case. NTSYNC arrived in SteamOS 3.7.20 beta. Stable Steam Deck builds may not have it yet, but it's coming. Desktop Linux users benefit from NTSYNC sooner.
Which distros have NTSYNC?
Any distro running kernel 6.14 or later can use NTSYNC. This includes current versions of Arch Linux, EndeavourOS, Fedora 44+, Ubuntu 25.04, and Bazzite. Ubuntu 24.04 LTS users need to wait for a newer LTS release or manually install a newer kernel, which isn't officially supported.
Will NTSYNC help with anti-cheat compatibility?
No. NTSYNC improves CPU-side thread synchronization performance. Anti-cheat issues (Valorant, Fortnite) are a separate problem caused by kernel-level anti-cheat software that requires direct kernel access Wine and Proton can't safely provide. NTSYNC doesn't change that situation.
Does standard Proton (from Valve) support NTSYNC?
Not yet, as of early 2026. Valve ships fsync in standard Proton and has said it's sufficient for SteamOS. NTSYNC support in Valve's official Proton is expected but hasn't been announced. GE-Proton (the community build) added NTSYNC in version 10-9, and it's enabled by default from 10-10 onward. Use GE-Proton if you want NTSYNC now.
The Bottom Line on NTSYNC for Linux Gaming
NTSYNC is one of those changes that's hard to see in a benchmark but easy to feel in a gaming session. The stutter that showed up every time you turned a corner in an open-world game. The frame time spike that happened for no obvious reason. The way a game felt slightly off even though the FPS counter looked fine. That's what NTSYNC is fixing.
It's not magic. GPU-limited games at 4K won't suddenly run differently. Anti-cheat blockers are still anti-cheat blockers. And if you were already on Proton-GE with fsync, the upgrade is incremental rather than dramatic.
But the fact that Windows thread synchronization is now correctly implemented in the mainline Linux kernel — not hacked in, not approximated, correctly implemented — is genuinely significant. It's the kind of architectural fix that makes every subsequent improvement easier. Future games that lean even harder on multi-threaded workloads will benefit from it more, not less.
If you're on a distro with kernel 6.14+, load the module, install GE-Proton 10-10+, and let it do its thing. You don't need to configure anything else. The one check worth doing is ls /dev/ntsync and confirming it exists before launching a game. After that, it's transparent.
Linux gaming in 2026 keeps quietly getting better at the stuff that actually matters. NTSYNC is a big part of that.
