Adaptive simulate_count based on measured simulation duration

[cweniger]

Problem

simulate_count is a static parameter that controls how many samples are generated per simulation round before any are pushed to the buffer. This is a poor fit across different simulator speeds:

• Fast simulators (ms/sample): a small simulate_count means unnecessary Ray overhead on each append_refs call.
• Slow simulators (seconds/sample): a large simulate_count means long delays between buffer updates — e.g. simulate_count=64 with a 10s/sample simulator means 640s between buffer refreshes.

Currently the user must manually tune simulate_count for their simulator, which is non-obvious and easy to get wrong.

Proposed solution

Replace (or supplement) the static simulate_count with a time-budget target (simulate_duration, in seconds). After each round, track an EMA of per-sample simulation time, then derive:

simulate_count = max(1, int(simulate_duration / avg_sample_time))

This makes the buffer update frequency predictable regardless of simulator speed, and removes a confusing tuning knob from users.

Cold start

Start with simulate_count=1 for the first round; let it ramp up after the first measured round.

Config

buffer:
  simulate_duration: 30.0   # target seconds per simulation round (replaces simulate_count)
  simulate_interval: 1.0    # seconds between rounds (unchanged)

simulate_count could be kept as an explicit override for users who want fixed-size rounds.

Relation to simulate_fraction

A further refinement (discussed separately) is simulate_fraction: the fraction of wall time a node spends simulating vs. waiting. This subsumes simulate_duration and simulate_interval into a single parameter but requires per-node tracking and is a larger change.

Notes

• All simulate_count samples are generated before any are pushed to the buffer (see deployed_graph.py L765–797) — this is why large values are harmful for slow simulators.
• The EMA update is cheap (one float per round) and requires no changes to the Ray actor interface.
• Tracking per-node simulation time is already partly possible via the existing timing infrastructure in NodeWrapper.