Deck: the same install on microSD holds ~15-20% fewer fps than on internal storage (measured, Steam Deck OLED) #386

New issue

Open

opened 2026-11-14 07:26:47 +00:00 by omgitsgela · 0 comments

omgitsgela commented

2026-11-14 07:26:47 +00:00

Contributor

What happens

The game installed on the Deck's microSD card sustains ~15-20 % fewer fps in the same scene than the identical install on the internal NVMe, with the same build, save, options, and walk protocol. The tell is draw counts: on SD the scene's per-frame draw count sits several times as high (asset requests keep failing to settle and get re-issued), and the log's streaming hitches lengthen. This reads as the "low fps on my Deck" reports to expect once more people install to SD, so it seems worth naming as a known factor and possibly a builder/README hint.

One session, measured (Steam Deck OLED)

Same save slot (KokiriForest_Child), same walk-and-turn protocol through the control bridge (idle 3 samples, then right-stick full-speed turn 4 samples of 3 s, then 20 s forward walk), warm pipeline caches both sides, same wrapper env. The like-for-like pair is the two fabcd2c0 rows: the same build on the same save, one install on internal NVMe (from my earlier A/B sessions, upscaler row at the game's own network), one on microSD (this session; the ini carries no upscaling key so it also defaults to the game's own network). The cf605c85 rows are from this session with FSR 3.1 set (dlss=3, 640x400 -> 1280x800), which on this build runs ~1-2 fps slower than its own network, so they are honest but a slightly different configuration.

install	`fabcd2c0` @ NVMe, game's own network	`fabcd2c0` @ microSD, game's own network	`cf605c85` @ NVMe, FSR 3.1
settled turn	21.2-22.4 fps	17.6-18.6 fps	20.6 fps
after 20 s walk	~21 fps	17.6 fps	20.6 fps
settled idle draws/frame	~500	2,060-2,620	860-1,160

Both fabcd2c0 rows are the same build on the same save slot with the Upscaler row on the game's own network (verified from each run's own log: Auto (this PC) would be: ... the game's own upscaler), only the storage differs. The microSD run's steady draw count at idle is four to five times the NVMe run's - the tell that asset requests are not settling. The cf605c85 row is this session's build with FSR 3.1, shown separately because the upscaler differs.

NVMe vs microSD on this machine, raw storage measurement while nothing else ran:

SD  4K random:  3,241 reads/s = 13.3 MB/s   (the streaming pattern)
SD  sequential: 89.6 MB/s
NVMe 4K random: 204,310 reads/s = 836.9 MB/s

The card is the stock-class SanNano-ish UHS card that ships in most Decks; the game folder is 30-35 GB, ext4, no compression.

What I think it means, as an observation not a diagnosis

The runtime's streaming wants small random reads at a rate the SD bus physically cannot do (63x gap at 4K). Nothing is wrong with the game; the Deck community's standing advice is already "keep games on internal storage when you can", but the builder gives no hint either way, and SD installs are the default for people managing space. Options that exist today: builder note ("internal storage measures ~60x faster for this game's read pattern"), or --romfs split (big romfs files on SD, hot streaming pieces on internal). Whether any runtime-side change could help (bigger readahead for slow media, detected by probing read latency at startup) is beyond what I can tell from outside.

Not known

Whether a fast UHS-II/A2 card changes the picture (this card is stock speed).
How much of the 20 % is re-request churn vs raw read wait; HOS_CHAIN during an SD-session walk would split it, happy to run it.

## What happens The game installed on the Deck's **microSD card** sustains ~15-20 % fewer fps in the same scene than the identical install on the internal NVMe, with the same build, save, options, and walk protocol. The tell is draw counts: on SD the scene's per-frame draw count sits several times as high (asset requests keep failing to settle and get re-issued), and the log's streaming hitches lengthen. This reads as the "low fps on my Deck" reports to expect once more people install to SD, so it seems worth naming as a known factor and possibly a builder/README hint. ## One session, measured (Steam Deck OLED) Same save slot (`KokiriForest_Child`), same walk-and-turn protocol through the control bridge (idle 3 samples, then right-stick full-speed turn 4 samples of 3 s, then 20 s forward walk), warm pipeline caches both sides, same wrapper env. The like-for-like pair is the two **fabcd2c0** rows: the same build on the same save, one install on internal NVMe (from my earlier A/B sessions, upscaler row at the game's own network), one on microSD (this session; the ini carries no upscaling key so it also defaults to the game's own network). The cf605c85 rows are from this session with FSR 3.1 set (`dlss=3`, 640x400 -> 1280x800), which on this build runs ~1-2 fps *slower* than its own network, so they are honest but a slightly different configuration. | install | fabcd2c0 @ NVMe, game's own network | fabcd2c0 @ microSD, game's own network | cf605c85 @ NVMe, FSR 3.1 | |---|---|---|---| | settled turn | 21.2-22.4 fps | 17.6-18.6 fps | 20.6 fps | | after 20 s walk | ~21 fps | 17.6 fps | 20.6 fps | | settled idle draws/frame | ~500 | 2,060-2,620 | 860-1,160 | Both fabcd2c0 rows are the same build on the same save slot with the Upscaler row on the game's own network (verified from each run's own log: `Auto (this PC) would be: ... the game's own upscaler`), only the storage differs. The microSD run's steady draw count at idle is four to five times the NVMe run's - the tell that asset requests are not settling. The cf605c85 row is this session's build with FSR 3.1, shown separately because the upscaler differs. NVMe vs microSD on this machine, raw storage measurement while nothing else ran: ``` SD 4K random: 3,241 reads/s = 13.3 MB/s (the streaming pattern) SD sequential: 89.6 MB/s NVMe 4K random: 204,310 reads/s = 836.9 MB/s ``` The card is the stock-class SanNano-ish UHS card that ships in most Decks; the game folder is 30-35 GB, ext4, no compression. ## What I think it means, as an observation not a diagnosis The runtime's streaming wants small random reads at a rate the SD bus physically cannot do (63x gap at 4K). Nothing is wrong with the game; the Deck community's standing advice is already "keep games on internal storage when you can", but the builder gives no hint either way, and SD installs are the default for people managing space. Options that exist today: builder note ("internal storage measures ~60x faster for this game's read pattern"), or `--romfs` split (big romfs files on SD, hot streaming pieces on internal). Whether any runtime-side change could help (bigger readahead for slow media, detected by probing read latency at startup) is beyond what I can tell from outside. ## Not known - Whether a fast UHS-II/A2 card changes the picture (this card is stock speed). - How much of the 20 % is re-request churn vs raw read wait; `HOS_CHAIN` during an SD-session walk would split it, happy to run it.

omgitsgela referenced this issue

2026-11-14 09:21:56 +00:00

The opening movies stutter: a quarter to a third of their pictures are skipped (RTX 3090, Linux) #73

omgitsgela referenced this issue

2026-11-14 09:39:46 +00:00

Deck: the frame is CPU-bound in the submission path, not GPU-bound (16 fps at 50% internal, GPU-bound wait 0.4 ms) #402