Theme
Configuring Transitions and Delays
Every timed transition requires an assigned duration. Configuring a delay involves two critical choices: how long it takes on average and its probability distribution (variability pattern).
Global Time Unit
Jupiter's simulation engine is unit-agnostic: typing 60 does not specify whether that means seconds or minutes. To ensure global consistency, every model defines a single global time unit selected at the top of the right inspector panel:
ms(milliseconds)s(seconds)min(minutes)h(hours)d(days)
Once chosen, this unit appears on every transition property field (e.g., Mean delay (s)) and on simulation chart axes (Time (s)).
Keep a single time unit across the entire model
Mixing seconds in one transition and minutes in another is one of the hardest bugs to spot: the simulation runs cleanly, but results are off by a factor of 60. Select your unit before filling in delays and convert all external measurements to match it.
The Three Supported Distributions
The stochastic simulation engine in Jupiter supports three primary probability distributions:
| Distribution | Characteristics | Recommended use cases | Required inputs |
|---|---|---|---|
| Exponential | High dispersion, memoryless | Random independent request arrivals, unpredictable service | Mean delay |
| Normal | Symmetrical dispersion around mean | Standardized human tasks, automated operations with known variance | Mean delay and Standard deviation |
| Deterministic | Fixed constant duration | Automated robotic cycles, rigid network timeouts | Exact duration |
Other distributions in the UI
The interface lists additional theoretical distributions (such as Erlang, Weibull, Gamma, and Lognormal) for documenting empirical field measurements. However, the calculation engine currently simulates only the three distributions above. If an unsupported distribution is selected, the pre-execution validator will reject the run. Approximate your measurements using Normal or Exponential distributions.
Exponential
The standard choice in queueing theory. Features many short delays and occasional long outliers. It represents the classic conservative assumption for customer and request arrivals.
Normal
Models durations concentrated symmetrically around a known average with controlled dispersion.
Deterministic
Zero variability. The delay is identical on every firing.
Why Variance Matters More than the Average
An average alone does not determine the queue length. Consider four simulations of the exact same system (5-minute average service time, arrivals every 10 minutes):
| Distribution | Mean queue | Server busy | Mean response time |
|---|---|---|---|
| Exponential | 0.50 | 50.0% | 10.0 min |
| Normal (std dev 2) | 0.29 | 50.0% | 7.9 min |
| Normal (std dev 1) | 0.26 | 50.0% | 7.6 min |
| Deterministic | 0.25 | 50.0% | 7.5 min |
Notice that the server utilization is identical at 50% across all four configurations. The worker spends the exact same total time working in every case.
Yet the customer waits 33% longer under exponential variability than under deterministic timing. Variability alone drives up the queue.
Practical Engineering Takeaway
Reducing operational variance improves system performance even without speeding up nominal execution. Standardizing procedures yields lower response times using the same infrastructure.
Rate vs. Mean Delay: The Critical Distinction
When describing how fast a process runs, there are two inverse representations:
| Format | Meaning | Example |
|---|---|---|
| Mean delay | How long a single occurrence lasts | 60 means 60 seconds per item |
| Rate | How many occurrences happen per unit time | 60 means 60 items per second |
The number 60 as a rate is 3,600 times faster than 60 as a mean delay!
In Jupiter, the input field is always Mean Delay
To eliminate confusion, transition property fields in Jupiter accept exclusively mean delay:
- If a task takes 5 minutes, enter
5. - If your data is an arrival rate (e.g., $\lambda = 2$ requests/s), convert it before entering: mean delay is $1 / \lambda = 1 / 2 = 0.5$ seconds.
The cost of confusing rate and delay
Inverting this concept produces no syntax error: the model executes smoothly, displays charts, and produces numbers that are completely wrong.
In a real wildfire monitoring model, a camera designed to capture one frame every 60 seconds was mistakenly entered with 60 treated as a rate. The system ended up simulating 60 frames per second — a workload 3,600 times higher than intended!
How to verify your inputs
- Ask yourself: "How long does a single instance take?" If the answer is "it takes 0.2 seconds", enter
0.2. If the answer is "it happens 5 times per second", the mean delay is $1/5 = 0.2$. - Sanity-check resulting throughput: If your system processes dozens of requests per minute and simulation results show thousands per second, check for rate/delay inversions.
- Use named parameters: Store durations in parameters like
ARRIVAL_DELAY. When sweeping scenarios, check Consider as rate to plot frequency axes while keeping model internals correct.
Next steps
Learn how to enforce conditions and physical capacity in Guards, Inhibitors, and Capacity.