Speed claims for SMS hardware are almost never comparable, because they are measured under different conditions and rarely state which. One figure is measured with a single module transmitting, another with every port active, and a third is a theoretical limit of the module rather than of the pool.
This guide replaces the claim with a method. It sets out the four variables that determine how fast a modem can actually send, how to measure throughput in a way you can repeat and defend, where the queue and thread settings change the answer, and how to recognise the point at which the operator rather than the hardware has become the limit.
What determines the real speed of an SMS modem?
Four variables, and the slowest one governs.
A pool is only as fast as its slowest component, and the component that limits a deployment changes with scale.
Module capability sets the ceiling: how quickly a module can accept a message, transmit it, and report the outcome. Command round-trip time is the latency between the host issuing a command and the module responding, and it becomes the dominant factor in pools with many ports because the host’s serial or USB handling multiplies it. Software queue and threading determines how many sends the host attempts concurrently. Operator behaviour determines how quickly the network accepts and delivers what you submit, and it usually becomes the limit before the hardware does.
The practical consequence is that a throughput figure quoted for a module is not a throughput figure for a pool, and a figure quoted for a pool is not a figure for your deployment. The only comparable number is one measured on the same pool, with the same queue settings, on the same network, at the same time of day.
That is why publishing a test method is more useful than publishing a claim. A method produces a number you can compare against your own baseline, and it makes the difference between a deployment that meets expectations and one that disappoints them visible before the purchase rather than after it.
How do you measure throughput repeatably?
Fix the message set, queue settings and interval.
A measurement is only useful if the conditions are recorded alongside it.
The method has five elements. Define a message set of known length, because message length affects transmission time. Define the submit pattern: how many messages the host attempts at once and how it paces them when a module is busy. Record the start time at the first submission and the end time at the last recorded delivery, not the last submission, because submission and delivery are different events. Record the pool configuration: port count, SIM count, and the mix of generations. And repeat the test at the same hour on at least two days, because network conditions vary by time.
The output is a figure with conditions attached: messages per minute, on this pool, with this queue setting, on this network, at this hour. Where two deployments compare their figures without the conditions, they are not comparing anything.
Where the customer needs a single headline number, the honest form is a range with a stated configuration rather than a peak. The peak is real but it is the figure least likely to be reproduced in production.
How do queue and thread settings change the answer?
They change it, differently at each pool size.
Two settings govern: how many sends the host attempts concurrently and how it behaves when a module is already busy.
Increasing concurrency raises throughput until the point where modules are saturated, after which it adds contention and latency rather than capacity. That point differs by pool size: a small pool reaches saturation with modest concurrency, while a large pool needs more attempts in flight to keep every module occupied. Setting one concurrency value across pools of different sizes guarantees that one of them is misconfigured.
The second setting is the behaviour when a module is busy: whether the host queues, waits, or skips. Skipping loses messages. Waiting creates a queue whose depth grows during a batch and drains afterwards, which affects the delivery time of the last message more than the throughput of the pool. Queuing with a bounded depth and a defined behaviour when the bound is reached is the configuration that produces predictable results.
Measure throughput at two or three concurrency settings rather than one. The curve is more useful than a single point, because it shows where the pool saturates and how steeply performance falls beyond it.
How do you know the operator is the limit?
When submission speeds up but delivery does not.
The signature is a growing gap between the rate the host submits and the rate the network acknowledges.
Three signals indicate an operator-side limit rather than a hardware one. Submission completes quickly while delivery reports lag by an increasing margin. A proportion of messages fail with an error that reflects network handling rather than a module fault. Or throughput is materially different at different times of day on the same pool with the same settings, which points at network conditions rather than at the equipment.
When any of the three appears, the useful response is not to add hardware. Additional ports submitting into a constrained network produce more failures, not more delivered messages. The response is to measure the accepted rate, pace the queue to match it, and treat the accepted rate as the capacity figure for planning purposes.
Operator policies on this type of traffic vary and change, which is why the accepted rate should be re-measured rather than assumed. The signalling standards behind the network side are published as 3GPP specifications, and the numbering that identifies the sender and recipient follows the ITU E.164 numbering plan, but neither determines how a specific operator treats a specific traffic pattern on a specific day.
What does a repeatable test report contain?
Conditions, curve, and the point of saturation.
The report is the artefact that makes a later performance dispute resolvable.
| Field | What to record |
|---|---|
| Pool configuration | Port count, SIM count, module generations present |
| Message set | Length and encoding of the test messages |
| Queue settings | Concurrency, pacing, and behaviour when a module is busy |
| Measurement window | Start at first submission, end at last delivery report |
| Results by concurrency | Throughput at each setting, with the saturation point identified |
| Accepted rate | The rate the network acknowledged, distinct from the rate submitted |
| Conditions | Network, SIM operator, date and hour of the test |
Two fields in that table are routinely omitted and both matter. The accepted rate distinguishes a hardware limit from a network limit, and the conditions make the figure comparable to a later run. Without them, a throughput number is an anecdote.
How should you size a pool from the measurement?
Size from the accepted rate, and add headroom for growth.
Sizing from the submitted rate produces a pool that is ahead of the network and behind the requirement.
The calculation is a division with a margin. Take the messages you must deliver in the peak hour, divide by the accepted rate per port measured on your network, and add headroom for the port that is unavailable while a module re-registers. The result is a port count, which you then compare against the published tiers: the TYH range runs from 8 ports at $113.00 to 64 ports at $579.00, with the 32-port model at $270.00 in between.
Two adjustments are worth making explicitly. Where the deployment must maintain a reserve of numbers for policy reasons, the SIM estate may exceed the port requirement, and the constraint moves to the slot count. And where the peak is brief and predictable, pacing the queue over a longer window can reduce the port count needed, at the cost of delivering the last messages later.
The final step is to record the figure you sized against. When volume grows, the same measurement repeated on the same pool with the same settings tells you whether the change is a genuine increase in requirement or a degradation in conditions, and those two lead to opposite decisions.
Repeat the measurement after any change to the pool, the operator or the software, and keep the earlier result. A throughput figure without a comparison is a number; a throughput figure against your own baseline is a diagnostic that distinguishes a capacity change from a conditions change, and those two lead to opposite decisions.
The signalling behaviour underneath the network side is specified by 3GPP, the numbering that identifies sender and recipient follows ITU Recommendation E.164, and where the traffic is commercial the operational expectations are described by M3AAWG.
Conclusion
Throughput claims for SMS hardware are not comparable unless the conditions travel with them, which is why a method is more useful than a number. Four variables govern real speed, and the one that limits a deployment changes with scale: module capability at small scale, host command handling in the middle, and operator acceptance at large scale. Measuring at two or three concurrency settings produces a curve, and the curve shows where the pool saturates and how steeply it degrades beyond that point.
The number to plan against is the accepted rate rather than the submitted rate, because adding ports to a constrained network produces failures rather than deliveries. Recorded with its conditions, that figure becomes the baseline against which later growth and later incidents are assessed, and it converts a performance conversation into a comparison. The published capacity steps from the TYH 8-port model at $113.00 to the 64-port model at $579.00 give the sizing options; the measurement tells you which one you need.
Measure your accepted rate before sizing the pool. Send your peak-hour delivery requirement, message profile and network to service@telarvo.com, or review the published models on the SMS modem solution pages.
FAQ
How many SMS can a modem send per second?
There is no figure that applies across deployments, because the answer depends on module capability, host command latency, queue settings and network acceptance. The comparable number is one measured on your own pool with your settings and recorded with its conditions. Measure at two or three concurrency levels and plan against the accepted rate rather than the submitted rate.
Why does throughput fall when I increase concurrency?
Because beyond the saturation point, additional concurrent sends add contention rather than capacity. Each module can only transmit one message at a time, so attempts beyond that point wait and add latency. The saturation point differs by pool size, which is why a single concurrency setting copied between differently sized pools leaves one of them misconfigured.
Should throughput be measured on submission or delivery?
Measure both, and size on delivery. Submission completes at the speed the host can issue commands, which says nothing about what the network accepted. The gap between the two is the diagnostic that distinguishes a hardware limit from an operator limit, and it is the figure that predicts whether a batch will complete inside its delivery window.
Can a modem pool be too fast for the network?
It can submit faster than the network accepts, which produces failures rather than delivered messages. When that happens, additional ports make the problem worse. The correct response is to pace the queue to the accepted rate, which preserves delivery, and to treat the accepted rate as the capacity figure for planning rather than the submitted rate.