Pause-Erased Time (PET)

• Pause-Erased Time (PET) is a time virtualization mechanism that decouples physical time from logical time during pause-based interactive debugging.
• It virtualizes each process’s clock by subtracting accumulated pause durations, thereby preventing debugger-induced delays from triggering premature timeouts and protocol errors.
• PET uses Virtual Deadline Enforcement to re-arm timers accurately after a pause, maintaining sub-5 ms discrepancies and consistent timeout behavior.

Searching arXiv for the primary PET work and closely related pause-based timing papers. Pause-Erased Time (PET) is a time-virtualization mechanism introduced as part of DDB, a source-level interactive debugger for distributed applications. PET makes debugger pauses effectively disappear from the application’s notion of time by decoupling physical time from logical time, so that when a breakpoint stops a distributed system, application-visible clocks and timeout behavior advance as if the pause never happened. In DDB, PET is the component that makes a default pause-the-world debugging model usable for distributed systems, where ordinary debugger pauses would otherwise trigger timeout cascades, retries, leader elections, lease expiry, failure-detector activations, and unrelated recovery behavior (Yan et al., 7 Jul 2026).

1. Distributed-debugging motivation

PET arises from a specific systems problem: interactive debuggers assume that pausing execution is semantically harmless, whereas distributed applications embed timing directly into protocol logic. In this setting, a debugger-induced pause is not merely a delay in human interaction; it is an externally introduced perturbation to heartbeat timers, RPC deadlines, lease intervals, retry windows, transaction timeouts, keepalives, and crash-recovery thresholds. DDB presents PET as “time virtualization via Virtual Deadline Enforcement that decouples physical and logical time, enabling safe debugger pauses without timeout cascades.”

The motivating failure mode is concrete. The reported survey of LogCabin, RAMCloud, and Nu found thresholds as small as 100–500 ms for retry, heartbeat, election, and crash-recovery related timers, including some 250 ms crash-recovery triggers and 50 ms-per-participant transaction timeouts. A human debugging pause of even one second can therefore cause callers to exceed RPC deadlines, retries to amplify load, followers to suspect leaders, leases to appear expired, lock waits and condition-variable timeouts to fire, and the system to enter recovery logic unrelated to the original defect. The qualitative user-study observations likewise note that ordinary GDB pauses in timing-sensitive cases caused RPC timeouts from callers and invalidated cluster state, forcing session restart (Yan et al., 7 Jul 2026).

PET is therefore not a general-purpose virtual clock for simulation. Its purpose is narrower and more operational: preserve the timing semantics that application code expects during pause-based live debugging of a distributed cluster.

2. Virtual-time model

PET virtualizes each process’s clock. A debuggee does not observe raw physical elapsed time directly; instead it observes a pause-erased logical time derived by subtracting accumulated debugger pause duration from the underlying kernel clock. DDB records when a process is paused and resumed, computes the pause duration, and accumulates that duration into a per-process offset.

The formal model defines physical time as $t \in \mathbb{R}_{\ge 0}$, with debugger pauses represented by disjoint half-open intervals

$G_k = [p_k, r_k),$

where $p_k$ is the pause time and $r_k$ the resume time. Let $T(t)$ be the kernel monotonic clock at physical time $t$. For each pause interval, DDB records internal stop and resume timestamps and defines the measured pause duration $\Delta_k$. The cumulative offset at time $t$ is

$O(t) = \sum_{k:\, r_k \le t} \Delta_k.$

The application-visible virtual time is then

$T_v(t) = T(t) - O(t).$

This is the core PET equation: virtual monotonic time equals physical monotonic time minus accumulated measured paused duration. For wall-clock APIs, PET uses the analogous construction

$G_k = [p_k, r_k),$0

where $G_k = [p_k, r_k),$1 is the kernel realtime clock. This preserves ordinary wall-clock slews and NTP jumps while still subtracting debugger pauses. The paper is explicit that monotonicity is guaranteed for monotonic clocks, but not for realtime clocks if the operating system itself steps the wall clock backward.

The abstraction is local, not global. PET “virtualizes each process’s clock,” and the paper further states that it “specifically governs local time reads and localized timeout evaluations, making no attempts to artificially synchronize or warp clocks across divergent system processes.” This suggests a precise semantic boundary: PET hides debugger-induced suspension from each process’s application-visible time, while cluster coherence is obtained operationally because DDB pauses attached processes together by default rather than by maintaining a cluster-wide virtual-time service (Yan et al., 7 Jul 2026).

3. Virtual Deadline Enforcement and API semantics

A simple offset subtraction is insufficient for correct timeout behavior. If a thread is blocked in an absolute timed wait when the debugger pauses the process, changing future get_time results alone does not prevent a false timeout: on resume, the kernel may find that the original physical deadline has already passed and wake the thread immediately. From PET’s perspective, that wakeup is premature because the pause-erased deadline has not yet been reached.

PET addresses this with Virtual Deadline Enforcement. For an absolute wait sleep_until(D_v), where $G_k = [p_k, r_k),$2 is an application-visible virtual deadline, the shim arms the underlying kernel wait with a physical deadline

$G_k = [p_k, r_k),$3

When the thread wakes, the shim recomputes current PET. If

$G_k = [p_k, r_k),$4

the wakeup is premature in virtual time, whether because a debugger pause increased $G_k = [p_k, r_k),$5, because of signal interruption, or because of a spurious wakeup. The shim then re-arms the wait with an updated deadline. Control returns to application code only when

$G_k = [p_k, r_k),$6

Relative sleep is reduced to absolute sleep:

$G_k = [p_k, r_k),$7

The supported PET semantics are organized into three classes:

Semantic class	Description	Examples named in the paper
get_time	Timestamp reads with pause-erased return values	clock_gettime, gettimeofday
sleep_until	Absolute-deadline waits enforced against virtual time	pthread_cond_timedwait, sem_timedwait
sleep	Relative waits reduced to absolute PET deadlines	sleep, nanosleep

Operationally, the shim tracks each active timer’s pause-adjusted deadline; on every return from the underlying libc sleep primitive, it inspects current PET; if PET is still earlier than the adjusted deadline, it re-arms for the remaining duration and blocks again; otherwise it returns. The appendix states this as unconditional return only when the virtual-time condition is satisfied (Yan et al., 7 Jul 2026).

4. Implementation inside DDB

PET is implemented entirely in user space. DDB uses a local shim layer interposed between the process and libc with LD_PRELOAD, intercepting time-related APIs and subtracting the cumulative offset from the underlying kernel or libc time result. This remains transparent even when libc resolves time reads through Linux vDSO, because the shim wraps the libc entry points while libc may still use vDSO internally.

Several concrete runtime components are required. DKnot, the per-process debugger agent, calculates the pause timestamp when the world is stopped, computes accumulated paused duration on resume, and sends the updated offset to the shim layer before execution continues. Timed blocking primitives must be wrapped in addition to ordinary clock reads, because Virtual Deadline Enforcement needs to inspect every timed wakeup and potentially re-arm the wait. No kernel modifications are required.

The prototype targets Linux, primarily x86_64 with experimental aarch64 support, and currently assumes GDB as the underlying debugger. The mechanism is designed for pause-based debugging of semantic logic and state errors, not for concurrency bugs that depend on exact thread interleavings. DDB’s default is to pause all attached processes together, but it also supports granular per-process control while the rest of the cluster remains paused; in that case, the stepped process’s PET advances only during its actual execution windows, while others accumulate larger offsets once resumed (Yan et al., 7 Jul 2026).

5. Correctness properties, measurement slack, and support boundaries

The paper proves two principal invariants for monotonic-clock PET. First, monotonicity: for two get_time calls at $G_k = [p_k, r_k),$8, if

$G_k = [p_k, r_k),$9

then

$p_k$0

The proof relies on the fact that each measured pause duration $p_k$1 is at most the true duration of that pause, so PET never over-subtracts.

Second, timer correctness: timed blocking operations unblock only when their virtual-time condition holds. sleep_until(D_v) returns at the earliest physical time $p_k$2 such that

$p_k$3

and sleep(D) issued at $p_k$4 returns at some $p_k$5 satisfying

$p_k$6

The intended significance is that code written against monotonic or wall-clock deadlines observes behavior equivalent to an execution in which debugger pauses did not occur.

A subtle but important implementation artifact is under-measurement slack. To avoid overestimating pause duration, PET records timestamps strictly inside the actual pause interval. Therefore the measured duration $p_k$7 can be slightly smaller than the true paused duration. The slack is defined as

$p_k$8

If ideal pause erasure is denoted $p_k$9, actual PET satisfies

$r_k$0

Thus PET runs slightly ahead of the ideal pause-erased timeline by cumulative slack. This bounded residual error explains the reported “sub-5 ms time jump” rather than contradicting the model (Yan et al., 7 Jul 2026).

The limitations are equally explicit. PET is strictly intra-cluster: it “cannot virtualize the physical flow of time for external, true-time observers.” External storage services, lock services, API gateways, or any other uninstrumented dependencies still observe real elapsed time and may time out. PET also does not alter kernel global time; it only changes what intercepted APIs return inside the process. Applications that use raw rdtsc, NIC hardware timestamps, direct syscall assembly, or manually resolved vDSO paths outside libc are outside the prototype’s interception scope. A common misconception is therefore that PET provides universal time freezing; in fact it only virtualizes local application-visible time within attached processes.

6. Evaluation, alternatives, and related pause-based notions

PET is evaluated directly in DDB’s “PET Effectiveness” study. Interception overhead is measured by calling common POSIX time APIs one million times with and without the PET shim. The reported nanosecond-scale overheads are gettimeofday 95 ns with PET versus 29 ns without, clock_gettime(REALTIME) 88 ns versus 28 ns, and clock_gettime(MONOTONIC) 89 ns versus 28 ns. The routine that computes and publishes cumulative pause offset before resume takes 1.265 $r_k$1s on average. For effectiveness, a synthetic application with approximately 50 $r_k$2s of work per iteration repeatedly reads timestamps while DDB injects repeated 100 ms pauses and resumes. The application consistently perceives $r_k$3 ms jumps despite 100 ms real pauses, and the paper states that similar sub-5 ms behavior is observed regardless of actual pause duration because PET accumulates and subtracts cumulative pause offset. DDB’s broader end-to-end evaluation reports sub-5 ms time jump under repeated execution pauses, 30 ms median cross-RPC backtrace latency, and 1–5% throughput overhead (Yan et al., 7 Jul 2026).

The paper contrasts PET with several simpler ideas. Ordinary pause-with-GDB fails because it causes timeout cascades and destructive state transitions. Manually extending timeouts is presented as impractical and behavior-changing, since distributed applications use many distinct timeout mechanisms across RPCs, leases, retries, heartbeats, and framework internals. Lower-level cluster freezing alone is also insufficient, because kernel time continues advancing and blocked waits may wake immediately on resume unless deadlines are virtualized and re-armed. PET is further distinguished from static-offset tools such as libfaketime-style mechanisms, discrete-event virtual clocks, chaos-engineering time warps, and rollback-based schemes: PET must support dynamic offset growth every time a live debugger pauses a process.

In the broader pause-oriented literature, the term “pause” appears in substantially different senses. “Think before you speak: Training LLMs With Pause Tokens” studies delayed next-token prediction by inserting explicit <pause> tokens into a decoder-only LLM so that extra hidden-state computation occurs before visible output; the pauses are sequence tokens, not a virtualized time base (Goyal et al., 2023). “Real-Time Generation of Game Video Commentary with Multimodal LLMs: Pause-Aware Decoding Approaches” uses pause-aware scheduling in which the next prediction time is adjusted by estimated utterance duration, $r_k$4, to regulate when commentary is generated, again without defining a pause-erased clock (Afzal et al., 3 Mar 2026). These works are conceptually adjacent in that they treat pauses as computational or scheduling structure, but they do not address the distributed-systems problem PET solves.

A final source of confusion is terminological. In other arXiv contexts, “PET” frequently denotes Positron Emission Tomography rather than Pause-Erased Time. Within DDB, however, PET specifically names per-process time virtualization for interactive distributed debugging. In that setting, its essential contribution is not merely adjusted timestamps, but the combination of virtual clocks with Virtual Deadline Enforcement so that timeouts fire when the application intends, as if no debugger were attached.