feat(systems): allow a sub-second monitor_interval - #1052
rutayan-nv wants to merge 1 commit into
Conversation
monitor_interval is the sleep between job-completion polls, so it sets a floor on how long a finished job goes unnoticed. Typed int, that floor was one second. That is far coarser than a fast backend needs. A standalone job backed by an in-process or warm-server surrogate finishes in tens of milliseconds, so a one-second poll dominated its wall clock: measured on a proxy-model DSE run, roughly 2.1 s of a 2.15 s per-trial cost was the poll, against ~25 ms of actual work. There was no way to express anything shorter, and 0 is not the answer -- completion is now checked through a process handle rather than by shelling out, so 0 spins a core without yielding. Widened on the base System and on every subclass that overrides it, plus the slurm_rest_client parameter that receives it, so the type is consistent rather than mixed. time.sleep already accepts a float, so no consumer changes. Purely widening: every existing integer value in a system TOML still validates and behaves identically. Test asserts 0.005 and 0.5 are accepted alongside 1 and 60; the two fractional cases fail when the field is typed int.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: NVIDIA/cloudai/.coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 12 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe PR changes monitor interval declarations from integers to floating-point values across system implementations and Slurm submission. Existing numeric defaults remain unchanged. A standalone system test checks fractional and integer intervals. ChangesMonitor interval support
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Feature Merge Risk: ⚪ Minimal · up to Fractional intervals pass through the inspected polling paths without truncation, and the defaults remain unchanged. No actionable merge risk was identified. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Summary
Job completion can be checked more often than once a second.
flowchart TB subgraph Before["Before: whole seconds only"] direction LR A["a 2 second job finishes"] --> B["up to 1 second spent<br/>waiting to notice"] end subgraph After["After: fractions allowed"] direction LR C["a 2 second job finishes"] --> D["noticed in milliseconds"] end Before ~~~ AfterHow often cloudai checks whether a job has finished could only be set in whole seconds. For trials lasting a couple of seconds, up to a full second of each one was spent waiting to notice it was already done.
monitor_intervalis the sleep between job-completion polls, typedint, so the floor was 1 s. Too coarse for a fast backend: a proxy-model trial finishes in ~25 ms, so the poll was ~2.1 s of a 2.15 s per-trial cost.0is not the answer — completion is a syscall now, so0spins a core. Widened on baseSystemand every subclass that overrides it, plus theslurm_rest_clientparameter.time.sleepalready takes a float.Test Plan
0.005and0.5accepted alongside1and60. Revert the field toint→ the two fractional cases fail and the integers still pass, which is the evidence existing configs are unaffected.ruff,pyrightclean. Full suite 1979 passed, 5 skipped.Additional Notes
No polling logic changed, no defaults changed — slurm/lsf stay 60, standalone/kubernetes stay 1.
Widened everywhere rather than just standalone: a
floatsubclass over anintbase is legal but leaves the base annotation wrong.