diff --git a/introduction/performance.rst b/introduction/performance.rst
index c50c403..63f4ab1 100644
--- a/introduction/performance.rst
+++ b/introduction/performance.rst
@@ -159,8 +159,10 @@ time) you can calculate how many bits fit in the pipe. For example, a
 transcontinental channel with a one-way latency of 50 ms and a bandwidth
 of 45 Mbps is able to hold
 
-.. centered:: 50 × 10\ :sup:`-3` *sec* × 45 × 10\ :sup:`6` *bits/sec* = 2.25
-              × 10\ :sup:`6` *bits*
+.. math::
+
+   50 \times 10^{-3}\ \mathsf{sec} \times 45 \times 10^{6}\ \mathsf{bits/sec}
+   = 2.25 \times 10^{6}\ \mathsf{bits}
 
 or approximately 280 KB of data. In other words, this example channel
 (pipe) holds as many bytes as the memory of a personal computer from the
@@ -262,14 +264,18 @@ Perhaps the best way to understand the relationship between throughput
 and latency is to return to basics. The effective end-to-end throughput
 that can be achieved over a network is given by the simple relationship
 
-.. centered:: Throughput = TransferSize / TransferTime
+.. math::
+
+   \mathsf{Throughput} = \frac{\mathsf{TransferSize}}{\mathsf{TransferTime}}
 
 where TransferTime includes not only the elements of one-way latency
 identified earlier in this section, but also any additional time spent
 requesting or setting up the transfer. Generally, we represent this
 relationship as
 
-.. centered:: TransferTime = RTT + 1/Bandwidth x TransferSize
+.. math::
+
+   \mathsf{TransferTime} = \mathsf{RTT} + \frac{\mathsf{TransferSize}}{\mathsf{Bandwidth}}
 
 We use RTT in this calculation to account for a request message being sent
 across the network and the data being sent back. For example, consider a
@@ -279,7 +285,9 @@ round-trip time of 100 ms. This includes both the transmit time for 1 MB
 (1 / 1 Gbps × 1 MB = 8 ms) and the 100-ms RTT, for a total transfer time
 of 108 ms. This means that the effective throughput will be
 
-.. centered:: 1 MB / 108 ms = 74.1 Mbps
+.. math::
+
+   \frac{1\ \mathsf{MB}}{108\ \mathsf{ms}} = 74.1\ \mathsf{Mbps}
 
 not 1 Gbps. Clearly, transferring a larger amount of data will help
 improve the effective throughput, where in the limit an infinitely
diff --git a/overlay/cdn.rst b/overlay/cdn.rst
index aa605c0..3b0e982 100644
--- a/overlay/cdn.rst
+++ b/overlay/cdn.rst
@@ -207,11 +207,15 @@ Consistent hashing hashes a set of objects
 visualizes a 128-bit ID space as a circle, where we use the algorithm to
 place both objects
 
-.. centered:: *hash(ObjectName) → ObjectID*
+.. math::
+
+   \mathsf{hash}(\mathsf{ObjectName}) \rightarrow \mathsf{ObjectID}
 
 and nodes
 
-.. centered:: *hash(IPAddr) → NodeID*
+.. math::
+
+   \mathsf{hash}(\mathsf{IPAddr}) \rightarrow \mathsf{NodeID}
 
 onto this circle. Since a 128-bit ID space is enormous, it is unlikely
 that an object will hash to exactly the same ID as a server’s IP
diff --git a/reliable/design.rst b/reliable/design.rst
index 7ee8c5b..c761320 100644
--- a/reliable/design.rst
+++ b/reliable/design.rst
@@ -89,7 +89,11 @@ or approximately 8 KB. Since the sender can send only one packet per
 RTT, if we assume a packet size of 1 KB, this implies a maximum
 sending rate of
 
-.. centered:: Bits-Per-Packet / Time-Per-Packet = 1024 x 8 / 0.045 = 182 kbps
+.. math::
+
+   \frac{\mathsf{BitsPerPacket}}{\mathsf{TimePerPacket}}
+   = \frac{1024 \times 8}{0.045}
+   = 182\ \mathsf{kbps}
 
 or about one-eighth of the network’s capacity. We’d like the sender to
 be able to transmit up to eight packets before having to wait for an
diff --git a/stream/coding.rst b/stream/coding.rst
index 8a145b3..c37c269 100644
--- a/stream/coding.rst
+++ b/stream/coding.rst
@@ -43,7 +43,9 @@ networked multimedia, consider the following example. A high-definition
 TV screen has something like 1080 × 1920 pixels, each of which has 24
 bits of color information, so each frame is
 
-.. centered:: 1080 × 1920 × 24 = 50 *Mb*
+.. math::
+
+   1080 \times 1920 \times 24 = 50\ \mathsf{Mb}
 
 If you want to send 24 frames per second, that would be over
 1 Gbps.  That’s more than most Internet users have access to even
diff --git a/stream/transport.rst b/stream/transport.rst
index 9405898..8625b27 100644
--- a/stream/transport.rst
+++ b/stream/transport.rst
@@ -324,9 +324,11 @@ timestamps are relevant. For example, if the sampling interval is
 the first sample in packet n, then the number of sampling instants
 between these two samples is
 
-.. centered:: TimeBetweenPackets / TimePerSample
+.. math::
 
-.. centered:: = (10 × 10\ :sup:`-3`\ ) / (125 × 10\ :sup:`-6`\ ) = 80
+   \frac{\mathsf{TimeBetweenPackets}}{\mathsf{TimePerSample}}
+      &= \frac{10 \times 10^{-3}}{125 \times 10^{-6}} \\
+      &= 80
 
 Assuming the clock granularity is the same as the sampling interval,
 then the timestamp in packet n+1 would be greater than that in packet n
diff --git a/technology/switch.rst b/technology/switch.rst
index b273d10..94b9b2d 100644
--- a/technology/switch.rst
+++ b/technology/switch.rst
@@ -196,11 +196,12 @@ to switch 40 million packets each second. This is sometimes called the
 packets-per-second (pps) rate. If the average packet is 64 bytes, this
 would imply
 
-.. centered:: Throughput = pps x BitsPerPacket
+.. math::
 
-.. centered:: = 40 × 10\ :sup:`6` × 64 × 8
-
-.. centered:: = 2048 × 10\ :sup:`7`
+   \mathsf{Throughput}
+      &= \mathsf{pps} \times \mathsf{BitsPerPacket} \\
+      &= 40 \times 10^{6} \times 64 \times 8 \\
+      &= 2048 \times 10^{7}
 
 That is, a throughput of about 20 Gbps—fast, but substantially below
 the range users are demanding from their switches today. Bear in mind