---
name: rosh-vps-cpu-medicoes
description: A VPS tem 8 núcleos e o cliente do jogo come 7 — medir tempos com o cliente aberto lá dá números falsos
metadata:
  type: project
---

A VPS onde corre o emulador (`D:\RoshEmulator`) tem **8 núcleos lógicos**. Medido em
28/08/2026: `Axn.exe` (nosso cliente) consumia **87,7%** dos 8 núcleos e `AMo.exe` (cliente
oficial) mais **19,1%** — fila do processador em 11. Com essa carga, um `time.sleep(48,5 ms)`
erra **+145 ms** na mediana; com a máquina livre erra +0,5 ms.

Consequência: **qualquer tempo medido no nosso servidor com um cliente aberto na VPS está
contaminado.** O laço do mundo acordava a 0,060 s em vez de 0,050, e a cadência do `04 01`
saía entre 0,519 e 0,796 num alvo de 0,600 — que é o que se vê no ecrã como o mob a dar um
arranque e abrandar.

Duas mitigações, ambas aplicadas:
- `entity_sim.afinar_relogio()` põe o processo em HIGH_PRIORITY_CLASS no arranque do mundo
  (medido: só a prioridade Alta limpa também a cauda; AcimaNormal deixa p90 em 0,199).
- **O jogo passou a correr na máquina do utilizador**, não na VPS. O gravador para lá está
  em `D:\RoshEmulator\dist\GravadorAxion\` (hook.dll + injector.exe + GRAVAR.bat).

**Why:** perdeu-se um dia a afinar constantes de movimento (`PASSO_PERSEGUICAO`,
`INTERVALO_PERSEGUICAO`, rajada/pausa) contra medições que estavam esticadas ~20% por falta
de CPU, não por o modelo estar errado.

**How to apply:** antes de aceitar qualquer medição de tempo do nosso lado, confirmar que a
VPS não tinha cliente aberto — `Get-CimInstance Win32_PerfFormattedData_PerfOS_System` e ver
`ProcessorQueueLength` (0 = limpo, >8 = medição inválida). Ver também
[[rosh-emulador-karos]] e [[medir-nao-adivinhar]].

Hipótese que se mediu e era **falsa**: o quantum de 15,6 ms do escalonador do Windows.
`timeBeginPeriod(1)` não mudou nada — com a máquina livre o `sleep` já acerta sozinho.
