TechFuel HQ

Best Motherboards for Ryzen 7 9800X3D (2026)

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 14 min read · St. Louis County, MO

The three boards at a glance

The 9800X3D reaches full gaming speed on a well-built mainstream board. These picks buy three different layouts; CPU performance stays in the same class, so every dollar above the B850 default must purchase a port, lane, form factor, debug control, or expansion path the build will use.

Pick	Best for	The features that justify it	Aug. 17 reference
MSI MAG B850 Tomahawk Max WiFi	Best ATX value for most builds	PCIe 5.0 x16, Gen5 M.2, Wi-Fi 7, 5GbE, strong 80A-stage listing	$209.99 standalone
ASUS ROG Strix B850-G Gaming WiFi	White micro-ATX build	Four M.2, Wi-Fi 7, 2.5GbE, 20Gbps USB-C, PCIe 5.0 x16	ASUS listed $259.99 standalone; bundle was $1,059.99
ASUS ROG Crosshair X870E Hero	Storage, USB4, and expansion-heavy build	Five M.2, SlimSAS, dual USB4, 5GbE + 2.5GbE, Wi-Fi 7	ASUS listed $569.99 standalone; bundle was $1,599.99

The standalone MSI price is a dated Newegg feed snapshot. The ASUS figures came from the official product-page offers captured on August 18. The bundle figures are current retailer snapshots described later. Check the live number before ordering.

The rule that prevents motherboard overspending

Buy the cheapest well-built board that has the ports you will use. Then verify its slot and lane map. Write those requirements down before opening retailer tabs; otherwise every extra feature looks useful in isolation.

The Ryzen 7 9800X3D is an eight-core, 120W AM5 processor. A decent B850 board already supplies ample CPU power. Moving to X870 or X870E changes the connectivity floor and lane layout; it does not add gaming frames by itself.

I would reject a board for:

no BIOS Flashback on an expensive build
weak rear I/O for the devices you own
only gigabit Ethernet when faster networking matters
a lane-sharing rule that disables a card or drive you plan to install
too few M.2 slots for the build’s life
a price that approaches premium X870E territory without premium I/O

A lower chipset rung does not disqualify a board. A missing port or broken lane plan does.

1. MSI B850 Tomahawk Max WiFi is the default

The B850 Tomahawk Max WiFi is the board I would put under a 9800X3D gaming system unless the build brief names a reason to move. That reason should be concrete: a smaller white case, five NVMe drives, USB4 peripherals, or an add-in-card layout this board cannot serve.

The exact Newegg row lists:

ATX form factor
B850 chipset and AM5 socket
PCIe 5.0 x16
a Gen5 M.2 slot
Wi-Fi 7
5GbE
four DDR5 slots
four SATA ports
an 80A smart-power-stage design

That is the useful part of a modern high-end platform without a flagship tax. The August 17 feed captured $209.99 against a $229.99 regular field. Even if the live price moves, the board belongs in the low-$200 class. A $500 board serves a different build.

There is one layout caveat in the retailer specification: the lower PCIe 4.0 x4-length slot drops to x2 when M.2_3 is populated. If you plan to run a fast capture card, storage adapter, or 10GbE NIC there, read the manual before filling every M.2 slot. Gaming builds with one GPU will rarely care. Hybrid workstation and homelab builds can care immediately.

For a gaming tower with one GPU, two or three NVMe drives, and onboard networking, this is the complete answer.

2. ROG Strix B850-G is the white micro-ATX pick

The B850-G exists for a different build. It compresses a premium-looking white AM5 platform into micro-ATX without stripping the storage and rear I/O that usually disappear first.

ASUS specifies:

micro-ATX
14+2+1 power stages
PCIe 5.0 x16
four M.2 slots, including one Gen5 slot
Wi-Fi 7
Intel 2.5GbE
ten rear USB ports, led by 20Gbps Type-C
BIOS Flashback and Clear CMOS buttons

The fourth M.2 slot sits on the underside, which matters for access and cooling. Two SATA ports are also lean for anyone reusing several 2.5-inch drives. Those layout costs should be in the case plan. Install the underside SSD before the board goes into the chassis; discovering it later turns a two-minute upgrade into a teardown.

ASUS’s page listed $259.99 at capture. That premium over the MSI buys a smaller white board and its particular I/O arrangement. It does not buy a faster 9800X3D.

Search NeweggLink checked 2026-08-18

3. Crosshair X870E Hero is for expansion

The Crosshair X870E Hero is not the “best gaming” choice. It is the choice for a system that needs to behave like a workstation while keeping an X3D gaming CPU.

Its reason to exist is the I/O map:

five M.2 slots, three of them Gen5 with a Ryzen 9000 or 7000 processor
SlimSAS plus four SATA ports
two USB4 40Gbps rear ports
eight additional 10Gbps rear USB ports
5GbE and 2.5GbE
Wi-Fi 7
two full-length CPU-connected slots with configurable lane sharing
onboard Q-Code, start controls, BIOS Flashback, and Clear CMOS

The lane-sharing rules deserve attention. Populate the second and third CPU-connected M.2 slots and the primary graphics slot can fall to x8 while the second full-length slot changes or disables. That is normal on a feature-dense desktop platform, but it means the installation order needs a plan. Sketch the final drive and card map first. Buying five slots is useless if populating the wrong two breaks the slot you bought the board to gain.

ASUS listed $569.99 at capture. Spend that only when the five-drive layout, USB4, dual wired networking, or slot flexibility replaces hardware you would otherwise add. A single-GPU gaming PC with two drives does not need it.

Search NeweggLink checked 2026-08-18

B850 vs X870 vs X870E for the 9800X3D

Chipset class	Buy it when	Do not buy it for
B850	One GPU, normal NVMe count, gaming-first value	More FPS from the CPU
X870	You want USB4 and a stronger modern-I/O baseline	A belief that “X” means faster games
X870E	You need more high-speed expansion and can map the lanes	One GPU, two drives, and no add-in cards

AMD’s AM5 chipset table is the right starting point, but a model’s manual is the final authority. Two boards with the same chipset can expose different slots and controllers. Their sharing rules can differ too.

That is why the shortlist crosses chipset tiers. It follows build requirements.

Are the CPU bundles worth it?

The August feed contained several Ryzen 7 9800X3D motherboard bundles. Three illustrate why “bundle” is not a synonym for “deal.”

Bundle	Aug. 17 snapshot	Rendered seller check, Aug. 18	What to verify
Sapphire NITRO+ B850M + 9800X3D	$969.99	TECH EDGE; new; ships from China; not fulfilled by Newegg	Manufacturer warranty flag was false; returns were non-replaceable
ASUS ROG Strix B850-G + 9800X3D	$1,059.99	TECH EDGE; new; ships from China; not fulfilled by Newegg	Manufacturer warranty flag was true; still compare return freight and delivery
ASUS Crosshair X870E Hero + 9800X3D	$1,599.99	TECH EDGE; new; ships from China; not fulfilled by Newegg	Manufacturer warranty flag was true; the premium only works if you need the board

The seller was rated 4.6/5 over 39 reviews in the prior 12 months and marked Top Rated in the embedded listing data at capture. That is useful context. It is not the same purchase path as a direct Newegg item. A heavy motherboard-and-CPU return to China can consume the paper discount in freight and delay. It also adds transit risk.

Price the CPU and board separately first. Newegg’s exact 9800X3D row was $479 in the same feed. Add the $209.99 MSI board and the parts total is $688.99 before tax. A $969.99 micro-ATX bundle therefore needs to justify roughly $281 through a different board, availability, or terms. The Crosshair bundle is a specialist purchase rather than a value shortcut.

If you still want a bundle, use the current searches below and inspect the exact seller block before payment.

Search NeweggLink checked 2026-08-18

What about B650 and X670?

You do not need to replace a good AM5 board merely because B850 and X870 exist.

If you already own B650, B650E, X670, or X670E, check the manufacturer’s 9800X3D BIOS support and the ports you need. A supported existing board is usually the value winner. The ROG Strix B650-A review covers one real example of a B650 board running an X3D system with ample power delivery.

Before a BIOS update, back up important data and do not interrupt power during the flash. Use BIOS Flashback when the board supports it and the installed CPU cannot boot the current firmware.

This page covers a new board purchase. A working compatible platform should stay in service.

RAM, cooling, and the rest of the build

Use two DDR5 modules. DDR5-6000 with an AMD EXPO profile is the low-drama target; the DDR5 buying guide explains why a larger advertised number is not automatically a better AM5 result. For the purchase itself, use the open RAM price index: its August 18 capture reviewed 583 listings, still found only three of 12 tracked kits that cleared the direct-retailer rules, and put the cheapest qualifying 32GB observation at $459.99. The gate remains closed, so treat the table as dated offers rather than a broad market average.

The 9800X3D does not include a cooler. Board selection should therefore leave room in the case and budget for the cooling hardware you want. The board does not need a giant VRM heatsink to survive this CPU, but the case still needs airflow across the socket, memory, SSD heatsinks, and graphics card. Header placement matters here: count pump and fan headers against the actual radiator and case layout, rather than assuming a premium board has one in the convenient corner.

One build can overturn the entire default. Imagine a 9800X3D workstation with an RTX 5080, three Gen5 scratch drives, two more archive SSDs, a capture card, 10GbE today, and a USB4 RAID enclosure already on the desk. The Crosshair’s price is suddenly easier to defend because one board replaces an add-in network card, a storage adapter, and a Thunderbolt-style expansion plan. Remove those devices and the logic collapses back to B850. That is the standard: every premium interface should displace another cost or solve a named constraint. The workstation case can defend the X870E premium because its five-drive map, USB4 enclosure, faster wired links, debug controls, and second expansion slot replace a pile of adapters while keeping the build coherent; a one-GPU gaming tower with two SSDs receives none of that value, even though both machines use the same processor and can post the same frame rate. Run the same test in reverse before paying: remove USB4, the fifth drive, the second network link, and the extra card from the parts plan; if the system still works exactly as intended, the premium board has lost every job that made it rational and the B850 choice is stronger.

Finally, map the whole build before checkout:

exact case form factor
GPU thickness and slot obstruction
number of M.2 and SATA drives
front USB-C header requirement
wired network speed
add-in cards now and later
fan and pump-header count

The PC Builder catches the basic socket and form-factor problems. Its open 126-part compatibility dataset exposes the source and last-verified date behind each supported row. The board manual catches the lane-sharing rules that a category-level dataset cannot.

The shortest honest recommendation

Buy the MSI B850 Tomahawk Max WiFi for a normal ATX 9800X3D gaming build.

Buy the ROG Strix B850-G when the machine must be white and micro-ATX.

Buy the Crosshair X870E Hero only when five M.2 slots, USB4, dual wired networking, or its expansion controls are already part of the plan.

Anything beyond that is paying for a feature list you have not assigned a job.

Best RTX 5080 Prebuilt Gaming PCs (2026)

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 13 min read · St. Louis County, MO

The three picks at a glance

All three finalists use the same performance core: Ryzen 7 9800X3D, GeForce RTX 5080 16GB, 32GB DDR5, and a 2TB NVMe SSD. The table therefore ranks what usually stays hidden in a prebuilt listing.

Pick	Why it made the list	Disclosed power supply	Newegg feed snapshot, Aug. 17
ABS Kaze II Ruby	Best disclosed parts list and power hardware	Gamdias HELIOS P2-1000G, 1000W Gold	$2,939.99
Andromeda Insights V3 Ultra 50	Best value; explicitly lists DDR5-6000 and an 850W Gold supply	850W Gold, brand not stated	$2,799.99
Acer Nitro UD.P02AA.070	Brand-name alternative with liquid cooling	850W, efficiency and model not stated	$3,299.99

Those prices are dated retailer-feed snapshots. The exact Newegg pages still resolved to the matching item on August 18, and all three pages showed Newegg as both seller and shipper at capture. Inventory can move before this page does.

How I ranked the systems

I started with a hard floor, then let disclosed component quality break the tie. A product page that names the PSU model, memory arrangement, storage generation, board, and seller path can justify a modest premium because each disclosed field removes a return-window investigation; a page that repeats only the CPU and GPU cannot.

RTX 5080 16GB and Ryzen 7 9800X3D. A cheaper processor can still run a 5080, but it is less hardware at this price. Every finalist uses AMD’s eight-core X3D chip.
32GB DDR5 and 2TB NVMe. A $3,000 gaming PC should not arrive with 16GB or a cramped 1TB system drive.
At least 850W. NVIDIA lists 850W minimum system power for the 360W RTX 5080. The full RTX 50-series PSU guide explains when 1000W becomes the better buy.
A listing that names the weak links. PSU model, memory speed, motherboard, cooler, seller, and warranty matter. Silence is a risk, not a premium feature.
The title, item number, and destination had to agree. I discarded feed rows whose product name and Newegg URL described different hardware.

RGB earned zero points. A giant discount badge against a price the system may never have sold for earned zero too.

1. ABS Kaze II Ruby has the strongest disclosed parts list

The Kaze II Ruby wins because its parts list answers the most expensive hidden question. Newegg names the power supply as a Gamdias HELIOS P2-1000G 1000W 80 Plus Gold unit. That changes the decision: the other two finalists list capacity, but they never identify the complete model.

The rest is the right shape for a high-end gaming system:

Ryzen 7 9800X3D
RTX 5080 16GB
32GB DDR5
2TB PCIe NVMe SSD
Wi-Fi 6
Windows 11 Home

The August 17 feed showed $2,939.99, down from a listed $3,499.99 regular figure. I care more about the $2,939.99 checkout number than the size of that markdown. The flashy percentage badge can disappear tomorrow; the named power supply is still the hardware inside the case.

There are still three checks to make. Confirm the 32GB arrives as two modules, identify the motherboard, and read the current warranty and return language. A named PSU does not make every undisclosed part disappear. It does make this the easiest system to approve. If the checkout configuration swaps any of those fields, stop and re-price the machine.

2. Andromeda V3 Ultra 50 is the value pick

The Andromeda was the least expensive qualified system in the feed at $2,799.99. It also discloses more memory detail than the other listings: 32GB of DDR5-6000. The 2TB drive is described as Gen4, and the power supply is rated 850W Gold.

That is a strong specification sheet for $140 less than the ABS. The trade is confidence around the power supply. “850W Gold” tells you the capacity and efficiency tier; it does not identify the platform, protections, cable, or warranty. NVIDIA’s 850W floor means the capacity is sufficient. The missing model is why this system finishes second. Ask for the exact unit before the return window closes; a photo of the side label settles it in seconds.

The exact page showed the matching Andromeda title. Newegg handled both the sale and shipment from the United States when checked. That removes the marketplace ambiguity that sinks many cheaper-looking results.

Buy this one when the price gap matters and the listing or support team can provide the exact PSU and memory configuration before the return window closes.

Check NeweggLink checked 2026-08-18

3. Acer Nitro is the brand-name alternative

Acer’s Nitro UD.P02AA.070 keeps the same core specification and adds liquid CPU cooling. The listing names a Ryzen 7 9800X3D, RTX 5080 16GB, 32GB DDR5, 2TB PCIe NVMe SSD, and an 850W power supply.

It also asks the most. The feed captured $3,299.99, which is $360 above the ABS and $500 above the Andromeda. The listing does not name the PSU model or efficiency certification, and it specifies gigabit Ethernet rather than a faster wired interface.

That does not make the Acer a bad machine. It makes the premium hard to defend from the published parts list alone. Choose it if the exact Acer service package, local availability, or chassis design has value to you. On hardware disclosure per dollar, it ranks third. At this price, brand familiarity needs to arrive with a better support path, not merely a familiar badge.

Check NeweggLink checked 2026-08-18

What I rejected

The live search results contain dozens of RTX 5080 systems. Most fail for one of five reasons.

A lower-tier CPU at the same system price

A Core i7-14700F or Ryzen 7 9700X can be a good processor. It does not belong in a system priced beside these 9800X3D builds unless the rest of the machine is materially better.

Sixteen gigabytes of system memory

That is an immediate upgrade on a new flagship PC. It also raises the chance of a single-module configuration. Thirty-two gigabytes is the floor here.

One terabyte of storage

Modern game libraries fill it quickly. A 2TB system drive is a modest requirement at this budget, and all three picks meet it.

A vague or undersized power supply

The RTX 5080’s official requirement is 850W system power. A listing below that floor is out. A listing that says only “1000W” without a model still needs investigation; wattage cannot tell you build quality.

Marketplace ambiguity

The product page must identify seller and fulfillment. It must also state the condition and warranty. The return path needs to be clear. A low price from an unknown seller can erase its savings with one freight return, and on a 40-pound glass-sided tower the expensive failure is rarely the missing five percent of benchmark performance; it is discovering after delivery that the power supply, memory layout, or warranty differs from the product tile while the only remedy is packing the entire machine again.

The price ceiling for a 32GB and 2TB build

My cutoff for this specification is roughly $3,500 before tax. Cross it, and I want a visible reason:

64GB instead of 32GB
4TB instead of 2TB
a premium factory-overclocked RTX 5080
a clearly better motherboard, PSU, and cooling stack
a service package worth buying

A basic 32GB/2TB system at $3,700 is too close to premium-custom pricing. It also gets uncomfortably close to the next GPU tier. If you are willing to assemble the machine, compare the full bill against the $2,500-class RTX 5080 build and load the same parts into the PC Builder.

What performance should you expect?

NVIDIA specifies the RTX 5080 with 10,752 CUDA cores, 16GB of GDDR7, a 360W total graphics power rating, and an 850W minimum system requirement. The Ryzen 7 9800X3D supplies eight Zen 5 cores and 96MB of L3 cache on AM5.

Those specifications put every finalist in the same broad performance class. Cooler design and the installed GPU model decide some of the small gaps, while power limits, BIOS behavior, and memory configuration decide the rest.

For a measured reference, the ROG Astral RTX 5080 OC review includes first-party 4K results and a 308-sample power log. The open bench dataset carries the underlying game and clock rows, plus thermal and power measurements, under CC BY 4.0. Use it as a picture of what one well-cooled premium 5080 did; an OEM card may hold different clocks.

The practical target is 4K gaming. At 1440p, a cheaper GPU can often deliver the experience without forcing the rest of the build into this price band. The 2026 4K GPU guide maps that break point. If your monitor is still 1440p/144Hz, spend against the display before paying for unused GPU headroom.

Here is the edge case that changes my answer. A buyer who keeps a PC for six years, moves from 1440p to a 4K OLED next spring, runs local models on the 16GB card, and refuses to replace parts mid-cycle can justify buying the 5080 tower before the current monitor demands it. That is a planned multi-use purchase, not a vague future-proofing claim.

There is measured evidence for the local-model half. On TechFuelHQ’s retail RTX 5080, the open Ollama throughput dataset recorded gpt-oss:20b fully GPU-resident at roughly 13.7–14.0 GiB and 187–190 decode tokens per second; the raw CSV is mirrored on Kaggle and Hugging Face. That does not benchmark image generation or prove every 16GB workload fits. It does show that a named local-AI role can be real rather than speculative.

The six-year plan has named workloads and a named display upgrade, with enough time for the premium to spread across several roles. Remove the 4K display and local workload, and the logic collapses: a gaming-only 1440p buyer is left with expensive capability no current screen or workflow can turn into visible value.

The 60-second checkout audit

Do this after clicking through and before payment.

Match the item number to the exact row in this guide.
Confirm Ryzen 7 9800X3D and RTX 5080 16GB in the selected configuration.
Look for two memory modules. If the page stays silent, ask or check immediately after delivery.
Confirm the PSU model and a native 12V-2x6 cable where possible.
Count open M.2 slots and accessible DIMM slots for future upgrades.
Read who sells it and who ships it.
Open the warranty and return terms.
Screenshot the final configuration and delivery promise.

If one of those fields changes, re-rank the system. The model name on the case matters less than the parts and terms attached to the exact SKU, because two towers wearing the same product-family badge can differ in the power supply and memory layout. They can also arrive with a different motherboard, SSD, cooler, seller, warranty, or delivery promise. Those details decide whether a prebuilt stays an easy purchase or becomes an expensive return. The exact-SKU check is the purchase: without it, a familiar family name can hide a lower-tier power supply, one memory module instead of two, a different motherboard, or a return path that turns a small discount into a freight bill after the tower is already in your house.

Best RTX 5090 Prebuilt Gaming PCs (2026)

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 14 min read · St. Louis County, MO

The three picks at a glance

These systems share the expensive core: Ryzen 7 9800X3D, GeForce RTX 5090 32GB, 32GB DDR5, and 2TB of solid-state storage. The ranking turns on the platform around those parts and the price attached to the exact SKU.

Same GPU and CPU. Very different risk.

Pick	Why it made the list	Disclosed power and cooling	Live Newegg price, Aug. 18
Stormcraft Valkyrie	Best pick; most complete useful disclosure	1300W 80 Plus Gold, 360mm AIO	$5,599.99
Acer Nitro N80-181-UR19	Best value; same gaming core for $300 less	1200W, liquid cooling; PSU model not stated	$5,299.99
Thermaltake View 9890S	Premium white X870 alternative; not the value choice	1200W Gold ATX 3.0, Thermaltake 360mm AIO	$6,699.99

All three pages showed sold and shipped by Newegg when captured. These are live-page snapshots. Prices can move. Thermaltake is the important warning: its August 17 affiliate feed showed $6,090.99, but the rendered product page was $6,699.99 on August 18. The checkout page wins that disagreement.

How I ranked the systems

The full August 17 feed held four direct-catalog RTX 5090 desktops. Two Stormcraft rows used the same chassis and price with different processor platforms, so I narrowed the final comparison to the three Ryzen 7 9800X3D systems; holding the gaming CPU, GPU, memory capacity, and storage capacity steady exposes the platform differences instead of burying them under a changing processor.

I then scored the parts that can turn a $5,000-plus computer into a poor purchase:

Power path. NVIDIA rates the RTX 5090 at 575W and specifies 1000W required system power. A 1200W or 1300W supply is the right capacity class here, but capacity is only the start. The model, protections, and native GPU cable still need confirmation.
Memory configuration. Thirty-two gigabytes must be two modules. Acer and Stormcraft explicitly showed 16GB x 2 in the captured specifications.
Cooling and airflow. A 360mm AIO earns confidence only as a disclosed component, not as proof of low temperatures or noise. I have not tested these systems.
Storage and motherboard. A 2TB system drive is the floor. Gen4 detail and a named chipset make future expansion easier to judge.
Seller and price integrity. The item number, title, live price, seller, and shipper had to agree on the rendered page.

RGB, “AI powered,” and giant markdown badges earned nothing. Exact parts and a clean return path did.

1. Stormcraft Valkyrie is the best pick

The Valkyrie asks $300 more than Acer and gives a visible reason for most of that difference. Its product page names:

Ryzen 7 9800X3D
RTX 5090 32GB
32GB as two 16GB DDR5-6000 modules
2TB Gen4 NVMe SSD
AMD B850 motherboard
360mm AIO liquid cooler
seven ARGB fans
1300W 80 Plus Gold power supply

That is the strongest platform disclosure in the direct-retailer set. The 1300W capacity sits above the practical 1200W target in the RTX 50-series PSU guide, and the listing gives the memory speed, module count, storage generation, motherboard chipset, radiator size, and fan count. The page also showed Newegg as both seller and shipper.

Several identities remain hidden: “1300W 80 Plus Gold” does not name the PSU manufacturer or model, and the listing says component brands may vary, which means the exact graphics card, memory kit, SSD, board model, and supply can change within the stated specification. I cannot call those parts premium. The page still tells the buyer more than the others.

At $5,599.99, the Valkyrie is the best choice when you want the 5090 tier and would pay $300 to remove several expensive unknowns. Confirm those fields one final time before ordering.

2. Acer Nitro is the value pick

Acer’s N80-181-UR19 is the lowest-priced direct 9800X3D and RTX 5090 system in the captured feed and live pages. At $5,299.99, it is $300 below the Stormcraft and $1,400 below the Thermaltake.

The useful disclosures are better than the short feed title suggests:

Ryzen 7 9800X3D
RTX 5090 32GB
32GB DDR5 as 16GB x 2
2TB PCIe SSD
1200W power supply
liquid CPU cooling
Wi-Fi 6 and gigabit Ethernet

The 1200W capacity is appropriate. The weak point is identity. The page does not name the PSU model or efficiency certification, and its detailed table says only “Liquid Cooling” even though the title advertises a 240mm AIO. It also leaves the motherboard model and SSD generation unstated.

That makes Acer the value pick, with a plain trade: save $300 and accept less component identity, or pay Stormcraft for DDR5-6000, a named B850 chipset, Gen4 storage detail, a larger listed radiator, and another 100W of supply capacity. Choose Acer when the support channel, chassis, and saving matter more. Photograph the PSU label and memory modules after delivery, before the return window gets short.

Check NeweggLink checked 2026-08-18

3. Thermaltake View 9890S is the premium alternative

The View 9890S has the clearest named cooling and platform combination:

Ryzen 7 9800X3D
RTX 5090 32GB
32GB DDR5-6000
2TB NVMe SSD
AMD X870 chipset
Thermaltake 360mm ARGB AIO
1200W 80 Plus Gold ATX 3.0 power supply
Wi-Fi 7
white panoramic chassis

Those are real differences. X870, a named Thermaltake radiator, Wi-Fi 7, a white build, and a more explicit ATX 3.0 supply description can matter to a buyer who wants this exact design.

The price breaks the general recommendation: the live page showed $6,699.99, or $1,100 above Stormcraft and $1,400 above Acer, while the prior feed showed $6,090.99. At the live number, the premium buys appearance and platform detail rather than more GPU, CPU, memory, or storage capacity.

I would skip that premium for gaming performance. This system stays on the list as the distinct white X870 alternative. It does not compete for value at the captured price. If it falls near the Valkyrie, re-run the comparison.

Check NeweggLink checked 2026-08-18

Why these are 9800X3D systems

At this price, the processor should fit the job. The Ryzen 7 9800X3D is an eight-core, 16-thread, 120W AM5 processor with 96MB of L3 cache. It is the gaming-first choice in the captured direct-retailer set.

The feed also held a $5,599.99 Stormcraft Valkyrie with an Intel Core Ultra 7 270K Plus, a system that can make sense for a different workload mix but would blur this gaming comparison by changing the processor platform while every other finalist stays on the 9800X3D.

I kept the CPU constant on purpose. Once every row uses a 9800X3D and RTX 5090, the reader can compare the system rather than decoding two product categories at once.

What a $5,000-plus prebuilt must disclose

The expensive GPU cannot be permission for everything around it to become vague. A machine at this price should make its electrical and upgrade constraints easy to inspect before you pay, then easy to verify again when the box arrives. Two facts from this comparison show why the second check matters. Thermaltake’s live price had moved $609 above the prior feed snapshot. Stormcraft warns that component brands may vary inside the stated configuration. Save the checkout screenshot. When the box arrives, compare the delivered graphics card and power supply against the order. Check the memory module count and motherboard next. Finish with the SSD and cooler. Inspect the cabling before the return window gets short.

A native high-current power path

NVIDIA lists 575W total graphics power and 1000W required system power for the RTX 5090. A capacity label of 1200W or 1300W clears the first test. The exact PSU model and a native cable clear the second.

Avoid treating four adapter leads as a harmless visual issue. This is a high-current connection behind a large card. Confirm the cable type, seat it fully, and avoid a tight bend at the connector.

Two memory modules

The captured Acer and Stormcraft pages showed 16GB x 2. Thermaltake disclosed 32GB DDR5-6000 but did not expose the module count in the same table. Confirm two modules before accepting the configuration.

Thirty-two gigabytes is enough for gaming. The DDR5 buying guide covers capacity and timing tradeoffs if this tower will also be a 64GB creator or local-AI machine.

Storage that fits the price

Two terabytes is the floor at this tier. Stormcraft identifies its drive as Gen4. Acer says 2TB PCIe, while Thermaltake says 2TB NVMe. None of those capacity lines tells you controller, endurance, or sustained write behavior.

Identify the installed SSD after delivery and count the open M.2 slots. A $5,500 tower should not require replacing its only system drive just to add working space.

A motherboard and case you can expand

Stormcraft discloses B850. Thermaltake discloses X870. Acer leaves the board unnamed in the saved specification. The chipset will not create gaming frames. It does help define storage lanes and USB. It also tells you more about networking and future cards.

Case dimensions and slot clearance matter too. An RTX 5090 is not a small component. Confirm that the installed model has room to breathe and that adding another card or bottom-mounted fans will not choke it.

RTX 5090 or RTX 5080 prebuilt?

The RTX 5090 tier needs a named reason. Mine would be one of these:

maximum native or lightly upscaled 4K performance
a 4K high-refresh display that can expose the difference
32GB of VRAM for local AI, rendering, or creation
one machine serving both gaming and a GPU-heavy paid workload

If the computer is for ordinary 1440p gaming or 4K with DLSS, the best RTX 5080 prebuilt guide starts at $2,799.99 in the same dated retailer feed. The jump from that value pick to the least expensive 5090 system here was $2,500. That money can buy a serious display and a later GPU upgrade. It can also fund the memory and storage the system will use every day.

The RTX 5090 is faster. It is not automatically the better purchase. NVIDIA’s official specifications put the difference in plain terms: 32GB versus 16GB of GDDR7 and a 575W versus 360W power rating. The 2026 4K GPU guide places both cards in the wider buying ladder.

The price ceiling

My practical ceiling for this configuration is about $6,000 before tax. That means a 9800X3D, 32GB, 2TB, and an RTX 5090. Cross the line only when the premium buys something you can name.

Above that line, I want several of these:

64GB of memory
4TB or more of quality storage
an explicitly named premium RTX 5090 model
a named high-end power supply
a motherboard and networking stack worth the difference
a service package with measurable value
a chassis and cooling configuration you were already willing to buy separately

Thermaltake’s live $6,699.99 can be defended only by the buyer who already values its white panoramic design, X870 platform, Wi-Fi 7, named 360mm cooler, and ATX 3.0 power description. Those features do not make it $1,100 faster than Stormcraft.

The 60-second checkout audit

Do this after clicking through and before payment.

Match the item number to the exact system in this guide.
Confirm Ryzen 7 9800X3D, RTX 5090 32GB, 32GB DDR5, and 2TB storage.
Look for two memory modules and record their speed.
Identify the exact PSU model and native GPU cable.
Identify the graphics-card, motherboard, SSD, and cooler models.
Confirm who sells it and who ships it.
Open the warranty and return terms, including freight.
Check case clearance, open M.2 slots, and usable expansion slots.
Screenshot the final configuration, price, delivery date, and seller block.

If the configuration changes, the ranking changes with it. At this price, a family name is not a substitute for the exact hardware and terms you are buying.

Best Wi-Fi 7 Routers (2026): 3 Picks That Make Sense

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 13 min read · St. Louis County, MO

Three picks at a glance

Choose the band layout first. Then count the ports. A giant aggregate speed number comes last because no single client receives the whole number printed on the box.

Pick	Best for	Radio layout	Useful wired I/O	Live price, Aug. 18
TP-Link Archer BE550 Pro	Best for most homes	Tri-band: 2.4 + 5 + 6GHz	1× 10G WAN, 4× 2.5G LAN	$229.99
ASUS RT-BE88U	Wired-first router and switch replacement	Dual-band: 2.4 + 5GHz; no 6GHz	10G SFP+, 10G WAN/LAN, 4× 2.5G, 4× 1G	$338.99
ASUS GT-BE98 Pro	Premium wireless capacity and dual-6GHz AiMesh	Quad-band: 2.4 + 5 + 6 + 6GHz	10G WAN/LAN, 10G LAN, 3× 2.5G LAN	$629.99

These are dated direct-listing prices. The exact pages resolved and showed the matching product in stock at capture, but the seller and price can move before this article does.

The decision before the product

This page assumes you have already decided Wi-Fi 7 is worth buying. If that question is still open, start with Wi-Fi 7 for the home network and homelab. It covers real throughput, MLO, client support, and the cases where Wi-Fi 6E should stay in service.

For the purchase itself, write down four facts:

Does the router need 6GHz? If 320MHz channels are part of the plan, yes.
What feeds the router? Gigabit, 2.5Gbps, 5Gbps, or 10Gbps internet changes the WAN requirement.
What sits behind it? A NAS, multi-gig switch, or wired gaming PCs decide the LAN ports.
Is one access point enough? A large or difficult house may need mesh instead of a more expensive standalone box.

The best router is the least expensive one that serves those four constraints. The rest is unused radio inventory. A flagship only earns its place when the second 6GHz radio, extra 10G path, or denser wired switch replaces another box or fixes a measured bottleneck; without that job, the premium buys capacity that sits idle while the same phone and laptop behave much as they would on the midrange router.

1. TP-Link Archer BE550 Pro is the best pick

The Archer BE550 Pro is the rare midrange router whose wireless and wired sides match. TP-Link specifies three bands, including 6GHz, with 320MHz channels and MLO. The wired side has one 10Gbps WAN port and four 2.5Gbps LAN ports.

That combination matters more than the BE9700/BE9300 naming inconsistency between TP-Link and the retailer feed. A fast Wi-Fi client can reach a multi-gig NAS without being pinched through a gigabit LAN port. A 5Gbps fiber service can enter through the 10G WAN port. Four 2.5G LAN ports also remove the immediate need for a small multi-gig switch in many homes.

At $229.99, it sits where the existing technology guide said useful tri-band Wi-Fi 7 should sit: the low-to-mid $200s. It is $109 below the RT-BE88U and $400 below the GT-BE98 Pro.

I would still verify three details at checkout. Match BE550 Pro, not the nearby BE550 family name. Confirm the regional version. Then check that the phone, laptop, or desktop you expect to speed up supports 6GHz Wi-Fi 7; a router cannot add a radio to the client.

2. ASUS RT-BE88U is the wired-first exception

The RT-BE88U is an unusual recommendation because its strongest feature is also the reason many Wi-Fi 7 buyers should skip it.

ASUS calls it dual-band. The official specification and Newegg table show only 2.4GHz and 5GHz wireless. There is no 6GHz radio, so there are no 320MHz 6GHz channels. Put that fact above every marketing number.

The wired layout is excellent:

one 10G SFP+ port
one standard 10G WAN/LAN port
four 2.5G ports
four gigabit ports
WAN/LAN aggregation options

For a homelab or fiber gateway, that can replace both a consumer router and a separate multi-gig switch. The SFP+ port is especially useful when the existing core already speaks DAC or fiber. At $338.99, the additional $109 over TP-Link can be cheaper than buying an extra managed switch.

For a wireless-first buyer, the logic reverses. Spending more while losing 6GHz makes no sense when the reason for the upgrade is wide-channel Wi-Fi. This is the port-density pick. Nothing else.

Check NeweggLink checked 2026-08-18

3. ASUS GT-BE98 Pro is the flagship

The GT-BE98 Pro carries four radios: 2.4GHz and 5GHz plus two separate 6GHz bands. ASUS pairs that with 320MHz support, one 10G WAN/LAN port, another 10G LAN port, three 2.5G LAN ports, plus AiMesh.

The second 6GHz radio is the feature that can justify the price. In an AiMesh deployment, one 6GHz band can carry wireless backhaul while the other serves clients. In a dense single-router deployment, the extra radio can divide high-end clients instead of placing them all on one 6GHz channel set.

Most homes will never turn that capability into a visible result. A single laptop cannot consume four bands. A gigabit internet plan cannot saturate the wired uplink. If the second 6GHz radio has no backhaul or client-density job, the $629.99 price is a $400 premium for idle capacity.

Buy it for a named topology: dual-6GHz AiMesh, multiple current Wi-Fi 7 clients, 10G core networking, or a flagship gaming network where cost is secondary. The GT-BE98 Pro is the strongest wireless platform here. It is not the default.

Check NeweggLink checked 2026-08-18

Why 6GHz changes the ranking

Wi-Fi 7 features are not one indivisible package. MLO and 4K-QAM can operate without 6GHz. The headline 320MHz channels cannot; in the United States they live in the 6GHz band.

That creates three product classes:

Class	What it gives you	What it misses
Dual-band Wi-Fi 7	MLO/4K-QAM on 2.4 and 5GHz, often strong wired I/O	6GHz and 320MHz channels
Tri-band Wi-Fi 7	The full mainstream feature set: 2.4, 5, 6GHz	A dedicated second 6GHz backhaul/client radio
Quad-band dual-6GHz	Extra capacity or dedicated 6GHz mesh backhaul	Value, unless the topology uses it

This is why TP-Link wins and ASUS RT-BE88U stays a specialist. The Archer delivers the feature most buyers mean when they say “upgrade to Wi-Fi 7.” The RT-BE88U delivers a different thing: a serious wired edge with a current-generation 5GHz radio.

Port topology beats a 30Gbps box number

Router marketing adds every radio’s theoretical maximum and prints the sum. That number is access-point capacity under ideal conditions. It is not a laptop speed test.

Read the physical ports instead:

Archer BE550 Pro: cleanest 10G-WAN-to-2.5G-LAN layout.
RT-BE88U: best wired density and the only SFP+ option here.
GT-BE98 Pro: two 10G-class paths plus three 2.5G LAN ports.

For a NAS and workstation, map the whole chain. A 10G router feeding a gigabit switch is still a gigabit network. A Wi-Fi 7 access point wired back through 1GbE is still limited to one gigabit of backhaul. The 2.5GbE versus 10GbE guide explains when the next wired tier pays off.

Standalone router or mesh?

These picks are standalone routers. That is deliberate. A mesh comparison needs node count and backhaul radio first; after that come wired backhaul speed, placement, and total-kit price. Mixing a three-pack Orbi or Deco kit into this table would create the appearance of choice while comparing different products.

Choose standalone when:

the router can sit near the center of the usable space
one access point already covers the home
Ethernet can feed a separate access point later

Choose mesh when:

floors, dense walls, or distance create repeatable dead zones
one central location cannot cover the house
you can wire at least the main satellite with 2.5GbE or faster

A larger antenna count does not repair a bad access-point location. Spend on topology before flagship hardware. Picture a two-story house with 5Gbps fiber, one wired office, a 10GbE NAS in the basement, and two Wi-Fi 7 laptops upstairs: the Archer serves the wireless upgrade and four 2.5G rooms cleanly; the RT-BE88U earns its premium only if its SFP+ and extra wired ports replace a switch; the GT-BE98 Pro earns its premium only if a second 6GHz radio carries mesh backhaul or a dense client group. The exercise also exposes the mesh question before checkout: if the upstairs devices remain weak because the access point is badly placed, buy a second wired access point or a mesh node rather than paying for a larger standalone router and hoping one box defeats the floor plan.

Do not upgrade to solve a fault

A router that disconnects clients, reboots, or loses WAN under load may need replacement. It may also have a channel, firmware, heat, power, or ISP problem. Work through Wi-Fi that keeps disconnecting before using a new wireless generation as a repair strategy.

The same rule applies to speed. Test a wired client first. If Ethernet is slow, the radio is innocent.

The 60-second checkout audit

Match the exact model and item number.
Count the bands. Look for 6GHz explicitly.
Confirm the WAN port speed and whether it can become LAN.
Count 10G, 2.5G, and 1G LAN ports separately.
Check whether your clients support Wi-Fi 7 and 6GHz.
Decide standalone versus mesh before ordering.
Confirm seller, warranty, return window, and regional version.
Screenshot the final price and configuration.

For most buyers, the answer remains the Archer BE550 Pro. It buys the radio that makes Wi-Fi 7 different and the ports that keep it from being trapped behind gigabit.

RTX 5090 vs RTX 5080 (2026): Which One Should You Buy?

LK Wood IV — Tue, 18 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-18 · 15 min read · St. Louis County, MO

The decision in one table

The RTX 5090 wins every absolute-performance question. The RTX 5080 wins the purchase question for most gamers. The exception is a buyer whose current game, render, model, or paid workflow already reaches the 16GB boundary or whose display can turn the 5090’s extra native-4K frame rate into something visible; in that case, the larger card solves a named limit rather than serving as expensive insurance.

Decision	RTX 5080	RTX 5090	Winner
4K gaming with DLSS	Strong, measured and playable	Faster	RTX 5080 value
Maximum native 4K	Compromises remain in the hardest titles	Fastest tier	RTX 5090
VRAM	16GB GDDR7	32GB GDDR7	RTX 5090
Card power	360W reference TGP	575W reference TGP	RTX 5080
Required system power	850W	1000W	RTX 5080
Local AI that fits inside 16GB	Already capable	Faster/roomier, but unmeasured here	RTX 5080 value
Workloads that exceed 16GB	Spill or fail	32GB headroom	RTX 5090
Most gaming builds	Rational ceiling	Halo purchase	RTX 5080

Current direct-retailer example

Launch MSRP is useful history. It is not the number buyers face today.

Exact card	What the listing disclosed	Live price, Aug. 18
GIGABYTE WINDFORCE RTX 5080 16GB	304mm long, 2.5 slots, 850W recommended PSU	$1,399.99
ASUS ROG Astral RTX 5090 32GB	14.1 inches, 3.8 slots, 1000W recommended PSU	$4,829.99

Both pages showed sold and shipped by Newegg at capture. The 5090 example cost 3.45 times as much. This is not an apples-to-apples cooler comparison: ROG Astral is a premium flagship board, while WINDFORCE is a simpler RTX 5080. It is still a real checkout comparison, and it shows why MSRP-only advice fails.

Specifications that matter

Specification	RTX 5080	RTX 5090	Difference
CUDA cores	10,752	21,760	+11,008
VRAM	16GB GDDR7	32GB GDDR7	2× capacity
Memory interface	256-bit	512-bit	2× width
Total graphics power	360W	575W	+215W
Required system power	850W	1000W	+150W

The core count is not a frame-rate equation. Games do not scale one-for-one with CUDA cores, and CPU limits, memory behavior, ray tracing, and engine design change the gap. The capacity and power differences are literal. They shape what fits in VRAM, which supply belongs in the system, and how much heat the case must move.

How much faster is the RTX 5090?

Two credible suites answer this in different shapes.

GamersNexus measured the RTX 5090 30% to 68.9% ahead of the RTX 5080 at 4K, depending on the game, with results commonly in the 45% to 55% range. That wide spread is the honest result. A single title can land near 30%. Another can approach 70%.

TechPowerUp’s combined 3840×2160 raster chart put the RTX 5090 at 152% of the RTX 5080’s performance, a 52% suite-level lead. That aligns with the middle of the GamersNexus range while using a different game list and aggregation method.

The safe buying number is therefore not “the 5090 is always 50% faster.” It is:

expect a large 4K lead
expect the exact lead to move by title
do not pay for the maximum result unless your own games resemble the workloads that produce it

At 1440p, CPU limits shrink the value of the larger GPU. If the display is 1440p, the RTX 5090 is usually an expensive way to wait on the processor.

What the RTX 5080 already does at 4K

TechFuelHQ owns and measures an ASUS ROG Astral RTX 5080 OC. The open bench dataset publishes raw values with the method and correction history under CC BY 4.0.

Measured 4K results include:

Workload	Average FPS	1% low
Cyberpunk 2077 Ultra raster	58	49
Cyberpunk RT Ultra, DLSS Quality	50	41
Cyberpunk Path Tracing, native	19	15
Alan Wake 2 RT, DLSS Quality	49	38
Black Myth Wukong Cinematic	34	27

The card needs help in the hardest path-traced workload. That is where DLSS 4 changes the buying decision. On the same system, Cyberpunk 4K path tracing measured:

Mode	Output FPS	PC latency
Native path tracing	19	95ms
DLSS Quality, no frame generation	40	45ms
DLSS Quality + MFG 2×	90	55ms
DLSS Quality + MFG 4×	135	62ms

If those techniques are acceptable, the RTX 5080 is already a serious 4K card. The RTX 5090 buys more native headroom and a higher starting frame rate. It does not make the RTX 5080 incapable.

The 16GB versus 32GB decision

For gaming, 16GB is the practical high-end capacity today. The first-party 4K runs above fit and complete on the RTX 5080. Buying 32GB solely because a future game might need it is weak evidence.

For work, capacity can become binary. A render scene, local model, image batch, or timeline either fits in VRAM or it does not. Once the workload crosses 16GB, the RTX 5090’s performance advantage is no longer just frames per second. It can keep work on the GPU that the 5080 must spill, reduce, or refuse.

Name the workload before paying:

What is the current peak VRAM allocation?
Does lowering batch size destroy throughput?
Does CPU/RAM offload create an unacceptable delay?
Does the extra GPU memory replace a second card, cloud bill, or work interruption?

If there is no measured 16GB problem, the 32GB answer is insurance at flagship pricing.

Local AI: use measured data, not parameter-count folklore

The RTX 5080 local LLM throughput dataset is measured on the same retail card and mirrored on Kaggle and Hugging Face. It shows what 16GB can already do:

gpt-oss:20b MXFP4: 187–190 decode tokens/second
resident VRAM: roughly 13.7–14.0 GiB
Qwen 2.5 14B Q4_K_M: 94–97 tok/s
Qwen 2.5 7B Q4_K_M: 177–180 tok/s

This site has no first-party RTX 5090 AI result, so I will not invent a speed multiplier. The grounded claim is capacity: 32GB gives room for larger fully resident models, longer contexts, image work, plus larger batches. The grounded counterclaim is equally important: 16GB is already enough for fast interactive use on several useful models.

Buy the 5090 for AI when a workload you run now exceeds the 5080’s capacity. Buy the 5080 when your actual models fit.

Power, case, and the rest of the system

The RTX 5090 adds 215W of reference board power. That changes more than the electric bill.

NVIDIA specifies 850W required system power for the RTX 5080 and 1000W for the RTX 5090. TechFuelHQ’s full RTX 50-series PSU guide treats 1200W as the practical high-end 5090 target once a powerful processor and factory-overclocked board enter the build.

Physical size follows the same pattern in the live examples:

GIGABYTE WINDFORCE RTX 5080: 304mm, 2.5 slots
ASUS ROG Astral RTX 5090: 14.1 inches, 3.8 slots

That can determine case choice, front-radiator clearance, lower-slot access, GPU support, and cable bend radius. The GPU price is only the first system cost.

Price-to-performance without fake precision

Using TechPowerUp’s 52% combined 4K raster lead and the two live listings above:

performance multiplier: about 1.52×
price multiplier: about 3.45×

That does not produce a universal “value score.” The cards are different AIB tiers, and the RTX 5090 also buys double the VRAM. It does show the shape of the purchase: live retail asks for far more money than the gaming-performance increase alone returns.

The RTX 5090 can still be the cheaper business tool when its 32GB capacity replaces cloud GPU time, cuts a render queue, or prevents an out-of-memory failure. Put a number on that benefit before paying: if the larger card saves four billable hours each week, avoids a recurring cloud instance, and keeps a current scene fully resident, the purchase has three measurable payback paths; if it only raises a benchmark score, gaming receives none of that accounting benefit.

Buy the RTX 5080 if

the system is primarily for gaming
DLSS Quality and frame generation are acceptable at 4K
current workloads fit inside 16GB
you want an 850W-class build with easier case fit
the 5090 price premium would delay the monitor, storage, or next upgrade

Buy the RTX 5090 if

maximum native or lightly upscaled 4K performance is the requirement
32GB solves a measured memory-capacity problem
rendering, AI, or creation time has direct financial value
the larger PSU, case, cooling, and card price are already budgeted
money-no-object performance is itself the goal

The first list describes most buyers. The second describes a smaller group with better reasons, and the difference should survive a simple counterfactual: if the paid workload, 32GB allocation, or native-4K display disappeared tomorrow, would the rest of the purchase still justify a card that costs several thousand dollars more and forces a larger power and cooling envelope?

Complete system or card?

If you want the GPU inside a ready-to-run tower, compare the best RTX 5080 prebuilts and best RTX 5090 prebuilts. Those guides rank power delivery and memory layout, then check storage, seller, and warranty details that disappear when a listing talks only about the GPU.

For the card alone, confirm the exact item and dimensions, then verify the recommended supply, seller, warranty, and return terms. A GPU family name is not the product in your cart.

Monitor Flickering? Use Task Manager to Find the Cause

LK Wood IV — Mon, 17 Aug 2026 00:00:00 -0500

By LK Wood IV · Published August 17, 2026 · St. Louis, Missouri

A flickering monitor is not one fault. It can be Windows repainting the desktop through a bad driver, one incompatible app flashing while the rest of the display is stable, a video cable losing the signal, an unstable power source, or variable refresh rate making dark scenes pulse.

That is why the usual list of ten random fixes wastes time. The order matters. I start with Task Manager, because Microsoft’s own procedure gives the cleanest Windows-side split: if Task Manager flickers with everything else, the display driver is the likely cause; if Task Manager stays stable while the rest flickers, an app is the likely cause.

First, name the symptom. A brief loss of the entire picture is a blackout, so use the monitor-keeps-going-black guide. A fixed vertical or horizontal band belongs in the lines-on-monitor guide. A trail behind motion is monitor ghosting. This page is for the image or brightness visibly pulsing while the picture remains on-screen.

Do not mix them.

The 30-second split

Wait until the flicker is visible, then press Ctrl + Shift + Esc to open Task Manager.

What flickers?	Start here	What it rules toward
Task Manager and the rest of Windows	Display driver	Update, roll back, or reinstall the driver
Everything except Task Manager	One incompatible app	Update or uninstall the app that triggers it
The monitor’s own menu or no-signal box	Monitor or power source	Cable-independent panel, board, or outlet problem
Only a dark game or loading screen with VRR on	G-Sync / FreeSync / Adaptive Sync	Frame-time and VRR-range tuning
Only at a high refresh rate or resolution	Cable, port, adapter, or bandwidth	Test a lower rate and a known-good connection

Microsoft’s screen-flickering procedure is explicit. Task Manager flickering with the screen points to the display driver. A stable Task Manager points to an incompatible app. That isolates the Windows side. The monitor still needs its own test.

One test creates two branches.

Open the monitor’s on-screen menu with its physical button or joystick while the flicker is happening. That menu is drawn by the monitor, not by Windows.

The menu is stable: Samsung’s diagnostic boundary points away from monitor service. Keep working the PC, cable, port, and refresh-rate steps below.
The menu flickers too: disconnect the video cable so the monitor shows its own no-signal message. If that also flickers, the PC is no longer involved. Test the monitor’s power source, then the monitor itself.

Samsung uses the same boundary in its monitor flicker troubleshooting. A clean menu or error message means the monitor does not need service; the connected device or cable is causing the issue. Flicker across those internal elements keeps the monitor side under suspicion.

Step 1: Reset the graphics driver

Press Windows key + Ctrl + Shift + B.

Windows briefly blanks or redraws the screen while it resets the graphics driver. Microsoft says the shortcut may fix the issue. A stable picture afterward is useful evidence for the Windows display path, but it is not proof that the monitor panel is healthy.

Do not treat the shortcut as a permanent repair. It restarts the driver; it does not fix why the driver became unstable.

If the flicker returns:

Open Device Manager.
Expand Display adapters.
If the problem started immediately after a driver update, open the adapter’s Properties → Driver tab and use Roll Back Driver when available.
If the driver is old, update it from NVIDIA, AMD, Intel, or the laptop manufacturer.
If updates and rollback both fail, uninstall the display adapter and let Windows reinstall it, or use the clean-install sequence in the GPU driver crash guide.

The timing decides whether update or rollback comes first. A driver that started flickering right after an update is not fixed by installing the same update again.

Step 2: If Task Manager is stable, find the app

When Task Manager stays solid while another window or the rest of the desktop flickers, Microsoft points at an incompatible app.

Do not reinstall the whole graphics stack yet. Find the smallest repeatable trigger:

Does it begin only when a browser opens?
Only when Discord, Steam, an overlay, capture software, or a remote-desktop app is visible?
Only while resizing a specific window?
Does closing that app stop the flicker immediately?

Update the app first. If it is already current, uninstall it, restart, and test before reinstalling. That gives you an actual control: same display driver, same monitor, app absent.

Older or incompatible Windows programs can show flickering windows even when the desktop is otherwise healthy. If one program is the trigger, changing the monitor cable will not repair it.

Step 3: Work the connection and power path

Samsung’s current monitor guidance puts the practical hardware-side suspects together: a loose or damaged cable, faulty power, high-current appliances on the same circuit, outdated drivers, and the computer’s refresh-rate setting.

Work these in order:

Reseat both ends of the video cable. Check for a crushed section, sharp bend, loose latch, or damaged connector.
Bypass the extras. Remove the dock, KVM, splitter, capture device, and adapter. Connect the PC directly to the monitor.
Try another port. Move to another output on the graphics card and another input on the monitor.
Try a known-good cable. Match its certification to the mode you run. The DisplayPort and HDMI bandwidth calculator shows whether the resolution, refresh rate, color depth, and chroma fit the connection.
Test another outlet. Plug the monitor directly into a different circuit as a control. Keep space heaters and other high-current loads off the same circuit during the test.

A new cable is evidence only if changing the cable changes the symptom. Buying three cables before running the Task Manager and monitor-menu tests is parts-cannon troubleshooting in a different form.

Change one thing only.

The trap is treating every flicker as a cable fault because the cable is visible and easy to replace, when a stable monitor menu, a Task Manager window that flickers with the desktop, and a symptom that began immediately after a driver update together make a far stronger case for the Windows display path than for the wire on your desk.

Step 4: Test the refresh rate

Open Settings → System → Display → Advanced display and confirm Windows is using a refresh rate the monitor supports.

As a diagnostic, temporarily drop from 144, 165, or 240 Hz to 60 Hz:

Flicker stops at 60 Hz: the original display mode is exposing a signal-path or monitor-timing problem. Test the cable, ports, adapters, and native mode separately before naming the failed part.
Flicker is unchanged: the refresh-rate ceiling was not the cause; return to the driver/app or monitor/power branch.

Do not leave a high-refresh monitor at 60 Hz. This is a short diagnostic control. Find the weak link, then restore the native rate with the correct cable and port.

Step 5: Only flickers in games? Test VRR

If the desktop is stable and the screen pulses in dark game scenes, loading screens, or menus, test G-Sync, FreeSync, or Adaptive Sync before replacing anything.

Variable refresh rate makes the monitor follow the GPU’s frame output. When frame times jump, the refresh rate jumps with them. KTC’s VRR flicker explanation describes the repeatable pattern: unstable frame rates force rapid refresh-rate changes, with the effect most visible in dark scenes or near the monitor’s VRR floor.

Run one controlled comparison:

Reproduce the flicker in the same scene.
Turn G-Sync, FreeSync, or Adaptive Sync off.
Replay the scene without changing anything else.

Use the exact same scene.

If the flicker disappears, the panel is not necessarily dying. Turn VRR back on and cap the frame rate to a level your PC can hold steadily. Also update the GPU driver and monitor firmware. The goal is steadier frame pacing, not a higher peak number.

Samsung also recommends disabling G-Sync or FreeSync as a flicker test on supported displays.

Step 6: When the monitor itself becomes the likely fault

Only then does the monitor side move to the top.

Suspect the display or its power board when:

its own on-screen menu flickers;
its no-signal message flickers with the video cable disconnected;
the same behavior survives a different cable, input, and source device;
a different wall outlet and power cord change nothing;
the flicker appears before Windows loads;
the panel brightness pulses even while displaying a static internal menu.

At that point, stop reinstalling drivers. If the monitor is under warranty, record a short video showing the flicker across the on-screen menu and request service. That evidence proves the symptom exists independently of the PC.

The fix order

Separate flicker from a full blackout, fixed line, or motion trail.
Open Task Manager: driver branch if it flickers, app branch if it does not.
Open the monitor menu: stable means upstream; flickering means monitor or power.
Reset the driver with Windows key + Ctrl + Shift + B.
Reseat and simplify the signal path: no dock, KVM, splitter, or adapter.
Test another cable, port, and outlet.
Drop the refresh rate temporarily to isolate bandwidth or timing.
For game-only flicker, toggle VRR and compare the same scene.
Request monitor service only after its own menu or no-signal image flickers.

That order stays reversible. More importantly, it gives each change a control. Prove which layer is unstable before replacing the layer below it.

Sources

Microsoft Support — Troubleshoot screen flickering in Windows — Task Manager split, graphics-driver reset, driver rollback/update/uninstall, and incompatible-app branch.
Samsung Support — Image is distorted, ghosted, or flickering on my Samsung monitor — cable, power-source, refresh-rate, driver, G-Sync/FreeSync, and monitor-menu controls.
KTC — What causes monitor flicker with VRR or Adaptive Sync — frame-time swings, rapid refresh-rate changes, dark-scene visibility, and the VRR-floor pattern.

Adding a User to the Docker Group Is Not a Convenience Setting (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~8 min read · St. Louis County, MO

Here is the command you came for:

sudo groupadd docker # only if the group does not exist yet
sudo usermod -aG docker $USER
# then log out and log back in

And here is the sentence that belongs next to it, which Docker puts in a Warning box on its own post-installation page and almost nobody repeats:

The docker group grants root-level privileges to the user.

Not “elevated access to Docker”. Root on the host.

Why it is root, concretely

The reason sudo is needed in the first place is architectural. Docker’s docs put it plainly: the daemon binds a Unix socket rather than a TCP port, that socket is owned by root, and the daemon itself always runs as root. Joining the docker group does not reduce what the daemon can do. It gives you write access to the socket that commands it.

The socket is the entire access-control model. Moby’s own systemd unit ships it as SocketUser=root, SocketGroup=docker, SocketMode=0660. There is no per-user authorization layer behind it. Anything that can write to that socket can ask the root daemon for anything.

So the escalation is not clever:

docker run --mount type=bind,src=/,dst=/host -it alpine sh

You are now root inside a container with the host’s entire filesystem at /host. Docker’s security page states it directly — the container can alter your host filesystem without any restriction. Edit /host/etc/shadow, drop a key in /host/root/.ssh/authorized_keys, whatever you like.

Notice what is absent. No --privileged. No sudo prompt. No password. No entry in the sudo log.

That last one is the part I find most under-discussed. sudo leaves a trail. Group membership does not.

Because Docker’s own docs frame it as convenience first. The section opens with the reasoning that if you don’t want to preface the docker command with sudo, you create a Unix group called docker and add users to it. The Warning box sits underneath that.

Read in order, the page teaches convenience and then qualifies it. Skimmed — which is how anyone with a broken build reads a post-install page — you get the command and miss the box. Docker clearly knows this happens, because they had to add a second and more explicit warning on the Windows side, where docker-users membership is described as equivalent to granting administrative privileges on the host. OWASP made not exposing the daemon socket rule number one of its Docker cheat sheet.

The warning exists. It is just positioned to lose.

Why the change does not take effect immediately

You run usermod, you run docker ps, and you still get permission denied. Nothing is broken.

Supplementary group IDs are a credential attached to a process when it is created. Your shell was created before you joined the group, so it does not carry the membership, and re-reading /etc/group is not something a running process does. The shell will never pick it up. Neither will your desktop session, or the terminal you opened an hour ago.

Docker’s instruction is to log out and log back in so that group membership is re-evaluated, and they note a Linux VM may need a full restart.

To test without logging out:

newgrp docker
docker run hello-world

newgrp starts a subshell that carries the group. It is a session-level patch. Close that shell and you are back where you started, so do not mistake it for the change having applied globally.

The config.json warning nobody explains

If you used sudo docker before joining the group, you will eventually see this:

WARNING: Error loading config file: /home/user/.docker/config.json - stat
/home/user/.docker/config.json: permission denied

Root created that directory in your home. Docker documents the fix:

sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
sudo chmod g+rwx "$HOME/.docker" -R

Cosmetic, not dangerous. It will nag until you clear it.

What to do instead, honestly

I am not going to tell you never to join the docker group. Plenty of people should. The point is to do it knowing what it is.

Rootless mode is the real fix, because it removes the root daemon rather than gating access to one. It has genuine limitations and I have not run it long enough under a homelab workload to tell you which of those bite in practice, so I will not pretend otherwise.

sudo docker keeps every invocation authenticated and logged. It is mildly annoying and it is the correct default on a machine that is not yours alone.

Join the group deliberately on a box where root-equivalent access is already a thing you accept. On a dedicated homelab Docker host that you administer alone and could rebuild in an afternoon, the trade is reasonable and I would make it.

What I would not do is join the group on a shared machine, a work laptop, or anything with credentials on it you would not want a container to read, and then tell myself it was a permissions tweak.

The same reasoning governs anything you point at that socket. A Dockge or Portainer container with the socket mounted is not a dashboard; it is that same root-equivalent access with a web login in front of it.

The Docker Desktop exception

This is the one place the warning genuinely does not carry over. On Docker Desktop the daemon and your containers run inside a Linux VM, and Docker documents that VM as the security boundary. Container root is not host root in the way it is on a native Linux install.

Do not port the Linux Engine threat model onto Desktop unexamined. Do not port Desktop’s comfort back onto a Linux server either — on Windows, docker-users carries its own warning, in Docker’s words equivalent to granting administrative privileges on the host.

What I have not tested

I have not run rootless mode as a daily driver, so I cannot tell you where its limitations actually hurt versus where they are theoretical.

I have not audited whether any mainstream distro ships auditd rules that would record socket writes by group members. My claim above is that sudo logs and group membership does not, which follows from how each works, but I have not sat down and confirmed what a default install captures.

What getting this wrong costs

On your own homelab box, usually nothing. That is exactly why the habit spreads.

The bill arrives somewhere else. It arrives when the same muscle memory runs usermod -aG docker on a shared build server, and the service account that now has passwordless unlogged root is the one whose CI token leaks six months later. Nobody has to attack Docker. The group was the grant.

Run the command if it suits your machine. Just do not believe it only saves you four keystrokes.

Docker Cleanup: Which Prune Command Eats Your Data (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~8 min read · St. Louis County, MO

The received wisdom is simple. docker system prune -a --volumes eats databases, so never run it.

That fear is aimed at the wrong command. Docker’s own options table describes --volumes as “Prune anonymous volumes”, and the confirmation prompt spells out what it will remove: all anonymous volumes not used by at least one container. A named volume is not anonymous. If your Postgres data lives in a volume you named in a compose file, docker system prune -a --volumes is not the thing that will take it.

The command that removes named volumes is this one.

docker volume prune --all

Docker documents that by default docker volume prune only removes anonymous volumes, and that --all removes all unused volumes, not just anonymous ones, behind an API 1.42 gate. Read those two sentences next to each other and the asymmetry is obvious: the destructive option is a four-character flag on a command whose name sounds like it only touches leftovers.

So the scary-sounding command is narrower than its reputation. The mild-sounding one is the loaded gun. That inversion — feared command safe, safe-sounding command dangerous — is the whole reason this page exists.

One honest caveat before you act on any of it. Everything above is read from Docker’s current documentation, not from a test I ran on this machine. I have no Docker daemon here, and I would rather say so than imply a bench I did not use. There is a two-minute scratch test at the end. Run it first. Trust it over me.

Look before you sweep

docker system df

That breaks usage into images, containers, local volumes and build cache, with a reclaimable column. Run it first. Every time.

I push this because “reclaim disk space” is usually the wrong framing, and running a prune before you have looked at docker system df is how people end up re-pulling forty gigabytes of images to solve a problem that was one container writing an unbounded log file the whole time. The question is what filled the disk, and the answer changes the fix entirely. Build cache on a machine that builds often is a different problem from forty pulled images you never run, which is different again from one container writing an unbounded log. Only one of those is solved by pruning.

What each command removes

docker system prune, per its confirmation prompt, removes exactly four things:

all stopped containers
all networks not used by at least one container
all dangling images
unused build cache

No volumes at all. A dangling image — one that no tag points at any more — is typically what is left after rebuilding under the same tag.

docker system prune -a adds, per the options table: Remove all unused images not just dangling ones.

This is a much wider sweep than it reads. “Unused” means no container is associated with the image, tagged or not. On a homelab where you keep images around for things you run occasionally, -a removes them and you will pull them again over your home connection at the least convenient moment. It is safe for your data. It is expensive for your time.

docker system prune --volumes adds anonymous volumes, as covered above.

docker volume prune takes anonymous volumes only, by default.

docker volume prune --all is the one to watch. Unused named volumes go too.

docker builder prune takes build cache only. It is the safest command here, because build cache is reproducible by definition. On a machine that builds regularly it is also often the entire problem.

The trap that is genuinely real

Here is the case where you can genuinely lose data to anonymous-volume pruning. It is not the one people worry about.

Some official images declare a VOLUME in their Dockerfile. Postgres declares one at its data directory. When you start such an image without giving it a named volume or a bind mount, Docker satisfies that declaration by creating an anonymous volume. It has a long hex name you never chose. It holds your actual database.

# creates an anonymous volume holding real data
docker run -d postgres:17

# creates a named volume you control
docker run -d -v pgdata:/var/lib/postgresql/data postgres:17

Stop that first container and the anonymous volume is now unused, and squarely in scope for --volumes.

So the failure mode is not “prune ate my named volume”. It is “I never named the volume, so Docker quietly named it for me, that autogenerated name made it anonymous by definition, and anonymous is precisely the category the flag I ran was documented to remove”. The fix is upstream of any prune command: name your volumes. A compose file with a top-level volumes: block gets this right by default, which is one more reason to run things through compose rather than long docker run lines.

What I run weekly

Weekly, on a homelab Docker host, with the reasoning attached:

docker system df # look first
docker builder prune # cache is reproducible
docker system prune # stopped containers, unused networks, dangling images

That reclaims most of what accumulates. It touches nothing you cannot rebuild.

I add -a only when I have decided I am willing to re-pull, which on a metered or slow connection is a real cost rather than a theoretical one.

I never run docker volume prune --all on a schedule. A volume is the one thing here that might be the only copy. When I want a specific volume gone, I look at it first and then remove it by name, which is slower in exactly the way that a command capable of destroying the only copy of something ought to be:

docker volume ls
docker volume inspect <name>
docker volume rm <name>

Slower. It also makes me say what I mean.

The scratch test, so you do not have to take my word for it

Two minutes, on a machine where losing the test volumes costs nothing.

docker volume create keepme
docker run -d --name anon-test postgres:17 # anonymous volume
docker run -d --name named-test -v keepme:/data alpine sleep 60
docker rm -f anon-test named-test

docker volume ls # note what exists
docker system prune -a --volumes # the feared command
docker volume ls # keepme should still be here

If keepme survives and the hex-named one does not, the documented behaviour holds on your version. If it does not survive, I want to know — that would mean the docs and your daemon disagree, which is a much more interesting problem than a tidy disk.

What I have not tested

I have not run any of this on a live daemon during this write-up, for the reason given at the top. Every behavioural claim here traces to Docker’s current CLI documentation.

I have not checked how an older daemon behaves, and this is the gap I would most want closed before anyone runs these commands on a long-lived box that has not been updated in a couple of years. --all on docker volume prune carries an API 1.42 gate, which implies the pre-1.42 behaviour differed, and I have not established what a new CLI does against an old daemon. If you are on something long-lived and unpatched, test rather than assume.

I have not measured how much any of this reclaims in practice. That number is a property of your machine, and quoting mine would tell you nothing.

What getting it wrong costs

Pruning images costs you a download. Pruning build cache costs one slow build. Both are annoyances with a known price.

Pruning a volume costs you whatever was in it, and the price is only discovered later, usually when something tries to read data that is no longer there and fails in a way that does not obviously say “your volume is gone”. If that data mattered, the real lesson is not about prune flags at all. It is that a volume you would miss should be backed up, because a wrong flag is only one of many ways to lose it.

Docker Compose Environment Variables: .env Is Not env_file (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~9 min read · St. Louis County, MO

Put a .env file next to your compose.yaml, fill it with variables, start the stack, and exec into the container to check.

They are not there.

This is the single most common Compose confusion. It is also not carelessness.

The two mechanisms have similar names, similar syntax, and point in opposite directions.

.env fills ${VAR} placeholders in the compose file itself. By itself it puts nothing in a container.
env_file: passes variables into the container, and is not consulted when Compose interpolates the compose file.

Docker says the first half plainly. Their precedence page notes that the Host OS environment and .env file columns are listed only for illustration purposes, and that in reality they do not result in a variable in the container by itself.

Read that twice. It is the whole article.

The two directions, side by side

# .env (interpolation source)
POSTGRES_VERSION=17

# compose.yaml
services:
 db:
 image: postgres:${POSTGRES_VERSION}  # .env fills THIS
 env_file:
 - db.env  # this goes INTO the container
 environment:
 - TZ=America/Chicago  # so does this

POSTGRES_VERSION never reaches the container.

TZ and everything in db.env do reach it, and neither of them can interpolate anything, which means the file you edited and the file you needed to edit are frequently different files.

The mirror-image mistake is just as common and harder to spot:

services:
 web:
 image: "webapp:${TAG}" # TAG will NOT come from env_file
 env_file:
 - .env

Listing .env under env_file: does not make its contents available for interpolation. It makes them available inside the container, which is a different thing that you did not ask for.

Precedence, in the order Docker documents

Highest to lowest, for what ends up in the container:

docker compose run -e on the CLI
environment or env_file with no value — passes through from your shell
the environment attribute
the env_file attribute
a Dockerfile ARG or ENV

Two entries in that list catch people.

environment beats env_file, even when it is empty. Docker’s wording is explicit that this holds true even if those values are empty or undefined. So a leftover FOO= under environment: silently overrides a correct FOO in your env file. Nothing warns you. The variable is simply empty, and you spend the next twenty minutes reading the env file, which is correct, because the problem is in the other file entirely.

A Dockerfile default is a fallback. The docs state that having any ARG or ENV setting in a Dockerfile evaluates only if there is no Compose entry for environment, env_file or run --env. You do not layer on top of it. You replace it entirely.

There is also a second, different precedence list in the docs covering interpolation: shell, then --env-file, then the project .env. Two lists. Two jobs. Reading one and applying it to the other is how people end up certain the docs contradict themselves.

The silent failures

This is what makes the topic worth a page rather than a paragraph.

Almost every way to get it wrong fails quietly.

Unset interpolated variables become empty strings, not errors.

image: "postgres:${POSTGRES_VERSION}"

With POSTGRES_VERSION unset, that resolves to postgres:, which the docs note is not a valid image reference.

Compose builds the string anyway and hands you the failure one layer down, where the error message talks about an image rather than about the variable that produced it, so the search you run next is the wrong search.

Bare passthrough does not warn; the explicit form does.

environment:
 - DEBUG  # unset? no warning, nothing passed
 - DEBUG=${DEBUG}  # unset? Compose warns

Both are legal. Only the second tells you when the shell had nothing to give. I use it for that reason alone.

A missing --env-file is a hard error. A missing .env is silent.

That asymmetry is deliberate. A path you named explicitly is a promise; the default is optional. It also means a stack that runs on your laptop can start on the server with a chunk of its configuration quietly absent, because .env was never committed and nobody noticed it was gone.

I check for that first now, whenever something runs locally and not on the host. It is nearly always this.

Secrets do not belong here

Anything you put in the container environment is readable with docker inspect. That means it is readable by anyone who can reach the Docker socket — and on a Linux host, that is anyone in the docker group, which is root-equivalent access anyway.

Compose supports file-based secrets that arrive at /run/secrets/<name> instead:

services:
 db:
 image: postgres:17
 environment:
 POSTGRES_PASSWORD_FILE: /run/secrets/db_password
 secrets:
 - db_password

secrets:
 db_password:
 file: ./db_password.txt

Note the pattern in that block. The environment variable holds a path. The secret itself never enters the environment. Many official images support a _FILE suffix on their password variables for exactly this, and where an image supports it, it is strictly better than pasting the value.

ARG deserves a specific warning too: build arguments are visible in the image history. An ARG carrying a token is published rather than private, and it stays published in every layer built from it.

What I do

A .env for things that shape the compose file: versions, ports, host paths.

An env_file per service for what the application reads.

environment for one or two values I want visible in the compose file itself, so that reading the file tells the truth about what the service gets rather than sending the reader off to a second file to find out.

The rule I hold to, after being bitten by the empty-override: never set the same variable in two places. Precedence rules exist so that Compose can resolve a conflict, not so that I can create one and rely on remembering the order at 1am.

What I have not tested

I have not verified the behaviour on old Compose v1. Everything here is from current Compose documentation, and v1 differed in enough places that I would not extend it there.

I have not tested how the newer top-level include: interacts with .env resolution across multiple compose files, which is the case I would most expect to hold a surprise.

What getting it wrong costs

Usually an hour. The hour has a distinctive shape: the configuration looks correct, the container disagrees, and nothing produces an error that points at either one.

Occasionally it costs more. environment silently overriding an env-file value with an empty string is a fine way to start a database with an empty password variable, and the failure mode there depends entirely on how forgiving the image is about it. Some are not forgiving at all, which is the good outcome.

Dockge Setup: The Compose Manager That Does Less On Purpose (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~7 min read · St. Louis County, MO

Dockge is a web UI over a folder of docker-compose.yaml files. That sentence is the entire product. I mean it as praise.

The install is one container. Five minutes, most of it waiting on a pull. The thing worth reading this page for is the volume line in the middle of that file, because getting it wrong is the one failure the project cared enough about to put a warning emoji beside in its own README, and because it fails quietly rather than loudly.

The compose file

services:
 dockge:
 image: louislam/dockge:1
 restart: unless-stopped
 ports:
 - 5001:5001
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - ./data:/app/data
 # Both sides of this MUST be the same path. See below.
 - /opt/stacks:/opt/stacks
 environment:
 - DOCKGE_STACKS_DIR=/opt/stacks
 - PUID=1000
 - PGID=1000

mkdir -p /opt/dockge /opt/stacks && cd /opt/dockge
# save the file above as compose.yaml
docker compose up -d

Then open port 5001 and create the admin account. Done.

Before you run that: the stable image is old

I nearly published this page without checking. That would have been a disservice, so here it is up front, ahead of the install advice rather than buried in a caveats section at the bottom where nobody reads it.

Dockge 1.5.0 was released on 30 March 2025. On Docker Hub the tags 1, latest and 1.5.0 all resolve to one digest, and all three were last pushed that same day. The 1 tag in the compose file above is therefore an image that has not been rebuilt in roughly sixteen months.

The project is not abandoned. Master took commits into April 2026, and there is a nightly tag rebuilt daily from it, which I confirmed had been pushed the day I wrote this. What has stalled is the release. The gap between the code and the artefact you actually pull is the part that matters, and it is the part a version number on a README will never show you.

Now weigh that against the socket mount in the next section. This is a container holding root-equivalent access to your host, running an image whose base layers have not been refreshed in over a year. Those two facts are worse together than either is alone.

I still think it is worth running. On a LAN-only host, behind a proxy, on a homelab you could rebuild in an afternoon. I would not put it on anything internet-facing, and I would not put it on a machine whose loss would ruin a week. You can pin nightly for the newer code. Then you are on unreviewed daily builds, which is a different risk, not a smaller one.

Check the dates yourself before installing. They may well have moved since I wrote this:

curl -s "https://hub.docker.com/v2/repositories/louislam/dockge/tags?page_size=10&ordering=last_updated" | python -c "import json,sys; [print(t['name'], t['last_updated'][:10]) for t in json.load(sys.stdin)['results']]"

The volume line

Look at the stacks mount again:

- /opt/stacks:/opt/stacks

Host path on the left, container path on the right. They are identical, and that is not stylistic. The README’s own examples are blunt about it — it marks /my-stacks:/my-stacks correct because both paths match, and /docker:/my-stacks wrong because they do not, with the warning that your data could end up written into a wrong path.

Here is why. “Just do it” is unsatisfying, and you will meet this shape again.

Dockge talks to the Docker daemon through the socket you mounted. When it asks the daemon to bring up a stack, the daemon resolves every path in that compose file on the host, not inside the Dockge container. So Dockge writes a compose file to what it believes is /opt/stacks/immich/compose.yaml, and the daemon goes looking for that same path on the host. If your bind was /docker:/opt/stacks, then Dockge’s /opt/stacks/immich is really /docker/immich on the host, and the two halves of the system now disagree about where your stacks live.

Make both sides identical and the disagreement cannot happen. It is the same class of problem as any socket-mounted tool that hands paths to the daemon, and the fix is always the same: agree with the host.

/opt/stacks is only a convention, and /srv/stacks:/srv/stacks would do just as well, because what the daemon cares about is that the two sides agree rather than what they agree on. Matching is the rule. The path is yours.

What it deliberately will not do

Dockge is compose-only. It will not manage standalone containers, networks, images, or the rest of the Docker surface Portainer covers.

I think that is the most interesting thing about it. It is also the part people get annoyed by, because they arrive expecting a Portainer swap and find something with a deliberately smaller footprint instead. If every workload you run is a compose stack — which, in a homelab, it usually is — then a tool that only does stacks has a much smaller surface to be confusing in. If you regularly poke at networks or one-off containers, Dockge will not cover that and you will keep a terminal open. Neither of those is a defect. They are just different jobs.

I compare it properly against the two obvious alternatives in Komodo vs Portainer vs Dockge, including the licensing change that pushed a lot of people to look in the first place.

Security, briefly, because the socket mount deserves it

That first volume line mounts the Docker socket into the container. Anything that can reach the Docker socket can start a container that mounts your host filesystem as root. That is not a partial privilege. It is root.

So the Dockge UI is not a dashboard. It is a root-equivalent control surface with a login form in front of it. Treat it that way:

Do not publish 5001 to the internet. Put it behind Nginx Proxy Manager with a real certificate, or reach it over a tunnel and leave it on the LAN entirely.
Give it a password you did not reuse.

If you already run Uptime Kuma, the same reasoning applies there and the same fix works for both.

PUID and PGID

The official file sets both to 1000, and its comment is worth repeating: both must be set for it to do anything. Setting one alone does nothing at all.

They decide who owns the stack files Dockge writes. Get them wrong and the symptom is undramatic — you SSH in later, try to edit a compose file by hand, and cannot, because it belongs to someone else. id -u and id -g give you the right numbers for your own user.

Adopting stacks you already have

Dockge reads a directory. There is no import step, and no separate database holding the real state, so a compose file you drop into the stacks directory is simply a stack it can see.

That property is the reason I find it easy to recommend trying. The compose files are the state. Nothing else is. If you decide against it in a month, you stop the container and your stacks are exactly where you left them, in plain files, unchanged. Tools that own their state are a commitment; this one is a visit.

What I have not tested

I have not run the agent/multi-host setup, so I cannot tell you how it behaves when a remote host goes away mid-deploy, which is the case I would want to know about before depending on it.

I have not measured its resource use, and I would rather say that than quote a figure I did not take.

I have also not run it against a stack large enough to make the UI struggle, so I do not know where that boundary sits.

What getting the volume wrong costs

Not much, if you catch it on day one. You notice the stacks are not where you expected, you fix the bind, you move on.

The expensive version is catching it in month four, after you have pointed a backup job at /opt/stacks on the host and it has been faithfully archiving an empty directory the whole time. The compose files were always at /docker. Nothing errored, because nothing was wrong from any single component’s point of view.

Check the two paths match. Before anything else.

Headscale: Self-Hosting the Tailscale Control Server (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~8 min read · St. Louis County, MO

Most people who look up Headscale want to run it on the machine already humming in their closet. That is the one deployment it does not do.

Headscale’s own requirements page asks for a server with a public IP address, recommends dual-stack IPv4 and IPv6, and serves over HTTPS on port 443 because the Tailscale client assumes that in certain situations. If your home connection sits behind CGNAT, you have no public IP to hand it. If it does have a real public IP, you can technically proceed, and you will have built a coordination server that depends on the same uplink as everything it coordinates.

So the shape of a Headscale deployment is fixed before you write any config: a small host somewhere else, with a public address and a name you can put a certificate on.

That is the practical answer. The more useful answer is the next section.

First, the case against doing this

Tailscale’s free Personal plan covers up to 6 users with unlimited user devices, 3 ACL groups, and access to nearly all features. It costs nothing and it is explicitly intended for homelabs and personal projects.

Read that against your actual situation. One person, a NAS, a Proxmox host, three VMs, a laptop and a phone? You are not close to a limit. There is no bill coming. Headscale would replace a working, maintained, zero-cost service with one you patch, back up, and get paged about.

I want to be blunt, because the search results for this topic are not: for the majority of homelabs, Headscale solves a problem you do not have. Running it is a hobby in its own right, and that is a completely legitimate reason to run it. It is not the same reason as necessity, and the two get blurred constantly.

Three situations where it genuinely earns the work:

You object to the metadata, not the cost. Tailscale’s coordination server knows your device names, your public keys, and who connects to what. The traffic is end-to-end encrypted and they cannot read it, but the graph is theirs. If that specific fact is what bothers you, Headscale is a direct answer and no amount of free tier fixes it.

Your structure does not fit the Personal plan. More than 6 users, or an ACL model that needs more than 3 groups, and you are looking at a paid tier. At that point the comparison is a real one.

You want the control plane to survive theirs. Existing tailnets keep passing traffic when the coordination server is unreachable, but new nodes and key rotations do not. If your tolerance for that is zero, owning the control plane is the only fix.

Everything else — “self-hosting is better,” “I want to own my stack” — is preference, and preference is fine. Just price it honestly against a free service that already works.

What it does support

The 2026 feature list is broad, which surprised me. Node registration by web auth and pre-auth keys, MagicDNS, split DNS and search domains, tags, subnet routers, exit nodes with route filtering, dual-stack, ephemeral nodes, embedded DERP and peer relays, ACLs and grants, autogroups, Tailscale SSH, OIDC single sign-on, Taildrop and Taildrive, Funnel and Serve, network flow logs.

The documented gap worth checking before you commit: OIDC groups cannot be used in ACLs. If your plan was to point Headscale at your identity provider and let group membership drive access policy, that specific path is closed. Verify it against your intended policy now rather than after you have migrated forty nodes.

Headscale is not a Tailscale product. It reimplements a protocol it does not control, which is the standing structural risk with anything in this category and is worth naming even though the project has tracked upstream well.

The host

A control server does very little work. It coordinates key exchange and hands out routes, then gets out of the way while nodes talk directly. SQLite is the assumed database in the setup requirements, so there is no separate database tier to size.

What it needs is not capacity. It is position:

A public IPv4 address. Dual-stack with IPv6 is recommended.
Port 443 reachable, with a valid certificate.
Uptime that is independent of the network it serves.

Any small VPS tier meets the first two. The third is the one people undercut by hosting it at home, and it is the whole reason the requirement exists.

There is one more reason not to put it on your home connection, and it is the sharpest: if Headscale is the thing that lets you reach your homelab remotely, and Headscale lives in your homelab, then you cannot fix your homelab remotely. You have built a mesh VPN whose failure mode is a locked door with the key inside. I would put the control server anywhere except the network it exists to let me into.

The domain

HTTPS on 443 means a certificate, and a certificate means a hostname. A subdomain on a domain you already own works fine — nothing about this needs a dedicated registration.

If you do not own one yet, this is the same purchase you would make for any public service, and it is worth doing before the install rather than during it. Certificate issuance is the step where a missing DNS record turns twenty minutes into an evening.

Where this sits against the alternatives

If you have not committed yet, the comparison is worth doing properly. I have written up Tailscale against plain WireGuard, which is the real decision for most people, and Tailscale against Cloudflare Tunnel for the case where you want to publish rather than connect. NetBird against Tailscale covers the other self-hostable mesh worth a look, and it is the one I would compare Headscale to most carefully, because it was designed to be self-hosted rather than adapted to it.

If you just want remote access to your homelab today and are not attached to owning the control plane, Tailscale on a homelab takes about ten minutes. If you want no third party in the path at all, WireGuard on Proxmox is the honest floor — more manual, no coordination server to run, no vendor.

What I have not tested

I have not run Headscale through a Tailscale client major-version bump, which is the failure mode I would most want data on before recommending it to someone whose remote access depends on it. The project tracks upstream well by reputation. Reputation is not a measurement.

I have not tested the OIDC integration, so I cannot tell you how painful the ACL group limitation is in practice, only that it is documented.

I have not run it at a scale where SQLite is the constraint.

What getting this wrong costs

The expensive version is not a failed install. It is a successful one, six months ago, on a box in the closet, which you have quietly come to depend on. Then the power blips while you are travelling, and the control server that would have let you back in is the thing that is down.

Put it somewhere else. That is most of the advice on this page.

Monitor Shadow Problem: Three Different Faults Wearing One Name (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~8 min read · St. Louis County, MO

Ten feet.

That is the run length where ViewSonic stops assuming your HDMI cable is fine — and it is the most useful number in this entire topic, because almost nobody staring at a shadowed screen has stopped to think about how long their cable actually is, how many boxes it passes through on the way, or whether the connector behind the monitor has been quietly oxidising in a warm room since 2019. They are thinking about whether the monitor is dying. It usually is not.

TL;DR · Find out which shadow you have

Drag a window across the screen and watch the shadow. Everything below depends on this one observation.
Holds a fixed offset and follows the window → signal path. Pull the dock, reseat the cable, get off VGA. Cheapest fix on the page.
Only appears while things move, gone when still → pixel response time. Different fault, different guide.
Faint copy of a taskbar or spreadsheet left up for hours → image persistence. Leave it alone and it goes.
Cuts through the monitor's own settings menu → the panel itself, and that menu is the referee.

Most guides on this topic make one mistake, and it is why people replace working monitors. They treat “shadow”, “ghosting” and “double image” as one problem with one list of fixes. Search the phrase and you get a single article covering cables and response time and burn-in in the same breath, as though the reader should simply work down the list until something helps. Those are three faults with nothing in common except the word people reach for when describing them.

The list approach costs you an evening and, often enough, a monitor.

The test that decides everything

Open any window and drag it slowly across the screen.

If the duplicate travels with the window and keeps the same offset, the image is being corrupted on its way to the panel. If the duplicate only exists during the drag and the screen is clean the moment you let go, the pixels are switching too slowly. If there is no duplicate at all, and what you are seeing is a faint ghost of yesterday’s spreadsheet sitting in one place regardless of what gets dragged over the top of it, then nothing is broken and you can stop worrying.

Three answers. Skip to yours.

The shadow that holds still: your signal path

This is the one worth real attention, because it accounts for most of the searches and it is almost always the cheapest thing in the chain.

A monitor draws what arrives at its input. It cannot do anything else. When the picture arrives degraded, the panel faithfully draws the degradation, and one of the recognisable ways a video signal degrades is as a displaced, lower-contrast copy of the real image. ViewSonic’s own support article on shadowing and double images is blunt about the mechanism: image artifacts are typically caused by signal degradation or interference. That is a panel manufacturer describing its own returns.

VGA sits at the top of the list

Let me be careful about how hard I lean on this.

I have never put a scope on a VGA line myself, and I am not going to pretend otherwise. What I can tell you is what the manufacturer says, and ViewSonic states plainly that low-quality VGA cables are the most common cause of shadowing, with the recommendation to use HDMI or DisplayPort instead.

The reasoning holds up. VGA carries the picture as an analogue waveform, so degradation along the way lands directly in what you see — no error correction, no fallback, just a slightly wrong voltage arriving at a panel that has no way of knowing it is wrong. A digital link fails differently. It either delivers a pixel correctly or breaks in ways that look nothing like a soft double image: sparkles, black flashes, a dropped signal, a refresh rate that silently falls back to 30Hz. If you are on VGA and both ends have a spare HDMI or DisplayPort, that swap is a five-minute test which costs nothing and settles the question outright. The catch is that plenty of people are running VGA without knowing it, because a VGA-to-HDMI adapter on a monitor’s input, or an old KVM with an analogue backbone, keeps the analogue segment sitting in the middle of the chain while the connector at your desk looks perfectly modern and the box on your shelf says nothing about what it does internally.

Check the back of the monitor before you rule this out.

Every box between the two ends is a suspect

ViewSonic’s first recommended step is to remove any docking stations or video splitters and connect the monitor directly to the PC to test the image quality. That ordering is right, and it is the step people skip, because unplugging a dock means unplugging everything.

Do it anyway. A dock, a splitter, a KVM and a USB-C hub are all re-driving or re-timing your video, and a cheap one does that badly. If the shadow disappears with the monitor plugged straight into the graphics card, you have found it. You also know what the fix costs, which is the part people want before they start. If you arrived here because a second display was misbehaving too, our guide on a second monitor that will not be detected covers the same hardware from the other direction.

Length, and the one certification that means something

Past about ten feet, cable quality stops being a rounding error. ViewSonic’s threshold is three metres, and the recommendation is a Premium Certified HDMI cable or a high-quality shielded one.

That certification is not marketing. Under the Premium HDMI Cable Certification Program, cables are tested to support the full 18Gbps bandwidth, including an EMI test to make sure they minimise interference with wireless signals, and — this is the part that matters for a long desk run — the program requires every length of every model line to be tested at an official HDMI Authorized Test Center, so a 25-foot cable cannot ride in on the results of its 3-foot sibling. Certified cables carry an anti-counterfeiting label with a QR code you can scan in the shop. That is a meaningfully different claim from “high speed” printed on a bag.

DisplayPort has an equivalent worth knowing. VESA’s DP8K certification confirms a cable handles HBR3 — the 8.1 Gbps-per-lane rate DisplayPort 1.4 tops out at — verified at an authorised test centre rather than asserted on the packaging. It also checks that pin 20 is not wired through on male-to-male cables. That one is a nastier failure than any shadow, since back-driven power can stop a machine booting.

Then the boring physical things

Reseat both ends. ViewSonic asks you to make sure the connectors are clean, with no oxidation, and are seated properly in the port, which sounds like filler right up until you remember what actually happens to a monitor cable behind a desk: it gets yanked when the desk moves, kinked against a wall, stood on by a chair caster, and left in a warm room for six or seven years while nobody once looks at the pins. Then someone buys a new monitor.

If none of that moves the needle, bring up the monitor’s own on-screen menu while the shadow is visible. That menu is drawn by the monitor’s internal board and never touches your cable, so a shadow cutting through the menu overlay puts the fault inside the display. I did not invent that test. It is the same referee our guide to lines on a monitor screen uses, and it works here for the same reason.

The shadow that only exists in motion

If the duplicate appears behind moving objects and the screen is clean when nothing moves, stop reading this page. You have ghosting, and this page will not help you. That is a pixel response-time problem inside the panel, and the fix is your monitor’s overdrive setting rather than anything in the cable chain. We wrote it up separately in how to fix monitor ghosting.

One thing is worth flagging, because it is the most common wasted purchase in this whole area. A new cable will do nothing for ghosting. Not one thing. The advice on the two faults points in opposite directions, which is exactly why bundling them into one article does readers harm.

The shadow that fades on its own

The third case is a faint copy of something that sat on screen for a long time. A taskbar. A spreadsheet grid. A dashboard someone left up over a weekend.

That is image persistence, and on an LCD it is temporary. Dell’s monitor guidance treats it as a condition that clears once the static content stops being shown, and recommends screen savers and varied content as the prevention. Leave the display on ordinary moving content, or switch it off, and it goes. How long that takes ranges from seconds to considerably longer depending on how long the static image sat there, so patience is genuinely part of the fix here.

Do not buy anything for this one.

OLED is the exception, and the distinction matters if you are running a TV as a desktop. There, prolonged static content can produce permanent wear rather than temporary retention. That is a different conversation. There is no home fix.

The case where the monitor is innocent

One search that lands people here has nothing to do with display hardware at all. Windows draws drop shadows under window borders, and a display-scaling change or a graphics-driver reset can render those shadows heavier, or leave them stranded behind inactive windows. If your “shadow” is a soft grey edge hugging window frames, no cable will touch it.

So take a screenshot. That settles it in about four seconds, because a real signal or panel fault never survives being captured to a file, while a compositor artifact is baked into the image and will look exactly the same on any other machine you open the file on.

What I have not tested

I have not reproduced any of these faults on a bench for this article, and the sourcing above reflects that: the signal-path claims are ViewSonic’s, the cable-certification specifics are HDMI Licensing’s and VESA’s, and the image-persistence behaviour is Dell’s. Where those sources agree with the physics I have said so, and where I am simply relaying a manufacturer’s claim I have tried to make that obvious.

I also cannot tell you how much of the shadowing people report in 2026 is still VGA. ViewSonic’s guidance does not carry a date I can check, and analogue connections have been disappearing from new hardware for a decade while surviving in offices, classrooms and KVM setups. The advice holds either way, since the diagnostic sequence does not depend on which cause turns out to be most common.

The next thing I would measure, if I put a monitor on the bench for this, is whether a failing HDMI run degrades gradually into visible shadowing or falls off a cliff into sparkle and signal loss with nothing in between. My expectation is the cliff, which would make a soft shadow on a short digital cable a much stronger indicator of a dock or adapter problem than of the cable itself.

Sources

ViewSonic Support, “Why is there shadow or double image on screen?” — signal degradation as cause, VGA as most common source, dock/splitter removal, three-metre cable threshold, connector oxidation.
HDMI Licensing Administrator, Premium HDMI Cable Certification Program — 18Gbps testing, EMI test, per-length testing at Authorized Test Centers, QR-code authentication label.
VESA, DP8K certified DisplayPort cables — HBR3 at 8.1 Gbps per lane, authorised test centre verification, pin 20 checking.
Dell, Guidelines for Dell Monitor Usage to Prevent Image Retention and Preserve Panel Life — image retention as a temporary LCD condition, prevention guidance.

Ollama in Docker with GPU: Stop Installing CUDA Inside WSL2 (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~9 min read · St. Louis County, MO

If you are on WSL2, the most common first move is the wrong one, and it feels like progress while you make it.

People open the distro, run apt install cuda or cuda-drivers, check nvcc --version, see a version string, and treat the prerequisite as handled.

NVIDIA’s own CUDA-on-WSL documentation warns against exactly this. More than once. One of those warnings is in capitals.

Here is why it is not merely unnecessary but harmful. Under WSL2 the Windows driver is projected into the distro as a libcuda.so stub. That stub is the GPU access path. The cuda, cuda-12-x and cuda-drivers meta-packages pull in a Linux NVIDIA driver, which installs over that stub and breaks the thing that was working.

You do not need a driver inside WSL. You already have one. It came from Windows.

The two toolkits people conflate

This is the root of it. The naming is genuinely unhelpful:

Package	What it does	Needed for Ollama in Docker?
CUDA Toolkit (`nvcc`, headers)	compiles CUDA applications	No
NVIDIA Container Toolkit (`nvidia-container-toolkit`)	lets Docker hand a GPU to a container	Yes

They share a brand. Nothing else. nvcc --version printing happily tells you precisely nothing about whether Docker can reach your GPU — I have watched that exact screenshot get posted as evidence in bug reports where the real failure was that the container toolkit was never installed.

You want the second one.

On Debian or Ubuntu:

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
 | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -fsSL https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
 | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
 | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

This is the same package on native Linux and inside WSL2. The only difference is where you stop: on WSL2 that command is the end of it, whereas on native Linux you also need a real NVIDIA driver underneath, which is the step WSL2 users are trying to replicate when they break their stub.

Running it

docker run -d --gpus=all \
 -v ollama:/root/.ollama \
 -p 11434:11434 \
 --name ollama ollama/ollama

docker exec -it ollama ollama run llama3.2

Drop --gpus=all and you get a working CPU install. That is a reasonable first move: it confirms the rest of your setup before you start fighting the GPU layer, and it means a later failure has exactly one new variable in it.

For AMD, the image and the flags both change:

docker run -d --device /dev/kfd --device /dev/dri \
 -v ollama:/root/.ollama -p 11434:11434 \
 --name ollama ollama/ollama:rocm

Note the volume is named.

/root/.ollama holds your downloaded models, and those are large. An anonymous volume there is how people re-download forty gigabytes after a cleanup — see which prune command eats data for why that happens.

Where 11434 really listens

There is bad advice in circulation. It says Ollama binds 127.0.0.1 by default, so publishing the port is safe.

That is true of a native install. It is not true of this image. The official container sets OLLAMA_HOST=0.0.0.0:11434 in its Dockerfile, so inside the container it listens on everything, and whatever you publish with -p is genuinely reachable.

Ollama’s API has no authentication. -p 11434:11434 on a machine with a public IP publishes an unauthenticated inference endpoint on someone else’s hardware budget. Bind it to localhost explicitly if you want it host-only:

-p 127.0.0.1:11434:11434

Compose, where `--gpus` does not exist

This is the second thing that costs people an evening.

--gpus=all is a docker run flag. Compose does not accept it as a service key, and the error you get does not point anywhere useful.

services:
 ollama:
 image: ollama/ollama
 volumes:
 - ollama:/root/.ollama
 ports:
 - "127.0.0.1:11434:11434"
 deploy:
 resources:
 reservations:
 devices:
 - driver: nvidia
 count: all
 capabilities: [gpu]

volumes:
 ollama:

Two rules inside that block, both documented and both easy to trip:

capabilities is not optional. Docker’s docs state that omitting it errors on service deployment. It looks like decoration and it is required.
count and device_ids are mutually exclusive. Pick one, or it errors.

There is also a newer top-level gpus: attribute if your Compose version has it, which is less verbose for the common case.

The WSL2 restriction nobody mentions

On WSL2, NVIDIA documents that only --gpus all is supported.

You cannot filter by index or UUID.

So a compose file pinning device_ids: ['0'] is documented as not workable under WSL2, even though the identical file is fine on native Linux. If you have two GPUs in a Windows box and were planning to give one to Ollama and keep the other for something else, that plan does not survive contact with WSL2.

That single limitation is the strongest argument I know for putting the LLM host on native Linux rather than WSL2, assuming you have the choice, and it is the kind of constraint that only shows up after you have already built the thing around the assumption that a GPU is a GPU.

Adding Open WebUI

The obvious next step is a browser interface. Open WebUI’s official stack runs it alongside Ollama, and their :cuda image tag is documented as Nvidia GPU support, to be paired with --gpus all.

One deliberate default worth understanding before you “fix” it: in Open WebUI’s official compose stack, the ollama service publishes no host port at all. 11434 is reachable on the Compose network and nowhere else. That is not an oversight. It means the only thing exposed is the UI, which has accounts, rather than the raw API, which does not.

If you genuinely need the API from the host, they ship a separate api overlay for that. Use it rather than editing the base file, so the reason stays visible.

Verifying the GPU is doing the work

The failure mode here is quiet. Everything runs. It just runs slowly, on the CPU, while you assume otherwise.

docker exec -it ollama nvidia-smi

If that errors, the container cannot see the GPU and no amount of Ollama configuration will help — the problem is the container toolkit or the driver.

Then run a prompt and watch nvidia-smi on the host. If VRAM use does not move and your CPU fans do, the model is not on the GPU. The usual cause is that the model does not fit in VRAM, which is a hardware question rather than a Docker one, and which I have written up separately in local LLMs by GPU VRAM.

What I have not tested

I have not run the ROCm image. The command above comes from Ollama’s documentation and I have no AMD card here to confirm it against, so treat that line as documented rather than verified by me.

I have not tested the newer top-level gpus: Compose attribute, and Compose version support for it is exactly the sort of thing that varies by distro package.

I have not benchmarked WSL2 against native Linux for inference throughput. I believe native is better and I have not measured it, so I am not going to give you a number.

What getting it wrong costs

The CUDA-inside-WSL mistake costs you a working GPU and then several hours, because the symptom appears after the install that felt like progress. You were closer before you started than after.

The -p 11434:11434 mistake costs more, and it costs it quietly. An unauthenticated inference API on a public address does not announce itself. It just becomes somebody else’s free GPU until you notice the electricity bill or the fan noise.

SSH Port Forwarding: -L, -R, -D and Why Your Reverse Tunnel Only Works Locally (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~10 min read · St. Louis County, MO

Three flags. The third is where the afternoon goes.

ssh -L 8080:internal-host:80 user@server # reach IN
ssh -R 8080:localhost:80 user@server # expose OUT
ssh -D 1080 user@server # SOCKS proxy

-L opens a listener on your machine. -R opens one on the server. That is the entire difference. Inverting it is the beginner mistake, and it announces itself immediately, which makes it the cheap one.

The expert mistake is different, and it is the reason this page exists: -R does not fail when it does not work. It succeeds into a state that is not the one you asked for.

The -R trap

You run this on a home machine, against a VPS with a public IP:

ssh -R 8080:localhost:80 user@vps

You expect http://vps-public-ip:8080 to reach the web server at home. From the VPS itself, curl localhost:8080 works perfectly, which is the detail that sends people off debugging their home firewall, their router, and eventually their ISP, when none of those were ever in the path. From anywhere else: connection refused.

Nothing errored. The tunnel is up. It is bound to 127.0.0.1 on the VPS, which is a perfectly good place for a listener to be if that is what you asked for, and you did not.

That is sshd’s documented default. Remote forwards bind loopback unless GatewayPorts is enabled, and it defaults to no.

Then comes the second half, which is the part that costs the extra hour. You reasonably try to force it from the client:

ssh -R 0.0.0.0:8080:localhost:80 user@vps # still loopback-only

It does not help.

ssh(1) is explicit: specifying a remote bind_address will only succeed if the server’s GatewayPorts option is enabled. Your bind address is a request, not an instruction — the server is free to override it, and by default it does exactly that, binding loopback anyway rather than refusing the forward and saying why. A refusal would have cost you thirty seconds. The override costs you the evening.

This is documented in OpenSSH’s own tracker as bug 1297, filed by someone who noticed the socket was always bound to 127.0.0.1 and [::1] and that -L had no such problem. That is the shape of the confusion: local forwards obey you, remote forwards negotiate with a server whose defaults you did not read.

Fixing it, on the correct side

On the server, in sshd_config:

GatewayPorts clientspecified

Then reload sshd. Not your session. The daemon.

I recommend clientspecified over yes deliberately. yes forces remote forwards to bind the wildcard address for every client on that server — a blunt, global change that removes the option of a loopback-only forward from everyone. clientspecified gives each client the choice, so -R 0.0.0.0:8080:... binds wide and a plain -R 8080:... stays local.

The two GatewayPorts

Here is the detail that turns a five-minute fix into a long one, and it is purely a naming accident.

There are two GatewayPorts options with near-identical wording:

File	Governs
`sshd_config` (server)	`-R` listeners the server opens on your behalf
`ssh_config` (client)	your own `-L` and `-D` listeners

They live in different files, on different machines, and do different jobs. Editing the client one, reloading nothing, and then wondering for forty minutes why the reverse tunnel is still loopback-only is an experience I would rather you skip.

Debugging -R? Server file. Every time.

-L, properly

ssh -L [bind_address:]port:host:hostport destination

host:hostport is resolved from the server’s perspective, and that is the entire point of the flag: you are borrowing the server’s view of the network for the duration of the session, which is why it reaches things your own machine has no route to. This reaches a NAS at 192.168.1.50 that your laptop cannot route to:

ssh -L 8080:192.168.1.50:80 user@homelab-gateway

Then browse localhost:8080. That is it.

By default that listener binds loopback on your machine, so nobody else on the coffee-shop wifi can use your tunnel. That default is correct. Leave it.

-L also accepts Unix sockets on either end, which is how you reach a socket-only service like a database or a Docker daemon without publishing a TCP port for it.

-D, the one people underuse

ssh -D 1080 user@server

That is a local SOCKS 4/5 listener. Point a browser’s SOCKS proxy at localhost:1080 and its traffic emerges from the server, with DNS resolved there too if the client is configured for remote DNS.

I reach for this more than -L when I am poking at a homelab, because it needs no per-service forwards. One flag, and the whole network is reachable by its internal names for as long as the session lives.

It is not a VPN. It carries only what an application deliberately sends through the proxy, so anything not SOCKS-aware ignores it completely and silently, which is a distinction people discover at the worst possible moment. If you want everything routed, you want WireGuard or Tailscale, not this.

-J, which is not a tunnel at all

ssh -J bastion.example.com user@internal-host

ProxyJump reaches a final destination through an intermediate. Nothing is published, no listener opens, and the bastion does not see your session in cleartext — your client negotiates end-to-end with the real target.

Keep the distinction clean.

Administrative access to a machine behind a bastion is a -J job.
Exposing a service is a -L or -R job.

I have watched people build an elaborate -L chain for something -J does in one flag, in ~/.ssh/config, permanently:

Host internal-*
ProxyJump bastion.example.com

“administratively prohibited”

channel 3: open failed: administratively prohibited

Two things about this message. The first one saves you a search.

First: the 3 is meaningless. It is OpenSSH’s local channel id from a format string. Searching the literal message with the number in it is why people find nothing.

Second: it means the server refused. Almost nothing more. There are at least three distinct causes, all server-side:

AllowTcpForwarding in sshd_config disallowing that direction. It takes local and remote as values, not just yes and no, so a server can permit -L and refuse -R.
A key option in authorized_keys — no-port-forwarding, or restrict, which turns everything off and then re-enables only what you name after it.
permitopen / PermitOpen restricting forwards to a specific host and port list that does not include the one you asked for.

Check them in that order. The authorized_keys case catches people out most often, because the server’s global config reads permissive and the restriction is sitting on the key itself, which is not where anyone looks second.

Privileged ports behave differently by direction

ssh(1) gives two different rules, and they are easy to conflate:

For -L: only the superuser can forward privileged ports. That is on your side.
For -R: privileged ports can be forwarded only when logging in as root on the remote machine. That is on the server’s side.

So -R 80:localhost:8080 to a VPS fails unless you are logging in as root there, which you should not be. Bind something above 1024 and put a reverse proxy in front of it.

Keeping a tunnel alive

An SSH tunnel is a process. Processes die. For anything you depend on, put it under supervision rather than in a terminal you will eventually close:

# /etc/systemd/system/tunnel.service
[Service]
ExecStart=/usr/bin/ssh -N -T -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes \
 -R 8080:localhost:80 user@vps
Restart=always
RestartSec=10

-N runs no remote command, -T allocates no TTY. ExitOnForwardFailure=yes earns its place: without it, ssh happily stays connected when a forward could not be established, and systemd sees a healthy process fronting a tunnel that carries nothing.

ServerAliveInterval matters because an idle tunnel crossing a NAT gateway is exactly the kind of connection a middlebox reaps without telling either end, leaving you with a socket that looks established on both sides and moves nothing.

Where this stops being the right tool

Reverse tunnels are the classic answer to “my home connection has no public IP”, and for one or two services they remain a genuinely good one, because the alternative is standing up infrastructure to solve a problem that a single flag already solves. They work. I still keep one for a couple of things.

But if you find yourself maintaining several, plus a systemd unit for each, plus GatewayPorts on a server whose config you now have to remember, you have hand-built a worse mesh VPN. That is the point to look at Tailscale or WireGuard, or at running the control plane yourself.

The honest dividing line I use is this. One or two forwards, occasional, and -R is fine.

More than that, or anything a household depends on, and the tunnel collection has quietly become technical debt with a systemd unit attached to each piece.

What I have not tested

I have not verified whether a current client surfaces the loopback downgrade under -v. OpenSSH added a debug message for this case in the 6.4 era, and I could not establish from the sources I read whether that reliably reaches a modern user’s terminal. Assume it is silent and check the listener yourself with ss -tlnp on the server.

I have not tested any of the authorized_keys restriction interactions on a live sshd during this write-up, so treat the ordering advice as a plan of attack rather than a measured result.

What getting it wrong costs

The -R trap costs an evening. That is the good outcome: you conclude nothing works, and go read the docs.

The bad outcome is GatewayPorts yes set globally on a server, forgotten, on a box that also hosts something else. Now every remote forward any account opens binds the wildcard address by default. Somebody tunnels an admin panel out to test something, leaves it up, and there is a listener on a public IP that nobody remembers creating.

clientspecified costs nothing extra and does not accumulate that debt.

Uptime Kuma Docker Setup, and Where to Actually Run It (2026)

LK Wood IV — Sat, 15 Aug 2026 00:00:00 -0500

By LK Wood IV · 2026-08-15 · ~9 min read · St. Louis County, MO

Uptime Kuma installs in about ninety seconds. One container, one volume, one port. That part is genuinely easy, and every guide covers it.

Here is the part that decides whether the install was worth doing: a monitor that lives inside the network it watches cannot tell you that network went down. Put Kuma on your Proxmox box, point it at your NAS, your Jellyfin, your reverse proxy, and go to bed happy. Then the UPS gives up at 3am. Everything stops, including Kuma. Your phone stays quiet all night, because the thing whose job was to shout is on the floor with everything else.

You find out at 9am. The dashboard shows a clean green wall, because it has no memory of the hours it spent unpowered, and a gap in the record renders identically to a stretch of perfect health once the container comes back and resumes drawing bars.

I have watched people run this setup for months and conclude their homelab is extremely reliable. It wasn’t.

The install, briefly

Version 2.5.0 shipped on 1 August 2026. Pin the major tag.

services:
 uptime-kuma:
 image: louislam/uptime-kuma:2
 container_name: uptime-kuma
 restart: unless-stopped
 ports:
 - "3001:3001"
 volumes:
 - ./data:/app/data

mkdir -p /opt/uptime-kuma/data && cd /opt/uptime-kuma
docker compose up -d

Open port 3001 and create the admin account on first load. That’s it. There is no separate database container. Kuma uses SQLite inside that one data volume, which is why this compose file is four lines of service definition instead of the five-container arrangement a Paperless-ngx stack needs. Version 2.x can talk to other backends for large deployments. For a homelab watching a few dozen endpoints, SQLite is correct and it is one fewer thing that can fail at 3am.

Do not publish 3001 to the internet. It is a login page standing in front of a complete map of your infrastructure, including hostnames and internal ports you would rather not advertise. Put it behind Nginx Proxy Manager or reach it over a WireGuard or Tailscale tunnel.

That is the whole tutorial. The rest of this page is about placement, which is where the value is.

Why placement is the whole problem

Uptime Kuma measures reachability. It sends a request and reports whether something answered. Every result it produces is therefore relative to one specific position on the network — its own.

From inside your LAN, Kuma can see that Jellyfin’s container is answering on port 8096. That is a real and useful fact. It is not the fact your users have. Your users are outside, and between them and Jellyfin sits your ISP, your modem, your router’s NAT and port forwarding, your DNS records, your certificate expiry, and your reverse proxy. Kuma checking http://192.168.1.40:8096 validates exactly one link in that chain and silently vouches for the rest.

So there are two distinct failure classes. One monitor position cannot cover both, and the table below is the reason I stopped treating a single green dashboard as evidence of anything.

Failure	Seen from inside	Seen from outside
Container crashed	yes	yes
Disk full, service refusing writes	yes	yes
Certificate expired	no	yes
DNS record wrong or lapsed	no	yes
ISP down, modem dead, power cut	no — monitor is down too	yes
Port forward removed by a firmware update	no	yes
VPN tunnel to the monitor collapsed	n/a	shows as a false outage

The bottom-left cell is the one that matters. When the whole site loses power, an internal monitor does not report an outage. It reports nothing at all, and nothing looks exactly like fine.

Two placements that work

Primary outside, pointed in. Run Kuma on a small external host and monitor your public endpoints the way a stranger would. This is the setup I would pick if I were only running one instance. It catches expired certificates, broken DNS, dead port forwards, and total site loss, because it is not standing on any of the things that break. Requirements are modest, which is the useful part: Kuma is a single Node process with a SQLite file, so the smallest tier at any VPS host is enough to watch a homelab’s worth of endpoints.

The trade is real. An outside instance sees only what you publish, so anything you never exposed to the internet is invisible to it, and that is usually most of the stack.

Two instances, watching each other. Keep the detailed instance inside, where it can reach every container and internal port. Add a second, nearly empty instance outside whose entire job is to watch the first one and a couple of public endpoints. Point each at the other’s health endpoint. Now an outage has to take out two separate sites and two separate uplinks before you hear silence.

This is the arrangement I would run for anything I actually cared about, and it costs one small VPS.

Do not try to solve this by having the outside instance reach in over a tunnel to check internal services. It sounds tidy. It fails badly, and in a specific way: the tunnel becomes a shared dependency, so every tunnel hiccup fires as a simultaneous outage across a dozen unrelated monitors, and after two weeks of that you will start ignoring the alerts. Which is worse than not having them.

The push monitor is the one people skip

Most Kuma monitors ask a question outward. The push monitor inverts that — it hands you a URL and waits to be called.

# at the end of your backup script
restic backup /data --repo "$REPO" && curl -fsS "$KUMA_PUSH_URL"

If the script finishes, Kuma hears from it. Good. If the script fails, hangs, or was never scheduled because the cron entry got clobbered, the call never arrives and Kuma alerts on the silence.

This catches a class of problem that no reachability check will ever see. Your backup host can be up, healthy, answering pings, and passing every HTTP check while quietly not having produced a backup in five weeks. I would put a push monitor on every scheduled job whose failure you would not notice for a month. Backups first.

Notification settings that avoid making you ignore it

The defaults are tuned to demonstrate the feature, not to survive contact with a homelab that reboots.

Set Heartbeat Interval to how fast you could genuinely respond. Sixty seconds is a reasonable floor. Set Retries to at least 3 before a monitor is marked down, so a container restart does not page you. Sixty seconds with 3 retries gives a service three minutes to come back on its own, which covers nearly every routine restart.

Add at least two notification channels through different infrastructure. Kuma supports over ninety providers. The reason for two is narrow but real: if you route everything through one service and that service is the thing that broke, your alert about the outage is part of the outage.

Then leave it alone for a week and count how many notifications you received that you did not act on. Every one of those is training you to dismiss the next one. Raise the retries until that count is near zero.

The status page, and whether you need a domain

Kuma’s status pages are genuinely good and cost nothing to set up. Group your monitors, mark which ones are public, and publish.

You need a hostname for it if the audience is anyone other than you. A status page at an IP address with a certificate warning does not reassure the household that the media server is coming back. If you are already buying a domain for your reverse proxy, a status. subdomain on it is free and takes about two minutes.

If the audience is only you, skip the domain and reach it over the tunnel.

What I have not tested

I have not run Kuma at a scale where SQLite is the constraint, so I cannot tell you where that boundary sits or whether moving to MariaDB is worth the extra container. Everything above is from homelab-scale use — dozens of monitors, not hundreds.

I have not measured Kuma’s resource use on the very smallest VPS tiers, and I would rather say that than quote a RAM figure I did not take. It is a single Node process with a SQLite file, so the tier below whatever you were considering is probably fine, but “probably” is doing real work in that sentence.

The 2.x non-SQLite backends I have not touched at all.

What getting this wrong costs

A silent monitor is worse than no monitor, because it converts an unknown into a false negative. You stop checking manually. You stop being suspicious. Then a drive fails in a mirror and the array runs degraded for three weeks, and the second drive fails, and the honest answer to “when did this start” is that nobody knows.

The install is ninety seconds. The placement decision is the part that determines whether any of it works, and it is the part almost every guide leaves out — including, for about a year, mine.

GPU Fans Stuck at 100%: The Fix Order That Finds the Cause

LK Wood IV — Thu, 13 Aug 2026 09:20:00 -0500

Fans pinned at 100% feel like an emergency because of the noise, but the noise is the least informative part. A modern card only commands full speed for a handful of reasons, most of them software, and the fastest path out is to check them in the order below — cheapest and most common first — instead of opening the case with a screwdriver on cause number six.

First: two situations where full speed is correct

Before the driver loads. From power-on until the graphics driver initializes, there is no fan-control logic running, and many boards default the fans high or to maximum as a failsafe. Loud at the BIOS screen, quiet at the desktop is normal behavior, not a fault.

When the card is genuinely at its limit. If a monitoring tool shows the hotspot or memory-junction sensor high while the fans scream, the controller is doing its job and your problem is cooling, not control — repaste, airflow, or dust, covered in that guide. Everything below assumes the temperatures are unremarkable while the fans are not.

The fix order

1. Reboot once, properly

A full shutdown and cold boot clears a one-off controller glitch and re-runs the driver’s fan initialization. If the fans come back under control and it never recurs, stop here. If it recurs, the reboot was a clue, not a fix — keep going.

2. Find the fight between fan-control programs

Count everything on the machine that can touch GPU fans: MSI Afterburner, the card vendor’s utility (Armoury Crate, Adrenalin’s tuning tab, iCUE, and friends), and motherboard suites. Two controllers arguing over one card routinely ends with a curve pinned at an extreme. Pick one owner, disable GPU fan control everywhere else, then set that one program’s curve back to its default profile. While you are in there, check for a forgotten manual override — a fixed-speed toggle left at 100% behaves exactly like this and survives reboots.

3. Reset the curve itself

If the single remaining controller still pins the fans, its stored curve or the card’s fan table may be corrupt. Reset the utility to defaults (or uninstall it and let the driver’s automatic control take over). On cards with a dual-BIOS switch, confirm it did not get bumped to the performance position, which runs a deliberately aggressive curve on some models.

4. Rule out the driver-crash fallback

A hung or crashed driver can leave the card with no one steering — and the failsafe is full speed, the same as before boot. If the pinning started after a driver update, or fans max out mid-session while the screen stutters or recovers, do a clean reinstall with DDU in Safe Mode per the GPU driver crash guide. Install the previous stable driver if the newest one is when the trouble began.

5. Check what the sensors are actually reporting

Open a monitor that shows every GPU sensor, not just the core. A controller reacting to a hotspot or memory sensor you were not watching is case “working as designed” from the first section. But a sensor reading that is obviously wrong — a temperature pinned at an impossible value while the others sit normal — means the controller is acting on bad input, which on most cards is a warranty conversation rather than a settings fix.

6. Suspect the fan that reads zero

If one fan reports 0 RPM under load while its neighbors run flat out, the controller may be compensating for a fan it believes has died — and the dead fan (or its tachometer wire) is the real fault. Confirm visually under load: a fan commanded to spin that stands still is the answer. Individual replacement fans exist for most current cards, and swapping one is far cheaper than living at 100%.

After it is fixed

Set the curve somewhere sane and quiet — the diagram above is the shape to aim for: silent below the zero-RPM threshold, smooth ramp through the middle, maximum held in reserve for genuine trouble. If what pushed you here was noise generally, an undervolt cuts the heat the curve responds to, and if the sound that remains is an electronic whine rather than airflow, that is coil whine — a different animal with its own page. And if your problem is the opposite one, read GPU fans not spinning instead.

MXFP4 vs Q4_K_M: Why 21B Beats 14B on an RTX 5080

LK Wood IV — Thu, 13 Aug 2026 09:05:00 -0500

The strangest row in our RTX 5080 throughput dataset is the one where the biggest model is not the slowest. gpt-oss 20B — 20.9B parameters as ollama reports it — decodes at 187–190 tokens per second. Qwen 2.5 14B, six billion parameters smaller, manages 94–97. The “bigger” model is twice as fast, and it lands within a few percent of the dense 7B. None of that is a fluke, and the explanation is worth having because it changes which models you should even shortlist on a 16GB card.

The numbers, and where they come from

Everything below is from our own bench: ollama 0.32.1 on a retail RTX 5080 (driver 610.88), medians of three fresh-prefill runs per cell, model digests pinned, with a nonce prepended each rep so the prompt cache cannot fake the prefill numbers. The full matrix, method, and raw CSV are on the dataset page.

Model	Params	Quant	Decode tok/s	Resident VRAM
Llama 3.2 3B	3.2B	Q4_K_M	298–313	~5.4GiB
gpt-oss 20B	20.9B	MXFP4	187–190	~13.7–14.0GiB
Qwen 2.5 7B	7.6B	Q4_K_M	177–180	~6.0–6.9GiB
Qwen 2.5 14B	14.8B	Q4_K_M	94–97	~10.6–12.8GiB

Decode is a memory race, and only active bytes run it

Generating a token means streaming the model’s weights through the GPU once. Do that a hundred times a second and the limiting factor is not compute — it is how fast VRAM can feed the cores. The RTX 5080’s memory bus moves about 960 GB/s. So the ceiling is simple division: bandwidth over bytes-touched-per-token.

Run it for the dense 14B. Q4_K_M stores roughly 4.5–4.8 bits per weight, so 14.8B parameters is about 8.5–8.9GB that every single token must read. 960 ÷ 8.7 ≈ 110 tokens per second as the theoretical ceiling — and the measured 94–97 is about 90% of that. The arithmetic and the measurement agree, which is how you know the model is bandwidth-bound.

Now gpt-oss 20B. It is a mixture-of-experts model: per OpenAI’s model card, 21B total parameters but only about 3.6B active per token, with the expert weights shipped natively in MXFP4 — 4-bit floating point with shared scale factors, the OCP microscaling format. The 21B has to fit in VRAM (hence the ~14GiB resident), but each token only streams the active slice. A few gigabytes per token instead of nine. That is the whole trick, and it is why the 21B model decodes like a 7B — because per token, it approximately is one.

Total parameters decide whether a model fits. Active bytes decide how fast it runs. Those are different questions, and the spec sheets only advertise the first.

What context length actually costs

The other quietly useful result: at prompts of ~500 and ~1,700 tokens, decode speed was flat between num_ctx 4096 and 16384 for every model — within about 1%. The 16k configurations cost VRAM (the KV cache has to live somewhere) but not speed at these lengths. If you have been keeping context small to protect tokens per second, at normal prompt sizes you are paying a real capacity price for an imaginary speed benefit. Push into genuinely long prompts and attention will eventually take its cut — but that boundary is much further out than the folk wisdom says.

Prefill tells the same story from the other side: it is compute-bound and parallel, and gpt-oss chewed through prompts at 9,000–10,500 tokens per second, roughly double the dense 14B there too.

What to shortlist on a 16GB card

If you want the strongest model that still feels instant on this class of hardware, the measured answer is the MoE: gpt-oss 20B gives 14B-and-up class capability at dense-7B interactive speed, for about 14GiB of resident VRAM. The dense 14B is the choice when a specific dense model’s quality on your task justifies half the speed. And the 3B remains the bulk-work option — 300 tokens per second is a different kind of tool.

Where your GPU lands if it is not a 5080: the local LLM by GPU VRAM guide maps models to cards, the LLM speed calculator estimates decode from bandwidth and quant, and the VRAM calculator does the fit math. What running this card 24/7 costs in electricity is measured in the 5080 perf-per-watt piece.

The dataset behind every number here is CC BY 4.0 — take it: /data/rtx-5080-llm-throughput/.

Coil Whine Database: Per-Model Community Census (GPU, PSU, AIO)

LK Wood IV — Wed, 12 Aug 2026 00:00:00 -0500

By LK Wood IV · Published 2026-08-12 · ~5 min read · St. Louis County, MO

The short version

Coil whine is one of the most-asked PC noise questions with the least data behind it. As of an August 2026 check, no per-model coil whine database existed anywhere — community knowledge lives in scattered forum threads, plus one lab analysis (hwcooling.net) that measured a 30-card batch once and stopped. Meanwhile “coil whine” draws about 2,900 searches a month and “gpu coil whine” another 1,000 (Google Ads exact match, checked 2026-08-12). This page opens the census that should exist: owner reports of GPUs, PSUs, and AIO pumps on an anchored 0-4 severity scale, published as per-model distributions.

The raw data, schema, and intake all live in the open repository: github.com/iBlessi/coil-whine-db (CC BY 4.0).

Why distributions, never verdicts

The defining fact about coil whine is the design constraint for the whole dataset: it varies unit to unit. The same GPU model ships silent units and screaming units, because the outcome depends on which inductors a particular board received, how they were potted, the PSU feeding them, and the load pattern — not on the model name. A review unit that stays quiet proves nothing about the unit you will receive, and one loud unit on a forum proves nothing about the model.

So the honest per-model answer is never “the RTX 4090 whines” or “it doesn’t.” It is a distribution: out of n reported units, this share was inaudible, this share was audible at the desk, this share screamed even at idle. That is what this database publishes — odds, never verdicts.

The schema

One row = one physical unit an owner listened to. Full machine-readable definitions live in schema.json.

Field	Required	What it records
`component_type`	yes	`gpu`, `psu`, or `aio-pump`
`brand`	yes	As printed on the box — ASUS, Corsair, Arctic
`model`	yes	Model line, specific enough to group units — “ROG Strix RTX 4090”, “RM850x (2021)”
`exact_sku`	no	Exact manufacturer SKU when known
`purchase_year`	yes	Year this unit was bought
`severity`	yes	0–4 on the anchored scale below
`load_context`	yes	Where the score was observed: `idle`, `gaming`, `menu-uncapped-fps`, `furmark`
`psu_used`	no	For GPU reports: the PSU in the system — whine sometimes moves with it
`fps_cap_changes_it`	no	Whether capping FPS audibly changes it — `true` / `false` / untested
`notes`	no	Free text, max 280 characters
`submitted_date`	yes	ISO date of the report

The severity scale (anchored)

Severity	Anchor
0	Inaudible in a quiet room
1	Audible with an ear at the case
2	Audible at the desk under load
3	Audible across the room under load
4	Audible even at idle

Score the unit at its loudest normal state. The anchors are fixed on purpose: changing them would make old and new rows incomparable, so any future anchor change bumps the dataset’s major version instead of quietly redefining the numbers.

How to submit a unit

One report = one physical unit you own or owned, judged by your own ears — not a model you read about. Severity-0 reports (“mine is silent”) are the most valuable rows in the census, because they are the half of the distribution that never shows up in forum threads.

No git knowledge needed — fill in the coil whine report issue form. It mirrors the schema field-for-field; a maintainer transcribes accepted reports into the CSV, with submitted_date taken from the issue’s creation date.
The CSV path — add one row to data/submissions.csv following the schema, and open a pull request. A stdlib validator runs on every PR and blocks malformed rows.

Every submission passes two layers before it lands: the mechanical schema check, and a maintainer review for outlier and troll patterns — duplicate-account bursts filing the same model at the same severity, impossible combinations like a purchase year before the model existed, and rows that summarize other people’s threads instead of a unit the submitter heard. The full acceptance rules are in CONTRIBUTING.md.

What publishes as the census grows

The activation floor, stated verbatim: per-model n + severity distribution once a model has >=5 reports. Below that floor a model is listed as collecting, with no numbers attached. As models cross the floor, their distributions render on this page — n first, then the share of reports at each severity level, always with the sample size in the same breath as the percentages.

The census opened at 0 rows by design — a dataset about unit-to-unit variance cannot be seeded from published reviews, because each review describes a single unit that is not ours to report. Every row is a real owner reporting a real unit.

Current count: n=1. Submission #1 is the maintainer’s own ASUS ROG Astral RTX 5080 OC — severity 1, audible only in uncapped game menus, silenced by any frame cap. It is the same physical card behind the Astral 5080 bench dataset, so its provenance is already public. One report proves the pipeline, not a distribution: the ROG Astral RTX 5080 OC is listed as collecting until it reaches n=5.

The honesty rules

No verdicts below n = 5. A model with three angry reports is collecting, not “a whiner.”
Self-selection bias is named, not hidden. People annoyed by a noise go looking for a place to report it; people with silent units mostly don’t. Annoyed owners over-report and silent units under-report, so every published whine percentage is a ceiling, not an unbiased estimate. The severity-0 row exists to shrink that bias, not to pretend it away.
Anchors never drift. The 0–4 scale above is frozen; a change would be a new major version, and old rows would be marked as scored on the old scale.

Use the data (CC BY 4.0)

The live dataset is one file: data/submissions.csv — one row per reported unit, in the schema order above. License: Creative Commons Attribution 4.0. Attribute as “TechFuelHQ Community Coil Whine Census” linking to this page.

If the noise is bothering you today, the diagnosis and mitigation walkthrough is the coil whine guide: is it normal, and where is it coming from? — and a brand-new buzz paired with crashes belongs in the PSU failure symptoms guide rather than a census form. If capping FPS quiets your card and you want the deeper fix, the GPU undervolt settings database is the companion dataset.

Change log

0.1.0 (2026-08-12) — schema, anchored severity scale, intake (issue form + PR path), validator, and the empty census opened: 0 rows, no seeded data.
0.1.1 (2026-08-13) — first accepted report: the maintainer’s own Astral RTX 5080 OC via the issue-form flow (issue #1 -> validated row). n=1; every model remains below the n>=5 distribution floor.

TechFuel HQ

Best Motherboards for Ryzen 7 9800X3D (2026)

The three boards at a glance

The rule that prevents motherboard overspending

1. MSI B850 Tomahawk Max WiFi is the default

2. ROG Strix B850-G is the white micro-ATX pick

3. Crosshair X870E Hero is for expansion

B850 vs X870 vs X870E for the 9800X3D

Are the CPU bundles worth it?

What about B650 and X670?

RAM, cooling, and the rest of the build

The shortest honest recommendation

Best RTX 5080 Prebuilt Gaming PCs (2026)

The three picks at a glance

How I ranked the systems

1. ABS Kaze II Ruby has the strongest disclosed parts list

2. Andromeda V3 Ultra 50 is the value pick

3. Acer Nitro is the brand-name alternative

What I rejected

A lower-tier CPU at the same system price

Sixteen gigabytes of system memory

One terabyte of storage

A vague or undersized power supply

Marketplace ambiguity

The price ceiling for a 32GB and 2TB build

What performance should you expect?

The 60-second checkout audit

Best RTX 5090 Prebuilt Gaming PCs (2026)

The three picks at a glance

How I ranked the systems

1. Stormcraft Valkyrie is the best pick

2. Acer Nitro is the value pick

3. Thermaltake View 9890S is the premium alternative

Why these are 9800X3D systems

What a $5,000-plus prebuilt must disclose

A native high-current power path

Two memory modules

Storage that fits the price

A motherboard and case you can expand

RTX 5090 or RTX 5080 prebuilt?

The price ceiling

The 60-second checkout audit

Best Wi-Fi 7 Routers (2026): 3 Picks That Make Sense

Three picks at a glance

The decision before the product

1. TP-Link Archer BE550 Pro is the best pick

2. ASUS RT-BE88U is the wired-first exception

3. ASUS GT-BE98 Pro is the flagship

Why 6GHz changes the ranking

Port topology beats a 30Gbps box number

Standalone router or mesh?

Do not upgrade to solve a fault

The 60-second checkout audit

RTX 5090 vs RTX 5080 (2026): Which One Should You Buy?

The decision in one table

Current direct-retailer example

Specifications that matter

How much faster is the RTX 5090?

What the RTX 5080 already does at 4K

The 16GB versus 32GB decision

Local AI: use measured data, not parameter-count folklore

Power, case, and the rest of the system

Price-to-performance without fake precision

Buy the RTX 5080 if

Buy the RTX 5090 if

Complete system or card?

Monitor Flickering? Use Task Manager to Find the Cause

The 30-second split

Step 1: Reset the graphics driver

Step 2: If Task Manager is stable, find the app

Step 3: Work the connection and power path

Step 4: Test the refresh rate

Step 5: Only flickers in games? Test VRR

Step 6: When the monitor itself becomes the likely fault

The fix order

Sources

Adding a User to the Docker Group Is Not a Convenience Setting (2026)

Why it is root, concretely

So why does every tutorial recommend it

Why the change does not take effect immediately

Compose, where `--gpus` does not exist