Quick Answer: Latency is the time it takes for data to travel from one point to another and return, measured in milliseconds. In enterprise networks, it determines how responsive applications feel to users, how reliably real-time services function, and how much of your infrastructure investment translates into actual performance. Unlike bandwidth, it cannot be fixed by purchasing more capacity.
Your team invested in a higher-bandwidth connection, and the applications still feel sluggish. VoIP calls break up mid-sentence. A database query that should return in under a second is taking several. Helpdesk tickets are piling up, and the complaints are coming from senior staff who expect better from the infrastructure they approved budget for.
The problem is probably not bandwidth. Most enterprise networks have sufficient capacity to move data. What is often missing is a network topology and infrastructure placement strategy that keeps data moving efficiently from origin to destination. That gap has a name: latency.
What makes latency particularly frustrating for IT leaders is that it is invisible until it becomes a problem. You cannot see it in a spec sheet the way you can read a bandwidth figure. It depends on physics, routing decisions, hardware configuration, and in some cases whether your traffic is taking an unnecessary detour through another country. This article breaks down what latency is, where it comes from, and what decisions you can make at the infrastructure level to reduce it.
Latency gets referenced constantly in infrastructure conversations, but it is frequently conflated with bandwidth, confused with throughput, or used as a vague synonym for "slowness." Getting the definition precise matters because misdiagnosing a latency problem as a bandwidth problem leads to expensive fixes that do not actually solve anything.
Latency is measured in milliseconds (ms) and is most commonly expressed as Round-Trip Time (RTT): the total time for a data packet to travel from a source to a destination and return. When a ping test returns 25ms, that is an RTT measurement.
According to Azion's network latency reference guide, latency above 100ms is perceptible to users in interactive applications, and anything above 300ms makes an application feel unresponsive.
Alongside average RTT, two additional metrics are critical for any enterprise infrastructure evaluation:
For real-time applications, jitter is often the more revealing metric.
An average RTT of 40ms sounds acceptable until individual measurements are swinging between 5ms and 200ms. For VoIP, video conferencing, or any application that cannot buffer against delivery gaps, that inconsistency causes direct, audible degradation.
Bandwidth is the volume of data a connection can carry per unit of time. Latency is the time a packet takes to travel.
High bandwidth enables high throughput, but high latency can reduce actual throughput well below available bandwidth because protocols like TCP wait for acknowledgements before sending additional data.
A useful way to think about it: bandwidth is the number of lanes on a highway; latency is the speed limit. Adding more lanes does not make cars travel faster.
A 10 Gbps connection with 200ms latency will still feel unresponsive for interactive workloads because every request waits 200 milliseconds for a reply before anything else proceeds. Research confirms this clearly: a web page loads faster on a 10 Mbps connection with 10ms latency than on a 100 Mbps connection with 100ms latency.
Most latency discussions treat "physical distance" as the complete explanation, which is accurate but incomplete. There are four distinct components that together produce the total delay a packet experiences on its journey, and each requires a different mitigation approach.
Propagation latency is the time a signal takes to physically travel from one point to another through a transmission medium, whether fibre optic cable, copper wire, or wireless spectrum.
At its theoretical minimum, light travels through fibre at roughly two-thirds the speed of light in a vacuum. A round trip between Toronto and a data centre in Virginia, a common routing pattern for Canadian traffic that lacks local peering, covers several hundred kilometres and adds latency that no hardware investment can eliminate.
This is the latency floor.
No routing software, no network architecture, and no amount of engineering can make data travel faster than physics allows. The only reliable way to reduce propagation latency is to shorten the physical distance between your infrastructure and the systems it serves.
For Canadian enterprises, this makes the geographic location of your data centre a primary performance variable, not an afterthought.
Transmission latency is the time required to push all the bits of a packet from a sender onto the network link. It is proportional to both packet size and link capacity. A large packet on a low-bandwidth link takes longer to transmit than the same packet on a high-capacity connection, and this is the one component of total latency where bandwidth genuinely plays a role.
Buying more bandwidth here does help, but the context is narrower than most people assume.
In practice, transmission latency on modern enterprise fibre connections is sub-millisecond for standard data packets and is rarely the dominant bottleneck for interactive workloads. It becomes meaningful when large payloads are moving across constrained links: video files, database backups, or large model weights being pushed to an inference server.
Upgrading bandwidth makes sense in those scenarios, but it will not improve the responsiveness of an application whose latency problem lies elsewhere.
Every time a packet passes through a router, switch, or firewall, that device inspects its headers, determines the correct forwarding path, applies any relevant policies, and sends the packet onward. The time that operation takes is processing latency.
On modern hardware with well-configured networks, per-hop processing delay is typically measured in microseconds and is rarely the primary driver of noticeable performance issues on its own.
The challenge is that processing latency accumulates across hops. A packet traversing a multi-hop path passes through many devices, and if any of them are heavily loaded, running outdated firmware, or applying complex inspection rules, the per-hop cost climbs. Deep packet inspection, layered firewall rulesets, and SSL termination all add processing overhead at each point of passage, contributing to total end-to-end delay in ways that a simple bandwidth measurement will never reveal.
Queuing latency occurs when packets arrive at a network device faster than that device can forward them. Rather than moving through, they wait in a buffer until earlier packets clear. Under normal traffic conditions, queuing latency is minimal.
Under congestion, it can spike from near-zero to several hundred milliseconds, overwhelming every other latency component and making the network feel broken even when the underlying infrastructure is perfectly functional.
This is the most variable and operationally damaging source of delay. During peak traffic periods, a network without Quality of Service (QoS) mechanisms treats a VoIP packet with the same priority as a background software update.
For organisations routing production traffic over shared public internet paths rather than dedicated carrier connections, this unpredictability is a persistent risk that does not show up in any single measurement but becomes very visible in user complaints at 9am on a Monday morning.
|
Latency Source |
Root Cause |
Typical Impact |
How to Address It |
|
Propagation |
Physical distance between endpoints |
~1ms per 200km; cannot be eliminated |
Place infrastructure closer to end users and cloud on-ramps |
|
Transmission |
Packet size relative to link capacity |
Sub-millisecond on enterprise fibre; higher on constrained links |
Increase bandwidth only for large-payload workloads |
|
Processing |
Routing decisions, firewall rules, hardware load |
Microseconds per hop; accumulates across many hops |
Reduce hop count; modernise and optimise network hardware |
|
Queuing |
Network congestion and peak traffic volume |
Near-zero to 500ms+ under load |
Implement QoS policies; use direct carrier or cross-connect paths |
Latency tolerance is not a single number, and one of the most common planning mistakes is applying a uniform performance standard across infrastructure that serves fundamentally different workloads.
The latency figure that is perfectly acceptable for scheduled file replication will make a VoIP deployment unusable and produce measurable revenue impact in a financial services environment.
Cisco's QoS documentation for voice over IP confirms the ITU G.114 standard: one-way end-to-end delay should remain below 150ms for high-quality real-time voice traffic, with jitter buffers typically effective only on delay variations below 100ms.
Video conferencing is similarly unforgiving. Networks with under 50ms latency are well-suited to real-time services, while anything above 100ms creates noticeable user experience problems.
For organisations running Microsoft Teams, Zoom, or proprietary unified communications platforms, the quality of the network path between endpoints and the hosting infrastructure is directly audible on every call.
Placing those services in a colocation environment with direct carrier access removes the unpredictable public internet hops that introduce jitter and variable delay, replacing them with a stable, measurable path.
In financial services, latency is a competitive variable with direct revenue consequences. Research referenced by Netrality shows that every 100 milliseconds of additional load time has historically cost major retailers approximately 1% of sales revenue, and for high-frequency trading environments the tolerances are far tighter: execution systems operate in microseconds, and a 500-microsecond disadvantage against a competing firm consistently means lost order flow.
Even outside algorithmic trading, financial applications including payment processing, fraud detection, and real-time portfolio valuation carry strict latency requirements embedded in service-level agreements.
For Canadian financial institutions operating under OSFI guidance, infrastructure decisions affecting application performance carry both operational and regulatory dimensions that make low-latency data centre selection a risk management decision, not purely a performance preference.
AI workloads introduce a category of delay that extends beyond network latency: compute latency. When a model receives a request and generates a response, the time required to process that inference is compute latency, and it is distinct from the network time getting to and from the model.
For applications serving real-time users, such as fraud scoring, recommendation engines, or natural language interfaces, both components contribute to total response time and both need to be addressed.
This means infrastructure location matters on two levels for AI workloads. Placing inference workloads in Canadian AI data centre environments with high-density GPU compute addresses the compute latency side.
Physical proximity to enterprise campuses and cloud on-ramps handles the network side. As AI inference shifts from experimental to operational across enterprise functions, what was once a niche infrastructure requirement is quickly becoming a standard one.
Backup and replication workloads tolerate higher latency than real-time applications, but that tolerance has practical limits tied to recovery objectives. For disaster recovery strategies built around low Recovery Point Objectives (RPOs), replication frequency depends on the available network path between the primary site and the recovery facility.
Higher latency limits how often data can be synchronised, which directly determines how much data is at risk if a failure occurs before the next replication cycle completes.
DRaaS deployments that route replication traffic over the public internet are particularly susceptible to queuing latency during congestion windows. Direct connections between primary and secondary facilities, across a carrier-neutral path within Canada, consistently deliver more predictable replication performance than public internet alternatives.
For organisations with active backup and disaster recovery requirements, latency on the replication path is a resilience metric as much as a performance one.
The most important thing a CIO or VP of Infrastructure can take away from a latency conversation is this: latency is not only a networking problem. It is a placement problem, a routing problem, and an infrastructure procurement problem. The decisions made when selecting a data centre partner have a direct and lasting effect on the latency every user in the organisation experiences every day.
This is where Qu Data Centres enters the picture. Qu operates nine purpose-built, carrier-neutral facilities across five Canadian markets: Toronto, Ottawa, Calgary, Edmonton, and London, Ontario.
With access to 15+ carrier networks and Megaport on-demand cloud on-ramps, Qu gives enterprise teams the flexibility to choose and optimise their network paths rather than inherit a single provider's routing decisions. That routing flexibility translates directly into lower, more predictable latency for the workloads that matter most.
If your team is evaluating its infrastructure footprint with performance in mind, we can help. Book a tour of the Qu facilities to learn more about how you can map your workload requirements to the right connectivity profile.
Because propagation latency is governed by physics and cannot be engineered away, the most reliable way to address it is to shorten the distance between your infrastructure and the users and systems it serves.
For Canadian enterprises with workloads serving staff and customers concentrated in major urban centres, placing those workloads in data centres within those markets reduces the baseline latency every request accumulates before any other factor comes into play.
This is also a long-term planning consideration.
Organisations that consolidate all workloads in a single facility to reduce cost often find that as the user base grows or becomes more geographically dispersed, the set of latency-sensitive use cases grows with it. Building geographic distribution into the infrastructure strategy from the outset is significantly less disruptive than retrofitting it after performance problems begin escalating.
Every router a packet passes through adds processing latency and creates a potential queuing point. Reducing the number of hops between source and destination reduces both the accumulated processing delay and the number of congestion points the packet must survive.
This is one of the core operational advantages of low latency interconnection in a carrier-neutral facility: traffic can reach its destination through fewer, better-optimised paths rather than traversing the full public internet routing table.
Carrier-neutral facilities allow tenants to connect to multiple network providers and route traffic over the path that best meets their performance requirements at any given moment.
A single-carrier facility locks you into that provider's routing policies and peering relationships. If that carrier's path to a critical cloud provider adds unnecessary hops, there is no alternative available without relocating the equipment.
A cross-connect is a direct physical or logical link between two parties within the same data centre. Rather than traffic leaving the facility, traversing the public internet, and returning, a cross-connect keeps that exchange inside the building.
For connections to cloud providers, trading partners, or other tenants in the same facility, this approach reduces latency to single-digit milliseconds because the propagation distance is measured in metres, not hundreds of kilometres.
The operational benefits over public internet routing for latency-sensitive workloads are specific and measurable:
For production workloads where consistent performance is non-negotiable, treating public internet paths as the primary routing option is an infrastructure risk. Interconnection services are specifically designed to address it.
Canada's internet exchange infrastructure is concentrated primarily in Toronto, Montreal, and Vancouver. For organisations in markets without strong local peering, traffic that appears to stay within the province may actually route through a U.S. internet exchange point before returning. This pattern adds latency from the additional physical distance and introduces legal exposure the moment Canadian data touches U.S.-controlled infrastructure.
The Office of the Privacy Commissioner of Canada is clear that organisations remain accountable for personal information transferred outside the country, including for processing purposes, and that this accountability does not disappear because the transfer was incidental or unintended.
Under the U.S. CLOUD Act, data residing on or transiting infrastructure subject to U.S. jurisdiction can be compelled by U.S. authorities regardless of where the data originated. Keeping traffic on Canadian infrastructure and Canadian carrier paths is not only a latency optimisation strategy. It is a data sovereignty risk management measure that becomes harder to ignore every time a cross-border routing dependency is discovered during an audit.
The most common latency problems that Canadian enterprises face are not fundamentally hardware problems. They are placement problems and routing problems. The applications are sound. The bandwidth is adequate. The issue is that infrastructure sits in the wrong location, is connected through a single carrier, and routes traffic through paths that add avoidable milliseconds at every hop.
Qu Data Centres addresses these problems at the infrastructure layer, before any software optimisation or network tuning is applied. Our nine facilities across Toronto, Ottawa, Calgary, Edmonton, and London, Ontario place enterprise workloads physically close to the users and networks they serve, addressing propagation latency at the foundation.
Each facility is carrier-neutral, with access to 15 or more network providers, giving teams the routing flexibility to select the fastest path to cloud providers, partners, and end users rather than defaulting to a single carrier's decisions.
Cross-connects and interconnection services are available across Qu's full solutions portfolio, enabling direct links to cloud on-ramps and co-tenants that keep latency-sensitive traffic off the public internet entirely.
For enterprise teams reviewing their infrastructure footprint with both performance and compliance in mind, book a facility tour to see firsthand how Qu's facilities are built to meet the latency requirements of modern enterprise workloads.
A good latency figure depends on the application. VoIP and video conferencing require one-way delay below 150ms to maintain quality. Interactive web applications generally perform well with RTT under 100ms. Financial services and trading platforms often require sub-millisecond paths for time-critical operations. Backup and replication workloads tolerate higher latency but still require consistency to meet recovery point objectives.
Round-Trip Time (RTT) is the standard way latency is measured in practice. Latency describes the delay a packet experiences on a network path; RTT is the measurement of that delay for a complete round trip from source to destination and back. When a ping test returns 30ms, that figure is the RTT. In most enterprise contexts the terms are used interchangeably, but RTT is the specific measurement produced by diagnostic tools.
Yes, significantly. Latency in the cloud environment affects every interaction between a client and a cloud-hosted service: API calls, authentication requests, database queries, and session handshakes all incur round-trip delay. Applications relying on many sequential requests are particularly affected, as each one waits for the previous response before proceeding. Reducing the network distance to cloud on-ramps through colocation or direct interconnection is the most direct way to improve cloud application responsiveness.
Latency is the average delay a packet experiences. Jitter is the variability of that delay over time. A connection averaging 40ms with 5ms jitter is predictable and well-suited to real-time applications. A connection with the same average but 80ms jitter produces irregular delivery gaps that cause VoIP calls to cut out and video streams to stutter. For real-time workloads, low jitter is often more operationally important than a low average latency figure.
Carrier-neutral data centres allow tenants to connect to multiple network providers within the same facility. This gives organisations the ability to select the carrier with the most direct, lowest-latency path to each destination, rather than accepting one provider's routing decisions. Cross-connects within the same facility also allow direct connections to cloud providers and co-tenants, keeping latency-sensitive traffic off the public internet and reducing both delay and variability.
No. Propagation latency is governed by the speed of light and the physical distance data must travel. It can be minimised but never reduced to zero. The practical goal in enterprise infrastructure design is not zero latency, but latency that is consistent, predictable, and low enough to meet the requirements of the most demanding workloads on the network. Every millisecond removed through better infrastructure placement and routing is a real, measurable performance improvement.
Azion: "What is Latency? | Network Latency Explained" - azion.com/en/learning/performance/what-is-latency/
Netrality: "Network Latency Optimization: How to Improve Connectivity Performance" - netrality.com/blog/network-latency-optimization/
CISCO: "Quality of Service for Voice over IP" - cisco.com/c/en/us/td/docs/ios/solutions_docs/qos_solutions/QoSVoIP/QoSVoIP.html