Repository navigation
Windows: the expert load runs 24x slower from Task Scheduler (0.05 vs 1.42 GiB/s); a hint names the cause - #126
Merged
Niko1221 merged 1 commit intoSep 29, 2026
Conversation
The expert-arena load runs at ~0.05 GiB/s (13-14 min to ready) when the serve is started from Task Scheduler with its registration defaults (Priority 7 / Below normal, least-privilege token), versus 1.4-1.5 GiB/s (~35 s) from a terminal or SSH - same binary, args and cache state. - docs/DETAILS.md: measured table + the two registration settings that fix it - src/program/generate.cpp: when load_gib_per_second() < 0.2 GiB/s, print a hint naming this cause under the load line
Owner
|
Thank you @Zauberio - a very clear measurement. Merged into the 0.1.23 branch, with one change: the hint prints on Windows only (on Linux a load that slow is the disk, and the Task Scheduler advice would mislead). It ships with 0.1.23 after our release checks. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The symptom
When the serve is started from Task Scheduler (a common way to have Strata up at logon), the ~40 GB expert
load crawls at ~0.05 GiB/s (13-14 min until
ready). The same binary, same args and same cache statestarted from a terminal or SSH loads at 1.4-1.5 GiB/s (~35 s).
The cause (measured)
The Task Scheduler registration defaults: Priority 7 (Below normal) and no
<RunLevel>(aleast-privilege token). Re-registering the task with
Priority 4+<RunLevel>HighestAvailable</RunLevel>makes the same task-spawned chain run at 1.42 GiB/s (35 s).
Elimination matrix (RTX 5070 Ti, Ryzen 7 9800X3D, NVMe, 64 GB RAM, Swift-1.5 IQ3_XXS, the v0.1.20 engine):
--serve --vision), SSHstart /normal)So it is the launch context - not the disk, the cache state, memory pressure, or the engine's serve/vision
mode. Note the priority class alone did not help (processes verified at Normal, still 0.05 GiB/s), so the
run-level/limited token or the scheduler's I/O treatment is implicated. Both registration settings were
changed together, so the isolated effect of each is not measured. (Possible connection: a limited token
strips
SeLockMemoryPrivilege, which the large-pages path wants - not proven.)This PR
registration settings that restore full speed.
under the
loaded ... GiB at ...line, so users do not blame their disk.Verified: the tree compiles (MSVC + CUDA sm_120, the setup.py recipe), and the hint path was exercised at
runtime - observed printing under the load line (smoke with a temporarily raised threshold; the shipped
threshold is 0.2 GiB/s and the task-context rate measured above is 0.05 GiB/s).