Data-Rate and Latency Budget Calculation Audit

Data-Rate and Latency Budget Calculation Audit

Ada re-derives this chapter’s own numbers step by step, at full precision

ADA · CALCULATION AUDIT

Data-Rate and Latency Budget Calculation Audit

One thousand vibration sensors streaming 10,000 samples a second at 2 bytes each would push 1.728 TB/day of raw waveform, while a 20-feature summary collapses that to 6.912 GB/day. On the control side, an edge decision totals 25 ms against a cloud path of 235 ms. This audit re-derives both budgets and asks whether the 250× reduction and that 235 ms-versus-50 ms deadline really force the decision to the edge rather than the cloud.

Companion to the chapter Edge Processing for Big Data — every number here comes from that chapter.

— raw vs feature volume, reduction factor, and edge vs cloud latency, ~5 minutes

Edge processing is justified by two calculations: how many bytes the raw stream would cost, and whether the decision path can meet its deadline. Both worked examples in this chapter supply the inputs; I only carry the arithmetic through.

See the relationship before changing it

The figure reads from left to right. The blue card is streaming sensors. The middle card applies this page's rule. The green card is raw data rate. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only streaming sensors, so the numeric fixture does not switch without explanation.

Walk the arrows. Each raw sensor adds the same waveform rate before edge features reduce the stream.

Derive the baseline in four named moves

1. 1

   Name the input. The chapter baseline is 1000 sensors.

2. 2

   Name the relationship. rate = sensors x 10,000 samples/s x 2 bytes / 1,000,000

3. 3

   Substitute with units. 1,000 x 10,000 x 2 / 1,000,000 = 20.0 MB/s

4. 4

   Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change streaming sensors

Try Predict the direction of rate = sensors x 10,000 samples/s x 2 bytes / 1,000,000. Test another streaming sensors, then compare raw data rate.

Streaming sensors

1000 sensors

Chapter baseline

Raw data rate

Observe Each raw sensor adds the same waveform rate before edge features reduce the stream. Reset streaming sensors to 1000 and compare raw data rate.

Explain Each raw sensor adds the same waveform rate before edge features reduce the stream.

Check yourself

What should you do before trusting a moved-control result?

Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.

What does this small model leave out?

Answer: Only streaming sensors moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only streaming sensors. It is not a field prediction.

Try

One thousand vibration sensors streaming 10,000 samples a second at 2 bytes each would push 1.728 TB/day of raw waveform, while a 20 -feature summary collapses that to 6.912 GB/day . Calculate this case.

Observe

This audit re-derives both budgets and asks whether the 250× reduction and that 235 ms -versus- 50 ms deadline really force the decision to the edge rather than the cloud. Check shows this.

Explain

What this means for your design: the 250× reduction is why you forward RMS, peak, and spectral-band features instead of raw waveforms — 6.9 GB/day is a manageable uplink while 1.7 TB/day is not — but keep a short raw window on the gateway so the feature evidence stays auditable. And the latency sumof 235 ms still exceeds the 50 ms deadline, independently forcing inference to the edge. Check confirms it.

Technical boundaries

The “Data-Rate and Latency Budget Calculation Audit” fixes its traffic and timing inputs. It leaves out bursts, feature-computation cost, compression, packet loss, model drift, and the accuracy lost when raw waveforms are discarded.

1. Raw rate is sensors × sample rate × bytes.

One thousand vibration sensors at 10,000 samples/s and 2 bytes each, then multiplied out over a full day:

1,000 × 10,000 × 2 = 20,000,000 B/s = 20 MB/s  →  20 × 86,400 = 1,728,000 MB = 1.728 TB/day

2. Features collapse each sensor-second to a handful of bytes.

Twenty features × 4 bytes = 80 bytes/s per sensor, so the fleet and the reduction factor follow:

1,000 × 80 = 80 KB/s  →  80 × 86,400 = 6.912 GB/day  →  1,728 / 6.912 = 250×

3. Latency is additive along a path.

Sum each stage, then compare against the 50 ms machine-protection deadline:

Design question	Arithmetic shown	Audit result
Raw data rate (sensors × rate × bytes)	1,000 × 10,000 × 2	20 MB/s
Raw daily volume	20 × 86,400	1.728 TB/day
Feature stream rate (1,000 × 80 B/s)	1,000 × 80	80 KB/s
Feature daily volume	80 × 86,400	6.912 GB/day
Reduction factor	1,728 / 6.912	250× smaller
Edge decision latency	12 + 8 + 5	25 ms — meets 50 ms
Cloud decision latency	80 + 45 + 20 + 90	235 ms
Cloud vs 50 ms deadline	235 / 50	4.7× too slow

What this means for your design: the 250× reduction is why you forward RMS, peak, and spectral-band features instead of raw waveforms — 6.9 GB/day is a manageable uplink while 1.7 TB/day is not — but keep a short raw window on the gateway so the feature evidence stays auditable. And the latency sum settles the control question outright: a 50 ms machine-protection action cannot wait on a 235 ms cloud round-trip that is 4.7× over budget, so the edge acts locally and ships the decision, model version, and raw-window pointer upstream for audit and learning.

Every number above is taken from the chapter’s own examples and re-derived step by step.