Chapter 7 — Probability and statistics
Lesson map
Lesson 07 published. Map, example, EX019.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Random failures"]
N2["Lab — Link failure probabilities"]
N3["7.2 Reading the result"]
N4["7.3 Summarising measurements"]
N5["Percentiles and outliers"]
N6["Uncertainty in small samples"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX019"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Random failures"]
N2["Lab — Link failure probabilities"]
N3["7.2 Reading the result"]
N4["7.3 Summarising measurements"]
N5["Percentiles and outliers"]
N6["Uncertainty in small samples"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX019"]
[Learning outcomes]
|
v
[7.1 Random failures]
|
v
[Lab — Link failure probabilities]
|
v
[7.2 Reading the result]
|
v
[7.3 Summarising measurements]
|
v
[Percentiles and outliers]
|
v
[Uncertainty in small samples]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX019]
Learning outcomes
You will (1) model failures probabilistically; (2) summarise measurements; (3) reason about uncertainty.
7.1 Random failures
Link failures are often modelled as a Poisson process: independent events at an average rate. With six inter-office links each failing about 1.2 times a year, the total rate is 7.2 a year. The model gives the probability of any number of failures, which helps decide how much redundancy and on-call cover are needed.
Hardware such as power supplies and disks fails at random times, but at fairly stable average rates. Modelling failures as random events with a known rate lets engineers estimate how often a device will be unavailable over a year. This turns vague worries into numbers that support choices such as buying a spare switch, adding redundant links, or accepting the risk for a minor office.
Lab — Link failure probabilities
"""Probability of k WAN link failures in a year if failures are Poisson with mean 1.2 per link-year over 6 links (stdlib only)."""
import math
lam = 1.2 * 6
for k in range(0, 13, 2):
print(f"P(failures = {k:2d}) = {math.exp(-lam) * lam**k / math.factorial(k):.4f}")
print(f"P(failures >= 10) = {1 - sum(math.exp(-lam) * lam**k / math.factorial(k) for k in range(10)):.4f}")
Run with python3 lab_poisson.py. Verified output:
P(failures = 0) = 0.0007
P(failures = 2) = 0.0194
P(failures = 4) = 0.0836
P(failures = 6) = 0.1445
P(failures = 8) = 0.1337
P(failures = 10) = 0.0770
P(failures = 12) = 0.0303
P(failures >= 10) = 0.1904
7.2 Reading the result
The most likely yearly counts are around six to eight. The chance of ten or more failures is about 19 percent, not negligible. Kofi concludes that relying on single links for critical services will regularly cause outages, which supports redundant tunnels later.
A model result such as a 0.3 percent chance of two simultaneous failures in a year is an estimate under stated assumptions, not a guarantee. Kofi reports it with those assumptions, notes that failures sharing a cause such as a power cut are not independent, and explains what the number means in practical terms for council staff.
7.3 Summarising measurements
Latency samples are summarised with median and high percentiles rather than mean alone, because a few slow packets matter to users. Kofi reports p95 as well as median.
Measurements such as latency vary, so a single average hides important behaviour. The median shows the typical experience, while a high percentile such as the 95th shows how bad the slow cases get, which is often what users notice. Reporting both, along with the number of samples and the measurement period, lets readers judge whether the summary reflects normal conditions.
Percentiles and outliers
Latency and throughput measurements rarely follow neat distributions. A few very slow samples, from a busy moment or a retransmission, can pull the mean far from typical experience. Kofi reports the median as the typical value and the 95th percentile to describe the slow tail that users notice. He also keeps the maximum, because a single extreme value may reveal a real fault, such as a misconfigured interface. Reporting these three numbers together gives a fair picture without hiding either the typical case or the bad moments.
Uncertainty in small samples
Some of Kofi's measurements come from short tests with a few dozen samples. Estimates from small samples are uncertain, and two tests can differ simply by chance. He therefore reports how many samples each figure is based on and avoids treating small differences as meaningful. Where a decision depends on a measurement, such as whether a firewall meets a latency budget, he repeats the test at a different time of day. Consistent results across repeats give more confidence than one precise-looking number from a single short run.
Worked example
Using the lab, Kofi reports P(failures ≥ 10) ≈ 0.19 to the council.
Synthetic case. Rates are synthetic.
Errors and limits
Poisson assumes independence; storms or shared ducts cause correlated failures.
Exercises
- EX019 — Total rate. What is the combined yearly failure rate for 6 links at 1.2 each? Rubric: 3 = 7.2;; 2 = value;; 1 = vague;; 0 = none.
- EX020 — Tail probability. What is P(≥10 failures) in the lab? Rubric: 3 = 0.1904;; 2 = about 0.19;; 1 = wrong;; 0 = none.
- EX021 — Independence limit. Give one reason link failures may not be independent. Rubric: 3 = shared duct or weather;; 2 = correlation;; 1 = vague;; 0 = none.
Synthesis
Probability models turn failure rates into planning decisions.
Continue studying — chapter 07 of 50
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →