Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.57.7

dummy-smtp-latency

Global

What network latency the fake receiver simulates
in the configuration this is a linedummy-smtp-latency 0inside the block Global
Making the fake look like the real thing

The latency in milliseconds that the fake receiver adds to its replies. The default is zero: the receiver answers instantly.

Zero makes the run unrealistic. A real receiver is on the network: between a command and a reply tens of milliseconds pass, and on an intercontinental route hundreds. All that time the connection is busy — and it is connection occupancy that runs into max-smtp-out and determines real throughput.

With zero latency the node manages to hold several times more conversations on one connection than it can in real life, and the ceiling comes out overstated.

The main trap is that a run with the default gives a pretty and useless figure. It measures the speed of the node itself, not how much it will handle on a network. The difference between zero and a hundred milliseconds on a long conversation is several-fold, and the overstated ceiling then gets built into planning.
What the Hub does. It does not write it: the mechanism is not brought up on the nodes. If it appears, the latency should be taken from fleet telemetry — the Hub knows the real response time for each provider, and substituting that here is more realistic than any round number.
Recommended values

A hundred milliseconds is a reasonable starting point. That is how long an exchange with a receiver in the same part of the world takes.

Two to three hundred — for long routes. If the mailing goes across an ocean, a run with a hundred will still overstate the ceiling.

Zero is kept for only one task — measuring the node itself, detached from the network. It cannot be used for planning.

The reference points of a hundred and two to three hundred milliseconds are ours. From the manual come the default of zero and the unit: milliseconds.
Example configuration
# a receiver in the same part of the world answers roughly like this
dummy-smtp-port 2525
dummy-smtp-latency 100
With zero the same run will show a ceiling several times higher — because the connection frees up instantly, which does not happen on a network.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Running with zero latency

our experience

What it costsThe connection frees up instantly, and the node holds several times more conversations on it than it can on a network. The ceiling comes out overstated, and capacity is then planned by it.
How to spot itThe measured throughput is several times higher than real sending with the same limits.
How to do it rightSet the latency by the providers’ real response time.

Using one latency for all runs

our experience

What it costsProviders respond differently, and a ceiling taken at a hundred milliseconds does not describe the flow to a distant receiver.
How to spot itCalculations add up for some providers and do not for others.
How to do it rightRun separately for the characteristic latency values.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
dummy-smtp-latency <integer>
Values
a number of milliseconds; zero means an instant reply
Default
0 § 3.3.1.57.7
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
A node-level line: it is written at the root of the file, not inside a block. It has no inheritance. It is picked up by pmta reload; it does not affect conversations already in progress.
⇄

Related directives

1 relation

Applies to

A fake receiver inside the node itselfOne of the eight lines configuring the fake receiver: this one makes it look like a remote server rather than a local one. § 3.3.1.57.7

How to check on the node
The value is set in the configuration; the result is visible from the conversation time in the run log:
grep -n dummy-smtp-latency /etc/pmta/config
pmta show status | head -20
Noticeably higher throughput than real sending gives is the usual sign that the latency was left at zero. The Hub does not use this mechanism.
◇

What else to read

3 articles

◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Capacity planning
Neighboring settings of the block Global:log-filelog-auto-rotationlog-rotatedummy-smtp-await-slotdummy-smtp-ipAll 108 directives of the block →