Delay

How it works#

The Delay holds each entity for the same fixed time and then passes it on. It stands for anything that takes time without being a resource: a network hop, a conveyor, a courier, a fixed lead time between two stages.

Unlike a server, a delay has no capacity limit and nothing waits in front of it. It accepts every entity the moment it arrives, however many are already in flight, and every one of them leaves exactly one latency later. It adds time to the cycle but never creates a queue.

A delay is passive on its input and active on its output: it is fed like a queue, and it pushes onward like a generator. So it can follow a generator, a server or another delay, and hand on to a queue or to another delay — but a server cannot pull from it. To serve what comes out of a delay, put a queue between them.

A delay must have an incoming connection. Its outgoing side is optional: with nothing connected, entities count as completed when their latency is up, so a delay can be the exit from a model. If the queue after it is full, the entity it releases is refused and dropped.

Settings#

Latencyseconds — default 1

How long an entity is held before it is passed on. Every entity waits exactly this long, so a delay models transport or a fixed lead time rather than work that queues.

Latency can be changed while the simulation runs. The latency is constant, not drawn from a distribution, so a delay shifts the cycle time histogram to the right without making it any wider.

Statistics#

• Entities in flight — how many entities the delay held on average over the chart window. By Little's law it settles at the rate entities arrive multiplied by the latency.
• Entity rate — entities passed on and entities dropped per second over time. Drops here mean the queue after the delay was full.