Калькулятор нагрузки на тик

Что у вас построено

Результат

Коэффициенты и откуда они

измерено — получено регрессией по замерам стенда. выведено — вычислено из журналов сервера арифметикой интервалов. допущение — прямого замера нет, границы заданы из конфигов модов. Данные и скрипт: CSV стенда, fit.py, model.json.

Математика

Нагрузка складывается из независимых статей, все коэффициенты неотрицательны:

ΔM = n_a·c  +  n_c·φ_c·c  +  n_f·φ_f·c  +  n_m·β  +  n_h·κ

ΔM — добавка к времени тика (MSPT), мс
c  — стоимость активного корабля Sable          φ_c, φ_f — доля стоимости для «крейсера» и «заморозки»
β  — стоимость блока механизма Create в простое  κ — стоимость форслоад-чанка

Каждый коэффициент — интервал [lo; hi] со средним mid. Раз все слагаемые монотонны, интервал итога — сумма интервалов: lo = Σ n·lo, hi = Σ n·hi; mid — геометрическое среднее границ (оно же — оценка, если нет данных о форме распределения). Это огибающая, а не статистический доверительный интервал: она заведомо шире, чем при независимых ошибках, зато не обещает лишнего.

Бюджет и запас: тик должен укладываться в B = 50 мс. В дневные часы (14–25 игроков) средний тик на проде 30–38 мс, поэтому запас H = B − M_день ∈ [12; 20] мс; в пик (50+ игроков, TPS ≈ 18) запаса нет. Шкала выше — доля от H = 12 мс.

Как получены коэффициенты

• β (Create). 7 замеров «N блоков → тик» при базе 2,1 мс. МНК через начало координат: β = Σ(n·Δ)/Σ(n²), остаточное СКО s ≈ 0,41 мс, ДИ по t-распределению (df = 6). Ограничение: блоки не подключены к сетям; при свободном члене наклон статистически неотличим от нуля, поэтому β — верхняя граница присутствия, а не цена работы.
• c (корабль). c = s · M / n_акт, где s — доля Rapier3D.step в выборках главного потока (30–35 %), M — средний тик, n_акт = total − frozen из отчётов sable-ship-lod. Два независимых снимка дали интервалы [0,088; 0,201] и [0,172; 0,312]; взято объединение. Это данные Сезона 0: размеры кораблей неизвестны.
• κ (форслоад-чанк). Остаток базы стенда: κ = (M_стенд − M_пуст − 1431·β − 22·c) / 3600 при 0 игроков и 3600 форслоад-чанках. Границы берутся по худшему сочетанию погрешностей.
• φ_c, φ_f. Допущения: у «крейсера» физика считается раз в 3–4 тика (≥ 1/4 стоимости), у «заморозки» — догоняющий тик раз в ≤ 30 (≈ 1/30); верхняя граница — «экономии нет». Замеров нет.

Самопроверки модели (выполняются в fit.py):

Чего калькулятор не знает.

• Зависимость от размера корабля: в данных нет ни одного замера «корабль из N блоков → мс». Ограничение лишь косвенное: у Simulated потолок 64 000 блоков.
• Работающие установки Create, сущности и мобы. Один пример масштаба: 5 «плазменных молний» с дорогим поиском пути стоили ≈ 10 мс — больше, чем тысячи блоков в простое. Фермы с мобами калькулятор не оценивает.
• Игроки и спавн: по профилю это основная нагрузка (тик чанков 24–39 %, спавн 10–17 %), но она привязана к игроку, а не к постройке.
• Стенд — 4 ядра, прод — 16 vCPU; абсолютные миллисекунды на проде отличаются, поэтому в итоге важнее доли, а не миллисекунды.

Как уточнить модель (следующие замеры на стенде, каждый — A/B с чередованием ABBA, как в bench_bots.sh):

1. Корабли 500 / 5 000 / 30 000 / 64 000 блоков × состояния «лежит» / «летит» × число узлов Create на борту → c(B) = c₀ + c₁·B^γ, показатель γ — из регрессии в логарифмах.
2. Припаркованный корабль: тик с N кораблями при игроке рядом и вдали → φ_f, φ_c вместо допущений.
3. Работающие установки Create (дробилки, деплоеры, миксеры) по 10/100/500 штук, с игроком рядом и вдали → β для рабочего режима.