DEV Community: Martin Stark

nvoc: linux overclocking gains multi GPU support, scripting, and is improved for ai use

Martin Stark — Fri, 26 Jun 2026 20:53:08 +0000

The latest version has focused on overclocking for running local LLMs (AI). Primarily better memory OC support, and improved support for targeting mixed GPU models in a single system. Read on.

Back in September I posted about NVOC - NVIDIA GPU Overclocking for Linux, an ergonomic cli tool for overclocking and undervolting RTX 50-series cards on Linux.

The tool is at v0.3.0 now. It picked up multi-GPU support, machine-readable output, a few more cards, and a clean way to apply settings at boot.

More than one GPU

The first release assumed you had one card and operated on device 0. There was no way to point it at a specific GPU in a multi-card system.

There is now a -d/--device flag. The simplest form takes an index, or a comma separated list of them:

# one card
sudo nvoc -d 1 -o 856

# two specific cards
sudo nvoc -d 0,1 -c 200,2820 -o 856 -m 2000 -p 105

# everything in the box
sudo nvoc -d all -o 200

Indices are convenient until you reboot and they shuffle. NVML does not promise they stay put, so for anything you want to survive a restart, select by something stable.

Selecting a card without counting

You can target a card by UUID, by a substring of its name, or by a regex against the name:

# stable across reboots
sudo nvoc -d GPU-1234... -o 856

# case-insensitive substring on the device name
sudo nvoc -d name:5090 -o 856
sudo nvoc -d "n:5060 ti" -o 100

# regex, for a mix of models
sudo nvoc -d "regex:RTX 50[89]0" -o 856
sudo nvoc -d "r:5060( Ti)?" -o 100

In a box with a 5090 and a couple of 5060 Ti, name:5090 is easier than working out which index the driver handed each card this boot.

nvoc list

To select a card you first need to know what is in the machine. nvoc list prints the index, name, and UUID of every GPU it can read:

$ nvoc list
0 - NVIDIA GeForce RTX 5090 - GPU-1234...

It skips devices it cannot read instead of falling over on them, so one flaky card does not take the whole listing down with it.

Output you can pipe

info and list both take --json now, which is what you need to drive nvoc from a script rather than by hand:

nvoc info --json
nvoc list --json

There is also nvoc list --uuid, which prints just the UUIDs, one per line. Put the two together and you can apply the same settings to every card by UUID without hardcoding anything:

for uuid in $(nvoc list --uuid); do
  sudo nvoc -d "$uuid" -o 856 -m 2000 -p 105
done

(-d all does the same in one shot. The loop earns its keep when you want different values per card.)

Not only RTX 50-series

The original gated on the card being an RTX 50-series part by matching its name. That was lazy, and it locked out the RTX PRO Blackwell cards, which are the same architecture wearing a different name.

nvoc now asks NVML for the architecture directly and accepts anything Blackwell, so the workstation cards work too. It is still Blackwell only, though.

A call for help

There is experimental support for Ada Lovelace (RTX 4060, 4070, 4080, 4090) and Ampere (RTX 3050, 3060, 3070, 3080, 3090) already, but it needs testing on hardware I do not have. If you own one of those cards, trying the relevant branch and reporting your results would be appreciated.

Draft PRs: Ada Lovelace (40-series) and Ampere (30-series).

Applying settings at boot

Overclock settings do not persist. Reboot and you are back at stock. A systemd oneshot service reapplies them automatically:

# /etc/systemd/system/gpu-oc.service
[Unit]
Description=GPU overclock settings
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/nvoc -c 200,2820 -o 856 -m 2000 -p 105

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now gpu-oc.service

On a multi-GPU box, pin by UUID or model rather than index, for the reasons above. The README has the full walkthrough.

Installing

If you are on Arch, it is in the AUR now:

paru -S nvoc-cli

Building from source still works the same way with cargo build --release.

Smaller things

reset puts clocks back through NVML directly, instead of the slightly hacky idle-clock trick the first version leaned on, and it attempts every reset before reporting what failed rather than bailing on the first error.
--dry-run no longer needs root, since previewing a change should not require privileges to do nothing.
Device names stopped truncating, after a switch to the v2 NVML name buffer.
info shows the memory clock offset next to the graphics one now.
An unknown device error points you at nvoc list instead of leaving you to guess.

$ nvoc info
driver: 595.71.05
gpu 0: NVIDIA GeForce RTX 5090
gpu clock: 1080MHz
gpu offset: 856MHz
mem clock: 810MHz
mem offset: 2000MHz
temp: 52°C
power: 28W
power limit: 600W (104%)
power range: 400W-575W (600W hard limit)

Repo and issues: https://github.com/martinstark/nvoc/

A Free Screenshot Editor That Never Uploads Your Image

Martin Stark — Fri, 26 Jun 2026 11:34:04 +0000

A few times a week I take a screenshot, circle something on it, sometimes cover up an email or a token, and send it on. I wanted to do that without the image ever leaving my machine, especially when it holds something private.

So I built edit-image.eu. It runs entirely in the browser. Paste a screenshot with Ctrl+V, drop a file, or pick one from your device, then mark it up with text, arrows, shapes, and freehand drawing. Crop it, then copy it back to the clipboard or download it as PNG, JPEG, or WebP. Nothing is sent anywhere, because there's no server behind it.

There's an undo stack and a history panel that removes any single edit you made earlier and leaves the rest. That panel shaped the design.

Keeping edits editable

The easy way to build a canvas editor is to draw each shape straight onto the bitmap. That works until someone wants to remove one arrow they drew five arrows back. Once the pixels are merged, it's gone.

So the picture isn't a bitmap with drawings baked in. It's a base image plus an ordered list of annotation objects, each one knowing its own position and style. Rendering replays that list over the base whenever something changes.

Undo and redo become snapshots of the list. The history panel drops object number three and redraws the rest as if it was never there. Moving a label nudges one object's coordinates. Crop swaps the base image and shifts everything else, so it undoes like any other edit.

Big photos on phones

Loading photos from a phone takes some care. The obvious way to turn that file into something drawable is createImageBitmap(blob), which is fine on a laptop. On a phone, a 12 megapixel photo decodes to a full resolution bitmap in memory, enough on some devices to kill the tab before anything reaches the screen.

So large images decode through a plain <img> and draw into a canvas capped at 4096 pixels on the longest edge. createImageBitmap only sees the small result, and the huge intermediate never exists. Files already under the cap keep their original bytes, so nothing is re-encoded needlessly.

No framework

There's no React or Vue here. The interesting state lives in the canvas, not the DOM, so a framework would mostly stand around watching. The visible UI is a couple of toolbars and a few popovers.

So it's plain TypeScript with a small pub/sub store, Canvas2D, rsbuild for bundling, and Biome for lint and formatting. The shipped JavaScript is about 48 KB, or 16 gzipped. No analytics or backend calls, so the network tab stays quiet after the page loads.

Try it

It's free, at edit-image.eu. Paste a screenshot and start marking it up. It's still a work in progress, so if something breaks, especially on a browser or device I haven't tried, I'd like to hear about it.

nvoc - linux OC/UV cli utility for RTX-50 series

Martin Stark — Fri, 26 Sep 2025 08:22:26 +0000

https://github.com/martinstark/nvoc/

I got tired of having to create multi-line scripts for applying a semblance of overclocking/undervolting on Linux, so I wrote a cli app that does it in a single line, example for 5090:

sudo nvoc -c 200,2820 -o 900 -m 3000 -p 105

-c = min,max core clocks
-o = graphics offset
-m = memory offset
-p = power limit

Since it's only possible to set a full curve offset on Linux (there is no per-voltage offset like in MSI Afterburner), and I don't want my idle clocks to be ~1100mhz, I wanted a utility to quickly apply and reset the OC when I need it.

NVIDIA kindly removed the ability to query GPU voltage from their Linux APIs. Due to that, I think the only way to simulate MSI Afterburner-like behaviour, where you can have default idle clocks (200mhz) and have an offset for higher load scenarios, would be to set up an elevated service that applies the OC as soon as the GPU goes above ~2000mhz, and resets the OC if the clocks drop down below 2000mhz for a number of seconds.

Functionality

# Show GPU information
nvoc info

# OC
sudo nvoc -c MIN,MAX -o OFFSET -m MEM_OFFSET -p POWER_LIMIT

# Reset
sudo nvoc reset

# Dry Run
nvoc -c 200,2800 --dry-run

info output:

$ nvoc info
Driver 580.82.09
0: NVIDIA GeForce RTX 5090
Blackwell v16777240
GPU: 1177MHz
GPU Offset: 960MHz
Mem: 15501MHz
Temp: 56°C
Power: 45W
Power Limit: 600W (104% of default)
Power Range: 400W-575W (hard limit: 600W)

Client Side Ad Insertion Crash Course

Martin Stark — Wed, 29 May 2024 12:43:28 +0000

This guide acts as a quick overview of concepts relevant to CSAI, it is not meant to act as a complete tutorial.

What is CSAI?

Client Side Ad Insertion means that the app on the user's device is responsible for fetching and displays advertisement as part of the streaming experience. This is in contrast to Server Side Ad Insertion, where the ads are stitched into the video on the server.

VMAP

The VMAP is fetched or polled by the client, it is parsed to check when an ad break should occur.

VAST

The VAST document is fetched and parsed by the client, it represents the content of an ad break.

The VAST document can contain several types of ads. For example: video, images, and companion links.

The VAST specifies how an ad should be tracked. It says which events need to be sent to a tracking server in order to verify if and how much of the ad was watched and/or interacted with.

Displaying the Ads

When it is time to show the ad to the user, it is usually handled by pausing the content stream, creating a new video element, overlaying it on the content stream, and playing the ad(s). When the ad break is finished, remove the ad specific video element and resume the content stream.

Interpreting HTML5 Video Events

Martin Stark — Mon, 13 Mar 2023 12:05:55 +0000

When building a HTML5 web video player, it tends to need a user interface, quality of service tracking, user interaction tracking, and sometimes ad tracking. To achieve this, the HTML5 Media Event standard needs to be interpreted.

After building multiple web video players, and having worked on more than one iteration of an event interpreter, something didn't feel right. Things weren't kept DRY.

When repetition strikes, it's usually a good idea to do something about it.

Creating a Media Event Filter

Enter @eyevinn/media-event-filter, a filter that interprets HTML5 media events in a way that makes sense.

This filter aims to provide a single source of truth that can be used across player engines and native browser playback.

Whether using one or multiple player engines, like Shaka Player, HLS.js, or dash.js, the filter will output a standardised event sequence. It does so without relying on events output by the player engine, giving applications a single, player agnostic, source of truth for video playback state updates.

Example Implementation

import {
  getMediaEventFilter,
  FilteredMediaEvent,
} from "@eyevinn/media-event-filter";

const videoElement = document.createElement("video");

const mediaEventFilter = getMediaEventFilter({
  videoElement,
  callback: (event: FilteredMediaEvent) => {
    switch (event) {
      case FilteredMediaEvent.LOADED:
        // handle loaded
        break;
      case FilteredMediaEvent.BUFFERING:
        // handle buffering
        break;
      case FilteredMediaEvent.BUFFERED:
      // handle buffered
      // ...
      default:
        break;
    }
  },
});

// Create a player, using your engine of choice
const player = createPlayer(videoElement);

// Load a manifest and play
player.load(url).then(player.play);

// Call when done
mediaEventFilter.teardown();

Live Example

See a barebones React + Shaka + Media Event Filter example over at codepen.

Production Readiness

While making the filter open source is recent, it has been battle tested for years. With millions of playback sessions, multiple third party tracking systems have been validated using the filter.

Event Sequence

The sequence follows the Eyevinn Player Analytics Specification, which maps directly to many popular tracking service provider SDKs.

Sample event sequence comparison, using <video autoplay> with Shaka Player in Firefox, excluding timeupdate:

Native	Filtered	Comment
ratechange	—	Shaka sets playback rate to 0 to control buffering
progress	—
durationchange	—
resize	—
loadedmetadata	—
ratechange	—
progress	—
loadeddata	—
canplay	—
play	—
playing	—
canplaythrough	loaded	video is ready to start playing
—	playing	video is playing, play event missing due to autoplay
progress	—
...	—
progress	—
pause	pause	manual pause
progress	—
seeking	seeking	seeking while paused
ratechange	—	Shaka sets playback rate to 0 to control buffering
play	play	Play requested during a seek
waiting	—
progress	—
progress	—
progress	—
seeked	—
canplay	—
playing	—
canplaythrough	—	video element thinks it can start playing, but playback rate is 0
progress	—
ratechange	seeked	shaka returns playback rate to normal
—	playing	video is playing again after previous pause
progress	—
progress	—
pause	pause
progress	—
play	play
playing	playing
progress	—
progress	—
seeking	seeking	seeking while playing
waiting	—
ratechange	—
progress	—
progress	—
seeked	—
canplay	—
playing	—
progress	—
canplaythrough	—
progress	—
ratechange	seeked	seek finished, video is rolling
progress	—
progress	—
progress	—
progress	—
ratechange	buffering	buffer empty, shaka sets playbackrate to 0
progress	—
progress	—
progress	—
canplaythrough	—	video element thinks it can start playing, but playback rate is 0
progress	—
ratechange	buffered	shaka returns playback rate to normal
progress	—
...	—
progress	—
seeking	seeking
waiting	—
ratechange	—
progress	—
...	—
progress	—
seeked	—
canplay	—
playing	—
canplaythrough	—
progress	—
ratechange	seeked
progress	—
progress	—
progress	—
durationchange	—
progress	—
seeking	seeking	seeking within buffer, no ratechange
waiting	—
seeked	seeked	seek finished
canplay	—
playing	—
canplaythrough	—
pause	pause
ended	ended	end of stream reached
emptied	—

Download it at npm.

Contribute at github.

HTML5 subtitles with dynamic width on OSX

Martin Stark — Thu, 17 Mar 2022 15:28:46 +0000

If you've run into subtitles taking up 100% width of the HTML5 video player window, which is common in Chrome or Safari on OSX, here is a neat styling trick:

::-webkit-media-text-track-display {
  // prevent subtitles from taking up 100% width
  // while remaining centered
  width: auto !important;
  left: 50% !important;
  transform: translateX(-50%);
  // prevent unexpected line breaks, since the  
  // above styling will otherwise force 50% width
  // on the subtitle element
  white-space: pre;
}

This code will center the subtitle element, make sure it keeps a dynamic width, and prevent unexpected line-breaks.

Since the fix maintains native subtitle rendering, it allows for operating system level accessibility options to be applied.

The equivalent of componentWillMount using React hooks

Martin Stark — Thu, 29 Apr 2021 12:29:48 +0000

Given that

the goal is to execute some code once, before the ui is updated
componentWillMount is deprecated (1, 2, 3), and that the suggested replacement is executing code in the constructor
code executed before the return statement of a functional component is implicitly run before rendering it
the rough equivalent of mounting a class component is the initial call of a functional component

The solution would be

Calling a function in the body of the functional component once. This can potentially be achieved with useState, useMemo, or useEffect, depending on the timing required for the use case.

Since the code needs to run before the initial render is committed to the screen, this disqualifies useEffect, as “The function passed to useEffect will run after the render is committed to the screen.” 4.

Since we want to guarantee that the code will only run once, this disqualifies useMemo, as "In the future, React may choose to “forget” some previously memoized values and recalculate them on next render" 5.

useState supports lazy initial state calculations that are guaranteed to only run once during the initial render, which seems like a good candidate for the job.

Example with useState:

const runOnceBeforeRender = () => {};

const Component = () => {
  useState(runOnceBeforeRender);

  return (<></>);
}

As a custom hook:

const runOnceBeforeRender = () => {};

const useBeforeInitialRender = (fn) => {
  useState(fn);
}

const Component = () => {
  useBeforeInitialRender(runOnceBeforeRender);

  return (<></>);
};

The runOnceBeforeRender function can optionally return a state that will be available immediately upon the first render of the function, triggering no re-renders.

See use-once on npm.