Skip to content

Measuring on the judge itself#

rbx time measures wherever rbx runs, so the straightforward way to get limits for a judge is to run it on that judge's hardware. --runner is the other way: it measures your solutions on the judge park, through the judge's own CLI, and feeds those timings into the same estimation you would get locally.

rbx time -p moj --runner moj

Why measure there#

A time limit is a claim about hardware. Estimate on your laptop and you have a limit that is correct for your laptop — different CPU, different compiler flags, none of the neighbouring load a judge machine carries. The margin you thought you left may not be there.

Measuring on the park removes the guess: the timings are the judge's own, so the limit is derived from the machine that will enforce it.

If what you want is a verdict rather than a limit, reach for rbx run --runner instead. The two commands share everything below.

Timing on MOJ#

MOJ is the only backend today.

You must be logged in to the moj CLI — rbx reuses its session and never handles your credentials.

rbx uploads a throwaway problem of its own, derived from the id recorded in a committed .moj-id, so two setters on the same package reach the same one. It never touches a problem it did not create: a package already bound to a real MOJ problem is refused by name rather than overwritten.

A judge reports less than the local sandbox does. It hands back a verdict, not the bytes your solution wrote, so some of what a local run shows you has no counterpart at all:

  • No memory usage, no .out/.err artifacts, and a verdict code rather than the checker's own message.
  • --runs greater than one, a sanitizer, and interactive (communication) problems are refused by name before anything is uploaded — each would produce a report answering a different question than the one you asked.

rbx refuses whatever it cannot answer honestly on a given backend, rather than quietly reporting less than you asked for.

The two phases, and the two uploads#

MOJ enforces the time limit from inside the package, so the limit rbx is measuring under has to be in what it uploads. The two phases of a run measure under different limits, and therefore need different packages:

  1. Estimating runs the accepted solutions under the estimation cap — one limit for every language.
  2. Checking the upper bound runs the too-slow solutions at the bound the estimate demands of them, which differs per language group.

So a full run uploads twice, and the second upload usually costs a calibration wait as well. Each trip through the language-group picker that changes a limit costs another one.

Finished testruns are cached, so re-running rbx time, or regrouping back onto limits already probed, costs no judge time at all. And --skip-slow stops after the estimate, which is the one-upload path:

rbx time -p moj --runner moj --skip-slow

Each command uploads to a throwaway problem of its own — …-run for rbx run, … and …-slow for the two phases of rbx time — so alternating between the commands never costs a re-upload.