Two Different Levers on Subscription Load

Two Different Levers on Subscription Load

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

foundations
math-foundations
calculation-audit
applications
Ada ADA · CALCULATION AUDIT

Two Different Levers on Subscription Load

The chapter’s OPC-UA historian has 2,000 variables publishing every 100 ms — 20,000 notifications a second — which a 70-90% dead-band cuts to 5,000, while batching turns 24 bytes of overhead per variable into 2.4 bytes. They pull in different directions. This audit separates them to show dead-band and batching are two different levers on subscription load.

Companion to the chapter OPC-UA Standard — every number here comes from that chapter.

See the relationship before changing it

The figure reads from left to right. The blue card is deadband cut. The middle card applies the page rule. The green card is notification rate. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

Deadband cut changes notification rate An input card leads through the rule rate = 20,000 x (1 - cut fraction) to the notification rate result. INPUT PAGE INPUT APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrows. Deadband changes how often values publish. Batching changes overhead instead.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 75 %.

  2. 2

    Name the relationship. rate = 20,000 x (1 - cut fraction)

  3. 3

    Substitute with units. 20,000 x (1 - 0.75) = 5,000 notifications/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 deadband cut

Try Predict the direction of rate = 20,000 x (1 - cut fraction). Test another deadband cut, then compare notification rate.

75 %
Chapter baseline
Notification rate

Observe Deadband changes how often values publish. Batching changes overhead instead. Reset deadband cut to 75 and compare notification rate.

Explain Deadband changes how often values publish. Batching changes overhead instead.

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 deadband cut moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only deadband cut. It is not a field prediction.

TryAt Check derivation, load 2,000 variables, a 100 ms publish interval, and the stated 70-90% dead-band.
ObserveNotifications fall from 20,000 to 5,000 per second, while batching separately changes overhead from 24 to 2.4 bytes per variable.
ExplainDead-band suppresses unchanged values whereas batching amortizes one envelope across many values; the two levers reduce different parts of subscription load.

Ada: The performance section leans on three numbers — a 2,000-variable historian at a 100 ms publishing interval, a dead-band that “reduces notifications by 70-90%,” and batching that turns “24 bytes overhead per variable” into “2.4 bytes each.” They pull in different directions, so let me separate them.

Start with the historian scenario: 2,000 monitored variables, each eligible to publish every 100 ms.

  • Raw notification rate: 2000 / (100 / 1000 s) = 2000 / 0.1 = 20,000 notifications/second.
  • Apply the dead-band at the low end of the stated band, 75%: 20,000 x (1 - 0.75) = 5,000 notifications/second. A 75% cut sits inside the chapter’s 70-90% range, so the claim holds.

Now the framing overhead, which dead-band never touches:

  • One variable per message pays the full 24 bytes of message header.
  • Ten variables sharing one message: 24 / 10 = 2.4 bytes of header each — a saving of 24 - 2.4 = 21.6 bytes per variable.

The design meaning is that dead-band and batching are independent levers, not two names for one saving. Dead-band attacks how often the server sends, cutting 20,000 notifications/second down to 5,000; batching leaves that count alone and attacks the fixed per-item framing cost, from 24 bytes down to 2.4. Only dead-band reduces the number of notifications — so a tuning record that credits batching for a lower notification rate, or dead-band for lower per-message overhead, has attributed each saving to the wrong control.

Technical boundaries
This fixed-factor ledger excludes OPC UA encoding detail, security and session bytes, retransmission, CPU and queue limits, and the real distribution of value changes.

Work the audit first, then check the displayed derivation.

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