Our Dilemmic World

We live in a world that insists on being both discrete and continuous. We count apples, yet we measure its weight; digital photos appear smooth, but are made up of pixels. The language of the universe aptly reflects this contrast: discrete structures give us clarity and computation; continuous models provides intuition and calculus. In fact, I believe, this tension is not a bug but a design feature of thinking — it tells stories we would otherwise miss.

This short exposition follows one precise story inside that tension: how modeling time as discrete slots, instead of a continuous flow, produces a small but exact bias in mean waiting time for periodic resources. This little concept of math has real-world consequences. It's a perfect reminder to appreciate the discipline of discrete logic as much as we love the flow of continuous math.

---

The Model

Consider a computer system, such as a server, that cycles between periods of downtime and uptime. A user can only access the server during an uptime period. In our model, a key rule is that each time slot must have a single period of uptime or downtime. Our primary objective is to determine the expected time required for a user to log in. Our modeling choices are straightforward: we can treat the arrival time as a continuous variable or as one of several evenly spaced discrete slots.

Mathematical Set-Up

Let downtime be represented by $D$ and uptime be represented by $U$. Hence the cycle length $T=D+U$.

Part 1 — If time is modeled continuously

If arrival time is continuous, the user needs to wait, only when it happens to arrive during the downtime interval $\left[0, D\right)$ ; the wait equals the remaining downtime until $D$

The best way to treat this is to find the average wait time here. The expected wait under continuous arrivals is the average of $W(t)=D-t$ for $t\in \left[0, D\right)$,normalized by the cycle ($t$, is the time in which the user would be able to access the server):

$$\mathbb{E}[W]_{\text{continuous}}=\frac{1}{T} \int_{0}^{T}(D-t) dt$$

Computing the integral:

$$\boxed{\mathbb{E}[W]_{\text{continuous}}=\frac{D^{2}}{2(D+U)}}$$

Part 2 — If time is modeled discretely

If time is binned into slots of width $\Delta$, , an arrival is equally likely to fall into any slot. If it lands in downtime slot $k$ (counting from the earliest downtime slot), it must wait until the end of that slot sequence; the wait equals the number of remaining downtime slots times $\Delta$

Now the number of bins for both would be, $m_{U}=\frac{U}{\Delta}$ and similarly, $m_{D}=\frac{D}{\Delta}$

The mean wait is the average over $M=m_{U}+m_{D}$ slots is:

$$\mathbb{E}[W]_{\text{discrete}}=\frac{1}{M}\sum_{k=1}^{m_D} (m_D-k+1)\Delta = \frac{\Delta}{M}\times\frac{m_D(m_D+1)}{2}$$

After substituting $m_D=D/\Delta$ and $M=(D+U)/\Delta$,

$$\boxed{\mathbb{E}[W]_{\text{discrete}}=\frac{D^2}{2(D+U)}+\frac{D\Delta}{2(D+U)}}$$

Step 3 — Isolate and interpret the bias

This is the most important step! We now see that we get different results for continuous and discrete time, but now let's understand the gravity of the situation. Usually, when you pay for server uptime, it's up to the user to decide the all aspects of uptime, but to make our model more realistic and useful, let's assume we're only using the server half the time (Yeah, we are cost-cutting!). So for simplicity, we'll just go with $50\text{%}$ of time.

$$\boxed{\text{bias}=\mathbb{E}[W]_{\text{discrete}}-\mathbb{E}[W]_{\text{continuous}}=\frac{D\Delta}{2(D+U)}}$$

As $D=U=X$:

$$\text{bias}=\frac{X\Delta}{4X}=\frac{\Delta}{4}$$

Example!

This literally opens floodgates to various notions.

Let's take the timescale to be $1\text{ min}\equiv 60 \text{ seconds}$. $ U=D=30\text{ seconds}$. If logging granularity is \(\Delta=1\) s, the symmetric bias yields a numerical extra wait of:

$$\text{bias}=\frac{\Delta}{4}=0.25\ \text{s}.$$

The continuous mean is \(X/4=7.5\) s, and the discrete mean becomes \(7.5+0.25=7.75\) s. Thus $1$ second granularity timing adds a quarter-second average wait in this example.

We will discuss it's real life implications ahead.

Step 4 — Isolate and interpret the bias

The discrete expectation equals the continuous expectation plus an additive correction proportional to $\Delta$. The general bias is:

$$\boxed{\text{bias}=\frac{D\Delta}{2(D+U)}}$$

In practice, one should evaluate this against your latency budget: if the bias is a non-negligible fraction of your target latency,one needs refine timestamp resolution or account for the correction in design. Moreover the granularity and the server uptime changes the dynamics.

Step 5 — Riemann-sum intuition (why the correction appears)

At first this may be a bit different, but here lies the bridge which joins the discrete and continuous!

The discrete sum acts as a Riemann approximation to the integral used in the continuous calculation. Rounding/endpoint choices introduce an \(O(\Delta)\) error: arrivals that miss an uptime boundary are bumped to the next slot, adding expected delay. For our triangular waiting function this leading error constant evaluates to the familiar quarter of a slot in the symmetric normalization.

$$\boxed{\displaystyle \frac{1}{T}\sum_{j=1}^{m_D} (j\Delta)\frac{\Delta}{T}\approx \frac{1}{T}\int_0^D (D-t)\,dt + O(\Delta) }$$

The computed \(O(\Delta)\) term equals \(\Delta/4\) in the symmetric setting.

---

Implications & Motivation

Small mathematical additives like the discretization bias \( \frac{D\Delta}{2(D+U)} \) needs engineering judgment, as time scale can set the relevance:

Even small additive biases matter when time scales are small or when events aggregate. Examples across scales:

• Human facing services (seconds): a $0.25$ s extra means wait each time affects perceived responsiveness and hence conversion metrics as persistance of human vision is $0.0625$, 4 times more than the expected time.
• Telemetry (ms–s): small biases accumulate in average and can mislead anomaly detection in complex systems, where there is high jitter and lag.
• High Frequency Trading a.k.a HFT (ms–µs): with \( \Delta = 1m s \), bias per event is \( 0.25m s \); across millions of events such shifts are economically meaningful.
• Real time control loops(ms–µs): sample-time biases can erode stability margins or increase latency beyond acceptable control thresholds.

Note that:

The algebraic bias we derived, \( \displaystyle \text{bias}=\frac{D\Delta}{2(D+U)} \) (simplifying to \( \Delta/4 \) when \(D=U\)), is immediately actionable. If arrivals occur at rate \( \lambda \) (Poisson), the extra waiting-work introduced per unit time is about \( \lambda\cdot(\Delta/4) \) — a compact expression linking event rate, timestamp granularity, and cumulative cost. Changing the server available time will change several aspects.

So we get a, rule of thumb for designing systems: compute the bias from \( \frac{D\Delta}{2(D+U)} \) (or \( \Delta/4 \) for symmetric case) and compare to your system's latency or control tolerances; if the bias is large relative to requirements, reduce \( \Delta \) or explicitly model discrete effects.

To put into perspective a \(1\ \mu\text{s}\) granularity adds \(0.25\ \mu\text{s}\) per event in HFT, and at \(10^6\) events/s aggregates to 0.25 s of waiting per second, which is a significant timescale in HFT. Thus the same small per-event constant can be negligible for web pages yet decisive in HFT, telemetry, or tight control loops.

---

Making the model a bit more realistic

We can also try to add realistic upgrades so one can adopt them incrementally, as the situation demands .

1) Queueing with excess arrivals but finite service capacity — Model using some kind of approximations of real scenarios and study how it affects stability and probability of 'rare and crowded' events. We would keep cyclic schedule but would let arrivals be Poisson(\( \lambda \)) or Bernoulli per slot with \( p\!\approx\!\lambda\Delta \). The expected backlog would be: \( \mathbb{E}[N_D]=\lambda D \). While for stability the requirement is: \( \lambda D < \mu U \) (where capacity \( C=\mu U \), and $\mu$ is the rate).

2) Calculating the load on system — System would receive entry requests during downtime, creating a backlog.The backlog would be cleared at next uptime. Due to extra load, the server can only process certain number of request, till the load is reduced. It can serve at a rate $\mu (t)$ (or capacity $C=\mu (t) U$ ). If $\lambda$, is the rate during $D$, then the stability condition (queue does not grow larger with time) is, $\lambda D=\mu U.$

---

Simulations!

---

Conclusion

So, while the play between the discrete and the continuous shapes everything from math to the world around us, it’s not about choosing one over the other, it’s about appreciating the unique strengths each brings to the table. The next time you weigh an apple after counting it, or stream a song built from a million digital bits, remember: it’s this beautiful tension that helps us piece together a clearer, richer story of how things work. And thank you for reading this far. I hope it wasn’t too much of a continuous effort, and that you found a discrete moment of enjoyment in it.