What copier latency claims actually measure

A signal copier is a piece of infrastructure that turns a trade signal — a Telegram message, a Discord post, a TradingView alert — into an order at your broker. Latency, in this context, is the time between the signal becoming available and your broker confirming the resulting order. That definition matters, because most of the latency numbers you see in copier marketing describe something much narrower.

This article is not about any specific vendor. It is about how to read a latency claim — any latency claim, including ours — and what an honest measurement has to include.

The chain a signal actually travels

Between a signal provider pressing send and your broker acknowledging an order, there are at least five stages, and every one of them takes real time:

1. Delivery: the message has to reach the copier. For Telegram that means the Telegram API delivering the message to whatever is listening — a step whose timing belongs to Telegram, not to any copier.
2. Parsing: the copier extracts symbol, direction, entry, stop-loss and take-profits from free text, a screenshot, or both.
3. Risk checks and sizing: position size is computed against your risk settings; guards decide whether the trade is allowed at all.
4. Order delivery: the order travels from the copier's infrastructure to your broker's server — across a network, through a session that has to be alive and authenticated.
5. Broker acknowledgement: the broker accepts (or rejects) the order and returns a ticket. Only now does a position exist.

End-to-end latency is the sum of all five. A number that describes only stage two — parsing — can be impressively small and still tell you almost nothing about how fast your order reaches the market.

Internal parsing time: the number that markets itself

Parsing is the stage a vendor controls completely, measures trivially, and optimises easily. It runs on the vendor's own hardware, with no third party involved. So when a landing page quotes a single small milliseconds figure without saying what it covers, it is usually the parsing step — the narrowest slice of the chain.

There is nothing dishonest about measuring parsing time. It becomes misleading only when the number is presented as if it were the whole journey. The delivery hop before parsing and the broker round-trip after it are typically the dominant components of end-to-end time — and they are exactly the parts a parsing-only figure excludes.

Why a single average misleads

The second problem with headline figures is statistical. Latency is a distribution, not a constant. Most executions cluster somewhere reasonable; a minority take much longer — a broker session had to be re-established, a message arrived during a Telegram flood-control window, a network path degraded. An average blends those tails away. The trade that hurts you is precisely the one in the tail.

That is why serious infrastructure reporting uses percentiles. p50 — the median — tells you what a typical execution looks like. p95 tells you what the slowest one-in-twenty looks like. If a vendor publishes both, you can reason about worst realistic cases. If a vendor publishes one unlabeled number, you cannot reason about anything.

What a trustworthy latency page states

• Where the clock starts (signal available) and stops (broker ACK received)
• p50 and p95, not a single unlabeled figure
• The sample size and the measurement window
• The environment: demo or live accounts, which broker types, which regions
• What is excluded, and why — e.g. provider-side delays before the signal exists

How we handle this at PipSync

We publish end-to-end percentiles — signal available to broker ACK — or we publish nothing. Our latency page explains the measurement points, the percentile choice and the exclusions, and its numbers stay blank until the production sample is statistically defensible. We wrote about the benchmark design itself in an earlier engineering post. That policy costs us a marketing number today; it is the only version of the number worth having.

Read the measurement methodology

FAQ

What is a good latency for a signal copier?

There is no single good number, because published figures rarely measure the same thing. A parsing-only figure and an end-to-end figure can differ by an order of magnitude on the same product. Compare only numbers whose start and stop points are defined, prefer p50/p95 percentiles over averages, and treat any unlabeled single figure as marketing rather than measurement.

Why do copier vendors advertise such small millisecond numbers?

Because the easiest stage to measure and optimise is the vendor's own internal parsing step, which excludes message delivery before it and the broker round-trip after it. The excluded stages usually dominate the real end-to-end time a trader experiences.

What is the difference between p50 and p95 latency?

p50 (the median) is the time half of all executions beat — the typical case. p95 is the time 95% of executions beat — a proxy for the bad-but-realistic case. Both together describe the distribution; either alone, and especially a plain average, hides the tail where the damage happens.

Does PipSync publish its own latency numbers?

PipSync publishes end-to-end p50/p95 (signal available to broker acknowledgement) once the production sample is statistically defensible, with the methodology documented on the latency page. Until then the page shows the measurement design and an explicit measuring state instead of numbers.