Application of Mathematics in Real-World Usage · Guide 16 · BTT Mathematics Hub

A connection is labelled 100 megabits per second. A file is two gigabytes. Dividing two by one hundred gives a number, but it does not give a meaningful transfer time until the prefixes and the factor of eight are handled. Even after the conversion is correct, the resulting time may be only an ideal lower bound.

Digital systems make ordinary Mathematics surprisingly important. File sizes are quantities. Bandwidth and throughput are rates. Latency is a delay. Storage is a capacity. Compression changes the amount to be moved, while sharing changes the rate available to each transfer. These objects interact, but they should not be collapsed into one vague idea of speed.

This guide uses original fictional files, connections and measurements. It does not assess a real internet plan, device, school network or service provider. No network testing, scanning, traffic generation or system modification is required. Every exercise can be completed offline using the supplied data. Technical references support the definitions; the numerical scenarios are teaching models, not observed benchmarks.

Start with bits, bytes and prefixes, calculate transfer-time bounds, separate latency from capacity, work through shared transfers and storage models, then attempt the twenty questions.

Bits and bytes are not interchangeable labels

A byte contains eight bits. A data rate of 100 megabits per second is therefore equivalent to 12.5 megabytes per second when both prefixes use decimal powers and the rates describe the same counted data. The uppercase B in MB distinguishes bytes from the bits represented by Mb.

NIST’s binary-prefix reference sets out the distinction between decimal prefixes and binary multiples. In this guide, 1 MB means 1,000,000 bytes, 1 GB means 1,000,000,000 bytes, 1 MiB means 1,048,576 bytes and 1 GiB means 1,073,741,824 bytes.

These are exact unit conversions, not estimates of network performance. They should be resolved before introducing overhead, congestion or timing uncertainty. A unit error can be much larger than the real performance difference being investigated.

A quantity ledger prevents the factor-of-eight mistake

Write a two-gigabyte file as 2,000,000,000 B. Convert it to 16,000,000,000 bits. Write the hypothetical line rate as 100,000,000 bits per second. Dividing bits by bits per second gives seconds: 160 s.

The equivalent byte-rate calculation is 2,000 MB divided by 12.5 MB/s, again 160 s. These two routes provide an independent representation check. If one produces twenty seconds and the other 160, a bit-versus-byte conversion has probably been omitted.

A useful working table has separate entries for file quantity, quantity unit, rate, rate unit and timing boundary. Do not put 2 GB and 100 Mb/s into a calculator as naked numbers. The units carry the route to the answer.

Decimal and binary file sizes produce different times

A 2 GiB file contains 2,147,483,648 bytes, more than a 2 GB file. At the same ideal 100,000,000 bit/s rate, its time is 2,147,483,648 × 8 / 100,000,000 = 171.79869184 seconds.

The approximately 11.80-second difference from 160 seconds is caused by a different file quantity, not a slower network. Comparing results without checking whether GB or GiB was intended can invent a performance problem.

Similarly, a capacity of 500 decimal GB is approximately 465.66 GiB before any other storage allocation is considered. A different displayed number need not mean that bytes disappeared. First reconcile the counting convention; only then investigate actual unavailable or reserved space.

Ideal transfer time is quantity divided by a usable rate

For constant payload rate G in bits per second and payload size S in bytes, transmission time is 8S/G. If G is a maximum rate rather than an achieved sustained payload rate, the result is a lower bound under that capacity assumption, not a guaranteed finish time.

For the fictional 2 GB file, 100 Mb/s gives 160 seconds if every counted bit of capacity carries the desired payload continuously and no additional time is included. If the actual sustained payload rate is 85 Mb/s, the same division gives about 188.24 seconds.

A report should distinguish “at least 160 seconds under the stated maximum” from “about 188 seconds if 85 Mb/s is sustained.” The first is a capacity bound. The second is a conditional prediction. Neither is an observation until a defined transfer has actually been timed.

Capacity, achieved throughput and useful payload rate are different

RFC 5136 distinguishes network capacity and available capacity with attention to the protocol layer and time interval being considered. For our classroom ledger, define useful payload rate as unique application-file bytes successfully delivered divided by the chosen elapsed interval.

That definition deliberately excludes bytes repeated during retries and bytes counted only as protocol overhead. Another measurement may count traffic at a different layer. Two rates cannot be compared fairly unless their counted quantities and intervals are compatible.

A displayed link capacity does not by itself identify the file’s payload rate. The useful next question is not “which number is wrong?” but “what does each number count?” This is the digital version of distinguishing gross production, usable output and rework in a manufacturing ledger.

Overhead must have a stated denominator

Imagine a deliberately simplified transmission unit containing 1,450 bytes of useful content and fifty additional bytes. Payload fraction is 1,450/1,500, or 96.6667%. This is an invented format for arithmetic, not a claim about a particular network protocol.

At a gross rate of 120 Mb/s with no other losses or delays, useful rate would be 120 × 1,450/1,500 = 116 Mb/s. Conversely, carrying 100 MB of useful content would require about 103.448 MB of gross units under the same fixed-fraction approximation.

Fifty bytes is 3.333% of the gross unit but about 3.448% of its payload. Both describe the same overhead with different bases. Therefore “add 3.333% to the payload” is not the exact inverse of “payload is 96.667% of gross.” Division by the payload fraction performs the correct reversal.

Do not charge the same loss twice

Suppose a supplied observation states that 600 MB of unique file data completed in sixty seconds, including all transfer overhead and retries during that interval. The observed useful rate is 10 MB/s, or 80 Mb/s.

If that observed useful rate is used to estimate another similar transfer, applying an additional generic overhead reduction can double-count effects already present in the measurement. Starting from a gross line rate and starting from an observed payload rate are different modelling routes.

Write the adjustment chain explicitly. A factor should transform one defined quantity into another, not merely make the answer look more realistic. When a factor’s basis is unknown, the uncertainty should remain visible rather than becoming a guessed discount.

A path is constrained by its bottleneck

Consider a fictional continuously pipelined path with three compatible link capacities: 1,000 Mb/s, 100 Mb/s and 300 Mb/s. With no other restriction, its sustained capacity cannot exceed the smallest, 100 Mb/s. Adding the three capacities would not describe an end-to-end flow through all three.

The same bytes must pass through each required stage. A faster stage can move ahead temporarily or wait, but it cannot make the slower stage transmit more than its allowed rate. For a long transfer, the bottleneck supplies a useful lower bound on completion time.

If an application instead requires the entire file to be received and stored at one stage before the next begins, the process is sequential and the stage times may add. That is a different scheduling model from ordinary pipelined forwarding. The topology alone does not specify the application’s staging rule.

Latency is a delay, not a data rate

For an illustrative request-response model, assume a fixed fifty-millisecond delay plus transmission of a 2,000-byte response at 100 Mb/s. The response transmission takes 16,000/100,000,000 = 0.00016 second, or 0.16 ms. Total under the simplified additive model is 50.16 ms.

Doubling the rate halves the transmission component to 0.08 ms, but total becomes 50.08 ms, not 25.08 ms. Most of the model’s time sits in the fixed delay. For a very large file, the rate term may instead dominate.

This distinction explains why improving one specification does not guarantee the same improvement in every user-visible task. The calculation is not a diagnosis of a real application. It demonstrates how the dominant term in a function changes with the size of the request.

Round-trip time and one-way delay should not be silently substituted

A round-trip interval includes a journey out and a return according to the measurement definition. A one-way interval measures only one direction. Dividing round-trip time by two assumes a symmetry that may not hold. The model must say whether symmetry is being used.

For a supplied 40 ms round-trip value, a symmetric teaching model would assign 20 ms each way. Without that assumption, many combinations could total 40 ms. The observation alone does not determine each component uniquely.

RFC 6349 discusses round-trip time alongside throughput and window constraints. It is an informational framework, not a promise that one latency measurement determines every transfer’s duration. Our examples use it for the conceptual distinction, not as instructions to test any public network.

Bandwidth multiplied by delay gives an amount of data

In the round-trip bandwidth-delay calculation used in RFC 6349, multiply capacity in bits per second by round-trip time in seconds. For 100 Mb/s and 40 ms, the product is 100,000,000 × 0.040 = 4,000,000 bits, or 500,000 bytes.

The unit is a quantity of data, not another time or speed. It represents the amount corresponding to one round-trip interval at that rate. This provides a bridge between a rate limit and a limit on data in flight.

The physical analogy is a flow occupying a channel during a travel interval. However, the analogy is not a complete description of transport protocols. The arithmetic identifies one necessary scale; actual behaviour depends on additional mechanisms and constraints.

A window constraint can impose another throughput bound

Suppose a simplified steady-state transfer permits at most W bytes outstanding per round trip. The corresponding rate bound is 8W/RTT bits per second. With W = 65,536 B and RTT = 0.040 s, the bound is 13,107,200 bit/s, or 13.1072 Mb/s.

This is below the assumed 100 Mb/s path capacity. A model using only the line rate would miss the more restrictive condition. The usable bound must respect both, so it cannot exceed their minimum.

The RFC’s receive-window discussion gives the underlying relationship. Our constant-window calculation is an illustration, not a recommendation to change system settings. Actual sending windows, congestion control and receiver behaviour can vary, so this one expression is not a universal exact throughput formula.

Two fictional files, 600 MB and 300 MB, begin together on a connection with constant total useful capacity 60 Mb/s. Assume they receive equal shares while both are active, no setup delays and no other traffic. Each initially receives 30 Mb/s.

The smaller file needs 300,000,000 × 8 / 30,000,000 = 80 seconds. During those eighty seconds, the larger file also transfers 300 MB and has 300 MB remaining. It then receives the full 60 Mb/s and needs forty more seconds. The larger finishes at 120 seconds.

A conservation check divides the combined 900 MB by the total useful capacity: 900,000,000 × 8 / 60,000,000 = 120 seconds. This equals the final completion time because the connection is fully used throughout the stipulated model. Assuming both transfers remain at half speed forever would overstate the larger file’s finish time.

The best schedule depends on whose completion time matters

For the same two files, send the smaller first at the full 60 Mb/s. It finishes after forty seconds. The larger then needs eighty seconds and finishes at 120. Average completion time is (40 + 120)/2 = 80 seconds, compared with (80 + 120)/2 = 100 seconds under equal sharing.

The final time to finish both is unchanged. The average time at which a file becomes available is lower. Sending the larger first gives completion times eighty and 120 seconds, whose average is 100. These schedules optimise different notions of service.

This is not a recommendation to impose a scheduling policy on a shared network. Real fairness, priorities and implementation constraints may matter. The mathematical point is that total completion, individual delay and average completion are different objective functions.

A varying rate must be accumulated over time

A hypothetical transfer receives 20 Mb/s for ten seconds and 80 Mb/s for five seconds. Delivered quantity is 20 × 10 + 80 × 5 = 600 megabits, or 75 MB. The time-weighted average rate is 600/15 = 40 Mb/s.

The simple mean of twenty and eighty is fifty, which assigns equal weight to unequal durations. It does not reproduce the delivered quantity over fifteen seconds. The total-data-over-total-time definition is the reliable route.

On a rate-time graph, each constant interval contributes a rectangle of area equal to data transferred. Adding those areas is the same accumulation principle used for electricity and water. With a continuously varying rate, integration is the advanced version of this idea.

An uncompressed image size follows from its representation

Choose a fictional raw image representation with 1,920 × 1,080 pixels, three colour channels per pixel and eight bits per channel, with no header, padding or metadata. Each pixel uses 24 bits, or three bytes. Data size is 1,920 × 1,080 × 3 = 6,220,800 bytes.

That is 6.2208 MB or approximately 5.9326 MiB. The two sizes describe identical data using different unit scales. They are not two different compression results.

A real image file may use a different channel count, bit depth, compression method or container overhead. Pixel dimensions alone therefore do not determine every actual file size. The calculation is exact only because the representation has been specified completely enough for the teaching model.

An audio stream joins sample rate, bit depth and channel count

Assume an uncompressed representation with 48,000 samples per second for each channel, sixteen bits per sample and two channels. The raw data rate is 48,000 × 16 × 2 = 1,536,000 bits per second, or 192,000 bytes per second.

One minute contains 11,520,000 bytes, or 11.52 MB, before any container overhead. Ten minutes contains 115.2 MB. Each multiplier has a different job: time samples, information per sample, channels and duration.

Do not treat the sample frequency itself as a file bitrate. Samples per second becomes bits per second only after the representation of each sample and the number of channels are supplied. The formula also says nothing by itself about perceived quality or whether a particular recording meets its purpose.

Encoded bitrate predicts storage only for a defined stream

Suppose an encoded media stream has a stated total average rate of 4 Mb/s, including all the encoded components being counted, and lasts 600 seconds. Payload size is 4,000,000 × 600 / 8 = 300,000,000 bytes, or 300 MB.

If the four-megabit rate described video alone while audio and other content were additional, those quantities would need to be added. If it were a maximum rather than a whole-duration average, multiplying by time would provide a bound rather than an exact quantity.

The wording around a rate matters as much as the numerical value. Average, maximum, target and observed are not interchangeable descriptions. Reading the label carefully is a mathematical skill.

Usable storage needs a capacity boundary and a rounding rule

A fictional storage allocation has 500 GB of raw capacity. The model reserves 20% and treats the remaining 400 GB as available for files, with no further overhead. Files are exactly 750 MB each. Whole-file capacity is floor(400,000/750) = 533 files.

Those files use 399,750 MB, leaving 250 MB. A 534th file would require 400,500 MB and exceed the available allocation. The floor operation follows the condition that each complete file must fit.

Real storage accounting may include additional filesystem allocation, metadata, snapshots or other uses. The 20% reserve is invented, not a recommended universal allowance. If more overhead is introduced, the earlier maximum must be recalculated rather than retained by habit.

Compression changes quantity but can add processing time

For a model file of 1 GB, suppose a selected representation compresses it to 40% of its original size. At constant useful rate 80 Mb/s, uncompressed transfer time is 100 seconds. Compressed transfer time is forty seconds.

If compression and decompression together take twelve seconds and occur sequentially with transfer, total time is 52 seconds, saving 48. At a much faster 800 Mb/s useful rate, uncompressed transfer takes ten seconds, while compressed transfer plus processing takes sixteen. Compression now loses six seconds under the same sequential model.

The break-even condition is processing time < 8S(1 − r)/G, where S is original bytes and r is compressed-size fraction. This calculation assumes the required output is preserved by the chosen representation. It does not promise a particular compression ratio for arbitrary files or decide whether lossy changes are acceptable.

Retries require a clearly defined probability model

Imagine a toy system that retries a complete fixed-size message whenever an attempt fails. Suppose attempts are independent, each succeeds with probability 0.8, and every attempt transmits the whole message. The expected number of attempts is 1/0.8 = 1.25.

Expected transmitted data is therefore 1.25 times the unique message size. It is not 1.20 times, because a retry can itself fail and require another attempt. The geometric-series calculation accounts for all possible retry counts.

This is not a model of every real transport protocol, which may retransmit smaller units and respond differently to loss. It is a probability exercise showing why the retry rule belongs in the calculation. A measured payload rate that already includes retries should not be adjusted again using this toy factor.

A transfer forecast should show sensitivity to its weakest assumption

Suppose a 2 GB transfer is expected to sustain useful rate between 60 and 90 Mb/s, with a separate setup interval from two to five seconds. Under the stated model, fastest completion is 16,000/90 + 2, approximately 179.78 seconds. Slowest is 16,000/60 + 5, approximately 271.67 seconds.

The range is generated by assumed bounds, not by a statistically validated confidence procedure. It also assumes the rate remains within the chosen range for the transfer and the extreme combinations are possible.

A deadline of four minutes lies inside this range, so the inputs do not guarantee completion before it. Reporting a single midpoint would hide that fact. The appropriate output is a conditional forecast with its boundaries, not an invented assurance.

What a useful measurement report would contain

A supplied record should identify unique payload bytes, elapsed interval, whether setup is included, direction, concurrent activity and the layer at which any other rate is counted. Repeating those labels makes comparisons more reliable than simply reporting a larger or smaller speed number.

For a fictional 600 MB completed in sixty seconds, the observed result is 80 Mb/s of unique payload over that interval. That record does not establish the maximum possible capacity, identify the bottleneck or guarantee the next transfer’s result. Those are additional questions requiring additional evidence.

This guide intentionally stops at analysis of supplied data. It does not instruct readers to generate traffic against networks or systems. The Mathematics can be learned completely through the offline models, while real measurements belong within the relevant owner’s authorised operating procedures.

Practice: twenty digital-quantity questions

Use decimal MB and GB unless MiB or GiB is explicitly written. Assume constant rates and ignore unlisted overhead only where the question defines an ideal model.

Convert 80 Mb/s to MB/s for the same counted data.
How many bytes are in 3 MB and 3 MiB?
Find the ideal time for 500 MB at 100 Mb/s.
Find the ideal time for 2 GB at 100 Mb/s.
Repeat question 4 for 2 GiB.
A line provides 120 Mb/s gross and the stipulated payload fraction is 1,450/1,500. Find useful rate.
A 600 MB unique payload completes in sixty seconds. Find observed useful rate in MB/s and Mb/s.
A compatible pipelined path has capacities 1,000, 100 and 300 Mb/s. Find its bottleneck bound.
A 2,000-byte response is transmitted at 100 Mb/s. Find transmission time in milliseconds.
Add a separate fixed fifty-millisecond delay to question 9.
Find the bandwidth-delay product for 100 Mb/s and 40 ms RTT, in bytes.
Under a constant-window model, find the rate bound for 65,536 bytes per 40 ms round trip.
Files of 600 MB and 300 MB share 60 Mb/s equally until one finishes, then the survivor receives all capacity. Find each finish time.
A rate is 20 Mb/s for ten seconds and 80 Mb/s for five seconds. Find delivered MB and average Mb/s.
A raw 1,000 × 800 image uses three eight-bit channels with no overhead. Find bytes.
A raw two-channel stream has 48,000 samples per second per channel and sixteen bits per sample. Find one-minute MB.
A total encoded stream averages 4 Mb/s for ten minutes. Find MB.
From 400 GB usable capacity, how many complete 750 MB files fit?
A 1 GB file compresses to 40%, with twelve seconds sequential processing time, on an 80 Mb/s useful path. Find total time and saving.
Why should an observed payload rate not automatically receive another generic overhead deduction?

Worked answers and unit checks

10 MB/s. Divide bits per second by eight to obtain bytes per second, keeping decimal prefixes consistent.
3,000,000 B and 3,145,728 B. MB uses 10⁶; MiB uses 2²⁰. The quantities differ.
Forty seconds. Convert 500 MB to 4,000 megabits and divide by 100 megabits per second.
160 seconds. Two decimal GB contains sixteen billion bits. This is ideal under the question’s assumptions.
About 171.80 seconds. Use 2 × 2³⁰ bytes before converting to bits. Do not substitute two decimal billion bytes.
116 Mb/s. Multiply gross rate by the useful fraction. The example excludes other overhead and delays.
10 MB/s or 80 Mb/s. The numerator is unique delivered payload, so this is already a useful-rate measurement.
100 Mb/s. The sustained path cannot exceed its narrowest compatible stage under the stated model.
0.16 ms. Calculate 16,000/100,000,000 seconds and multiply by 1,000.
50.16 ms. The fixed delay dominates this small-response model. Doubling rate would not halve the total.
500,000 bytes. Capacity times 0.040 seconds is four million bits; divide by eight.
13.1072 Mb/s. Calculate 65,536 × 8/0.040. This bound must also respect any smaller path capacity.
The 300 MB file finishes at eighty seconds; the 600 MB file at 120. The survivor’s rate doubles after the smaller file completes.
75 MB and 40 Mb/s. Total is 600 megabits over fifteen seconds. Unequal durations require time weighting.
2,400,000 bytes. There are 800,000 pixels, each using three bytes. Header and padding are explicitly excluded.
11.52 MB. Multiply 48,000 × 16 × 2 × 60 bits, then divide by eight and one million.
300 MB. Ten minutes is 600 seconds; multiply 4 Mb/s by 600 and divide by eight.
533 files. They use 399,750 MB and leave 250 MB. A partial file does not count as another complete file.
Fifty-two seconds total, saving forty-eight. Compression leaves 400 MB, taking forty seconds; add twelve processing seconds. Uncompressed time is 100 seconds.
The observed rate may already include those effects. An additional deduction can double-count losses unless it represents a separate, clearly defined change.

Teaching the distinction between a bound and a prediction

Begin by requiring two equivalent calculations: one in bits and one in bytes. Then change GB to GiB while leaving the rate unchanged. This isolates unit conversion from performance interpretation, making it easier to identify the first wrong step.

Next replace an ideal rate with an observed useful rate and ask which adjustments are still needed. Add a fixed delay, a shared transfer or a processing stage one at a time. The learner should explain why a previously correct total changes rather than simply substitute new numbers into an unexplained formula.

At the advanced level, compare several constraints and identify which is active: path capacity, window allowance, processing time or storage. Ask for a final sentence naming whether the result is an exact calculation within a model, an ideal lower bound, a conditional forecast or a supplied observation. Those distinctions make digital Mathematics useful rather than merely numerically tidy.

Sources and connected applications

Technical reference routes are NIST: Prefixes for Binary Multiples, RFC 5136: Defining Network Capacity and RFC 6349: Framework for TCP Throughput Testing. The RFCs supply terminology and model context; this page is an offline Mathematics lesson, not an operational testing runbook. All files, timing results and capacity scenarios here are hypothetical.

Continue with Manufacturing, Tolerances, Yield and Quality Control for observed versus expected performance; Cooking, Recipes, Scaling, Timing and Unit Conversion for shared production capacity; and Sports, Pace, Scoring, Rankings and Performance Data for rate comparisons. Return to the BTT Mathematics Hub.

Small Group Tutorials

Real-World Mathematics: Data Networks, Storage, Bandwidth and Transfer Time