{"id":44619,"date":"2026-10-26T13:15:23","date_gmt":"2026-10-26T10:15:23","guid":{"rendered":"https:\/\/web-dev.iptp.net\/?p=44619"},"modified":"2026-10-26T13:47:18","modified_gmt":"2026-10-26T10:47:18","slug":"low-latency-trading-infrastructure","status":"publish","type":"post","link":"https:\/\/www.iptp.net\/es_ES\/blog\/low-latency-trading-infrastructure\/","title":{"rendered":"Low-latency Trading Infrastructure: Where Microseconds Come from and Where They Go"},"content":{"rendered":"<p>In electronic trading, low latency is not a single number. A 50 &mu;s round trip can contain dozens of smaller delays. They come from market data processing, application logic, network interface card (NIC) and kernel processing, switching, optical transport and exchange connectivity. On longer routes, physical distance alone can add milliseconds.<\/p><p>That makes trading network latency an engineering problem of allocation as much as optimization. Saving 2 &mu;s in application code may matter far less than removing 20 km from an optical route. It may also matter less than reducing queueing or eliminating an unnecessary network hop. The right question is not simply how fast a system is. It is where its latency budget is being spent.<\/p><p>This article examines the main sources of latency in low-latency trading infrastructure: colocation and cross-connects, switching, kernel bypass, DWDM transport and long-haul fiber. It also looks at which delays can realistically be reduced, which are imposed by physics, and why optimizing the application alone is rarely enough.<\/p><h2>Key takeaways<\/h2><ul>\n<li>Latency is a budget. Every component spends part of it, and not all delays are equally controllable.<\/li>\n<li>At roughly 5 &mu;s per km of fiber, physical route choices often yield larger gains than micro-optimizing code.<\/li>\n<li>A standard OS network stack can add 20&ndash;50 &mu;s per packet. With kernel bypass, round-trip packet processing can drop into the 1&ndash;5 &mu;s range.<\/li>\n<li>Colocation close to the exchange or your counterparty replaces kilometers with meters of fiber. Nasdaq advertises an average round-trip reduction of 2&ndash;5 microseconds.<\/li>\n<li>Consistency matters. A steady 30 &mu;s response is usually preferable to a 20 &mu;s average that spikes to 200 &mu;s.<\/li>\n<\/ul><p><strong>Reading time: 15 minutes<\/strong><\/p><h2>Why trading latency is a budget, not a metric<\/h2><p>Think of trading latency as an engineering budget. Every component in the system spends a portion of the total time budget. For example, if you have a 20 &mu;s budget and shave off 2 &mu;s in the application, you&rsquo;ve spent 10% of the budget. But if you cut 20 km of extra fiber (&asymp;100 &mu;s round-trip cost at ~5 &mu;s\/km), you save far more.<\/p><p>Critically, not all delays are equally controllable. Engineers can reduce software overhead from 30 &mu;s to 3 &mu;s. But they cannot make light travel faster than physics allows. Optimizing one part of the chain has diminishing returns if another part dominates the latency.<\/p><h2>The end-to-end latency budget: where the time goes<\/h2><p><strong>Where does the time actually go?<\/strong> In a simplified round trip from market data to order acknowledgment, latency accumulates across layers of networking and compute. The table below summarizes typical ranges seen in trading environments. These figures are engineering estimates, not guarantees. Actual latency depends on equipment, coding and traffic conditions.<\/p><div class=\"table-responsive\">\n<table class=\"table table-bordered\">\n<thead class=\"\">\n<tr>\n<th scope=\"col\">Stage<\/th>\n<th scope=\"col\">Typical latency<\/th>\n<th scope=\"col\">Why it matters<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Market data deserialization<\/td>\n<td>1&ndash;5 &mu;s<\/td>\n<td>Parsing a binary feed into memory<\/td>\n<\/tr>\n<tr>\n<td>Trading logic<\/td>\n<td>1&ndash;10 &mu;s<\/td>\n<td>Strategy, risk checks, decision making<\/td>\n<\/tr>\n<tr>\n<td>Serialization<\/td>\n<td>0.5&ndash;3 &mu;s<\/td>\n<td>Encoding order into protocol (binary vs FIX)<\/td>\n<\/tr>\n<tr>\n<td>NIC + OS stack<\/td>\n<td>20&ndash;50 &mu;s<\/td>\n<td>Interrupts, context switches, kernel overhead<\/td>\n<\/tr>\n<tr>\n<td>NIC with kernel bypass<\/td>\n<td>1&ndash;5 &mu;s<\/td>\n<td>DPDK\/Onload\/AF_XDP directly to NIC memory<\/td>\n<\/tr>\n<tr>\n<td>Cross-connect (in-DC)<\/td>\n<td>&#8810;1 &mu;s<\/td>\n<td>Short (meter-scale) fiber or copper link<\/td>\n<\/tr>\n<tr>\n<td>Low-latency switch hop<\/td>\n<td>0.5&ndash;2 &mu;s<\/td>\n<td>Cut-through forwarding on a top-of-rack switch<\/td>\n<\/tr>\n<tr>\n<td>Enterprise router hop<\/td>\n<td>5&ndash;30 &mu;s<\/td>\n<td>Full forwarding\/NPU delay in an ISP router<\/td>\n<\/tr>\n<tr>\n<td>DWDM transponder \/ FEC<\/td>\n<td>O(10s &mu;s)<\/td>\n<td>Optical transport equipment (e.g. FEC overhead)<\/td>\n<\/tr>\n<tr>\n<td>Fiber propagation<\/td>\n<td>~5 &mu;s per km<\/td>\n<td>Distance: light speed (~200,000 km\/s in glass)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div><p><strong>Key takeaway:<\/strong> A 2 &mu;s software improvement can be dwarfed by just a few kilometers of extra fiber. At roughly 5 &mu;s per km, physical route choices often yield larger gains than micro-optimizing code.<\/p><h2>Where do microseconds accumulate in a trading system?<\/h2><h3>Application stack: first and last microseconds<\/h3><p>The trading server&rsquo;s own processing is the first point of delay. A typical sequence on the server is:<\/p><ol>\n<li>Receive market data packet (from NIC).<\/li>\n<li>Deserialize binary feed into an in-memory data structure.<\/li>\n<li>Update internal order book and run strategy logic.<\/li>\n<li>Execute risk checks, generate a new order.<\/li>\n<li>Serialize the order into the exchange protocol (often Financial Information eXchange (FIX) or a binary equivalent).<\/li>\n<li>Hand the packet off to the NIC for transmission.<\/li>\n<\/ol><p>Even highly tuned C\/C++ trading engines often take 1&ndash;10 &mu;s for these steps. The dominant costs are usually not math operations, but data movement: memory accesses, cache misses, locking and copying. For example, parsing and populating an in-memory object from a binary format may incur several microseconds. Serializing an order message back into network format adds more. Using lean data structures and in-place buffers is crucial.<\/p><h3>NICs and kernel bypass<\/h3><p>The NIC is the bridge between the server and the network. In a standard Linux stack, a packet traverses interrupts, kernel drivers, socket buffers, scheduler queues and system calls before it finally reaches user-space code. This can easily add 20&ndash;50 &mu;s of latency per packet in an unloaded system.<\/p><p>To cut this overhead, high-frequency trading (HFT) setups use kernel bypass techniques (e.g. DPDK, Solarflare\/OpenOnload, Mellanox VMA, or AF_XDP). These allow the trading application to exchange packets directly with the NIC hardware, bypassing most of the operating system (OS) kernel. With kernel bypass, round-trip packet processing can drop into the 1&ndash;5 &mu;s range. That&rsquo;s why HFT deployments often dedicate CPU cores to busy-loop polling instead of interrupts.<\/p><p>The goal is not just lower latency, but predictable latency. Bypass minimizes variability from OS scheduling. In practice, a modern NIC with a polling driver can deliver sub-microsecond transmission for well-tuned code. A traditional kernel path, by contrast, might jitter tens of microseconds under load.<\/p><h3>Colocation latency: reducing geography, not eliminating latency<\/h3><p>Colocation means housing your own hardware in a specialized, professional data center (with power, cooling, security and connectivity provided) rather than on your own premises. Where that facility sits determines whether it helps with latency. For trading, the benefit comes from choosing a data center close to the exchange&rsquo;s matching engine, or inside the exchange&rsquo;s own facility. That removes the need for long-haul fiber, but it doesn&rsquo;t make all latency vanish. It merely replaces kilometers with meters of fiber.<\/p><p>A colocated server still traverses a series of switches and cables inside the data center:<\/p><ul>\n<li>the server&rsquo;s NIC;<\/li>\n<li>a top-of-rack switch;<\/li>\n<li>possibly one or more aggregation switches;<\/li>\n<li>the exchange access switch; and<\/li>\n<li>the exchange gateway and matching engine.<\/li>\n<\/ul><p>The key difference is that the fiber runs between these switches might be 10&ndash;50 meters instead of 10&ndash;20 kilometers. Even so, that can save several microseconds. For example, Nasdaq advertises that its colocation reduces round-trip latency by an average of 2&ndash;5 microseconds. That&rsquo;s the order of magnitude of intra-facility savings. It is not zero, and it is often worth paying for in sub-100 &mu;s trading.<\/p><h3>Cross-connects: the smallest physical link<\/h3><p>A cross-connect is simply a dedicated cable (fiber or copper) linking two racks or devices in the same data center. Typical examples:<\/p><ul>\n<li>trading server rack to an exchange port;<\/li>\n<li>trading rack to a carrier point of presence (POP); and<\/li>\n<li>server rack to a market data provider feed.<\/li>\n<\/ul><p>The cable itself adds almost no propagation delay (nanoseconds for meters of fiber). Its value is architectural. It creates a direct Layer-1 link without intermediate switching or public Internet hops. This removes one source of unpredictable latency and jitter. In practice, the latency cost of a cross-connect is dominated by the few switches at each end. The fiber run of tens of meters is negligible compared to all other delays.<\/p><h3>Router vs switch latency: forwarding delay per hop<\/h3><p>Not all network devices forward packets equally fast. A specialized low-latency switch (often used in trading networks) might take well under 1 &mu;s to forward a frame (cut-through switching). Standard merchant switches might add 1&ndash;5 &mu;s per hop.<\/p><p>By contrast, an enterprise-grade IP router or firewall doing deep inspection can introduce tens of microseconds. The table below illustrates this:<\/p><div class=\"table-responsive\">\n<table class=\"table table-bordered\">\n<thead class=\"\">\n<tr>\n<th scope=\"col\">Device<\/th>\n<th scope=\"col\">Typical delay<\/th>\n<th scope=\"col\">Function<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Low-latency switch<\/td>\n<td>0.1&ndash;1 &mu;s<\/td>\n<td>Cut-through Layer-2 forwarding<\/td>\n<\/tr>\n<tr>\n<td>Trading aggregation switch<\/td>\n<td>~1&ndash;3 &mu;s<\/td>\n<td>Deterministic switching, some packet handling<\/td>\n<\/tr>\n<tr>\n<td>Core MPLS router<\/td>\n<td>~5&ndash;30 &mu;s<\/td>\n<td>Label switching, packet routing<\/td>\n<\/tr>\n<tr>\n<td>Security appliance<\/td>\n<td>~10&ndash;50 &mu;s (or more)<\/td>\n<td>Firewall, DDoS inspection<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div><p>Minimizing unnecessary hops and choosing cut-through hardware for trading traffic can save microseconds. Conversely, throwing more bandwidth at a problem doesn&rsquo;t reduce per-packet latency. It simply processes more packets per second, not faster.<\/p><h2>Optical transport: where distance dictates delay<\/h2><p>Once packets leave the colocation facility, distance takes over.<\/p><h3>Fiber propagation is the dominant constraint<\/h3><p>Light in fiber travels around <strong>200,000 km\/s<\/strong>, so roughly:<\/p><ul>\n<li><strong>5 &mu;s<\/strong> per kilometer (one-way);<\/li>\n<li><strong>500 &mu;s<\/strong> per 100 km; and<\/li>\n<li><strong>5 ms<\/strong> per 1,000 km.<\/li>\n<\/ul><p>For example, New York to London is about 5,500 km along a subsea path. So even at the speed of light it&rsquo;s tens of milliseconds one-way. No amount of local optimization will beat this. Route planning, meaning choosing the shortest physical path, is the biggest lever. (Microwave links shave roughly 30% off fiber delay by going faster than light in glass, but they have other limitations.)<\/p><h2>DWDM latency: fast transport with measurable overhead<\/h2><p>Most long-haul links use Dense Wavelength Division Multiplexing (DWDM) to carry multiple channels over one fiber. The optical amplifiers and reconfigurable optical add-drop multiplexers (ROADMs) in a DWDM path add minimal delay (often nanoseconds). The main added delay comes from the transponders and muxponders that generate wavelengths and apply Forward Error Correction (FEC).<\/p><p>Depending on technology, each transponder (especially at 100G+ with FEC) can add on the order of tens of microseconds of latency. For example, a modern 100G optical module might introduce 10&ndash;30 &mu;s one-way. Over multiple hops or older gear, this can accumulate into hundreds of microseconds on a long path. Thus, path length (in kilometers) is the baseline latency, and equipment FEC adds a small additional overhead.<\/p><h2>Why distance still matters despite faster hardware<\/h2><p>Engineers often squeeze application latency from, say, 8 &mu;s down to 3 &mu;s. That&rsquo;s a win. But consider what else could be done with those saved microseconds.<\/p><p>In practice, path engineering typically yields larger gains than micro-optimizing an already fast application. This is why firms invest in:<\/p><ul>\n<li>carrier-neutral colocation close to the relevant exchange (meters vs miles of fiber);<\/li>\n<li>shortest-path optical routes (e.g. direct transatlantic cables, microwave);<\/li>\n<li>private circuits (EPL, WDM) with fixed routes versus best-effort Internet; and<\/li>\n<li>Multiprotocol Label Switching (MPLS) networks with quality of service (QoS) and traffic engineering to avoid congestion.<\/li>\n<\/ul><p>Simply put, the network sets the ultimate physics limit. Optimizing only code is like tuning a race car engine to 10 hp when the road is clogged. Sometimes rerouting wins bigger time savings.<\/p><h2>Jitter vs latency: consistency often matters more than speed<\/h2><p>Latency is often quoted as an average or best-case number. In trading, jitter, the variability of latency, can be more critical. A trading system with a very consistent 30 &mu;s response is usually preferable to one that averages 20 &mu;s but occasionally spikes to 200 &mu;s.<\/p><p>Jitter arises from buffering, scheduling and dynamic routing. For example, even an MPLS link may queue packets under bursty load, adding microseconds of delay. A shared Internet path can see latency vary by orders of magnitude during congestion.<\/p><p>Low-latency trading networks mitigate jitter by dedicating bandwidth, enforcing QoS and using fixed paths. The goal is deterministic behavior. If your algorithm assumes a 50 &mu;s round trip, sudden 50 ms spikes (as sometimes seen on the public Internet) would render predictions useless. In practice, architects trade off raw lowest possible latency for stability.<\/p><h2>TCP, UDP and serialization: protocol choices matter<\/h2><p><strong>UDP vs TCP. <\/strong>Market data feeds are latency-critical and often sent over UDP multicast. UDP has minimal overhead (no handshake, no ACK) and supports one-to-many distribution. It&rsquo;s common for exchanges to push data via UDP, counting on protocols above the network to handle packet loss.<\/p><p>Order entry is more often on TCP or specialized transport (like a sequencing engine). TCP guarantees delivery and ordering via acknowledgments. This adds some latency overhead (e.g. the initial SYN\/ACK handshake, windowing delays). In HFT, even the small extra round trips of TCP can matter, but correctness often trumps the microsecond cost.<\/p><p><strong>Serialization overhead.<\/strong> Converting an order into bytes (&ldquo;serialization&rdquo;) can itself take microseconds, especially if you use verbose formats. For example, FIX is text-based and slower to parse than a compact binary feed. Modern trading stacks favor fixed-length binary frames or even hardware-assisted parsing to eliminate this cost. Optimizations include zero-copy buffers, memory-aligned structures and fixed schemas. In general, any per-message CPU work (parsing, copying, context-switching) adds to latency. The fastest systems minimize per-packet work in software.<\/p><h2>Common misconceptions about trading latency<\/h2><ul>\n<li><strong>&ldquo;More bandwidth means lower latency.&rdquo;<\/strong> Not directly. Upgrading a link (e.g. 10G &rarr; 100G) reduces serialization time (1.2 &mu;s &rarr; 0.12 &mu;s for a full frame), but it does not reduce propagation delay or queuing delay. If two locations are connected by a long fiber, the time to travel that fiber (~5 &mu;s\/km) is unchanged by bandwidth.<\/li>\n<li><strong>&ldquo;Colocation eliminates latency.&rdquo;<\/strong> Only when the facility is close to the exchange&rsquo;s own infrastructure, and even then it removes distance, not all delay. Colocating in a data center far from the relevant exchange gives you none of that benefit. In an exchange-proximate facility, colocation cuts the fiber path from kilometers to meters. But even adjacent racks still have switches and links between them, and processing delays (NIC, switch, exchange gateway) remain. Typically, colocation gains are a few microseconds (as Nasdaq advertises, ~2&ndash;5 &mu;s improvement).<\/li>\n<li><strong>&ldquo;MPLS is slower than the Internet.&rdquo;<\/strong> This is a misunderstanding. MPLS is a transport mechanism, not a bandwidth measure. A well-engineered MPLS network can provide deterministic, low-latency paths with QoS priority. The public Internet (best-effort IP) can have more variable routes and contention. In practice, MPLS often reduces effective latency variation, whereas Internet routes might spike unpredictably (even tens of milliseconds under load).<\/li>\n<li><strong>&ldquo;The application is always the bottleneck.&rdquo;<\/strong> Not necessarily. If the trading code is already sub-10 &mu;s, the network or distance can dominate. In many high-frequency setups, the limiting factors are distance (propagation) and queuing, not CPU. Focusing only on code misses the biggest sources of latency: the fiber path and switching fabric.<\/li>\n<\/ul><h2>Where IPTP Networks fits in the latency budget<\/h2><p>IPTP Networks is not an exchange, a broker, or an HFT firm. It&rsquo;s a connectivity and infrastructure provider. The company&rsquo;s strengths lie in the network and infrastructure layers where latency accumulates. For example:<\/p><ul>\n<li><strong>Global backbone:<\/strong> IPTP operates a privately-owned international IP backbone with over 240 points of presence worldwide [<a href=\"#Sources\">1<\/a>]. This means it can select short routes (even non-public ones) between major hubs.<\/li>\n<li><strong>Optimized routes:<\/strong> IPTP markets &ldquo;low latency routes&rdquo; on short fiber paths [<a href=\"#Sources\">2<\/a>], and even shorter routes can be arranged on request. For instance, its BestPath tool shows NYSE&harr;LSE at about 32.5 ms one-way over the FLAG-1 submarine cable, compared to 40&ndash;60 ms typical via public Internet [<a href=\"#Sources\">3<\/a>][<a href=\"#Sources\">4<\/a>].<\/li>\n<li><strong>Carrier-neutral colocation:<\/strong> IPTP operates in carrier-neutral data centers such as Equinix, Digital Realty, MEGA-i in New York, London, Hong Kong, Tokyo, Singapore, Amsterdam. These facilities offer proximity and interconnection to major exchanges&rsquo; infrastructure. Being carrier-neutral lets clients choose the connectivity option and provider that best fits their setup. This helps keep in-building delay low and gives access to many service providers on site.<\/li>\n<li><strong>Deterministic connectivity:<\/strong>IPTP offers MPLS and dedicated circuits (E-Line\/EPL\/WDM) so that paths are fixed and QoS can be applied. This avoids the jitter and reroutes of public Internet transit.<\/li>\n<li><strong>Managed services:<\/strong> IPTP provides support like remote hands, monitoring, and SLAs. These services help reduce the risk of unexpected latency hikes.<\/li>\n<\/ul><p>IPTP&rsquo;s role here rests on verifiable facts. It operates its own backbone with over 240 points of presence and is present in carrier-neutral data centers such as those listed above. IPTP does not claim to improve exchange matching or trading algorithms. What it can say is that it connects the same sites on shorter paths, with route latency you can check, such as about 32.5 ms one-way for NYSE&harr;LSE. Those are verifiable benefits of infrastructure, not marketing hype.<\/p><h2>Conclusion: optimize trading latency end to end<\/h2><p>Low-latency trading isn&rsquo;t solved in software alone. Each packet experiences delay at multiple stages: serialization, NIC\/OS, switches, transport gear, fiber and exchange processing. Some of these delays (like server code) can be shrunk with engineering, while others (like the speed of light) cannot.<\/p><p>The most competitive trading systems address all layers:<\/p><ul>\n<li>efficient application code and kernel bypass to minimize server processing;<\/li>\n<li>colocation in the data center closest to the relevant exchange, to cut distance;<\/li>\n<li>direct cross-connects and low-latency switches to shave microseconds;<\/li>\n<li>shortest-path optical routes (and even alternative carriers like microwave) for long-haul links; and<\/li>\n<li>MPLS\/QoS for predictable forwarding without Internet congestion.<\/li>\n<\/ul><p>Focusing on the application alone is like tuning a race car engine while driving on the longest road possible. In reality, latency is an end-to-end engineering problem. The most competitive trading setups treat the network and the server as a single system. By optimizing both domains together, firms can capture the last fraction of a millisecond. That can be one factor separating a missed opportunity from a profitable trade.<\/p><p>If you are mapping your own latency budget, you can check route latency in BestPath or talk to the IPTP Networks team about low latency routes and colocation.<\/p><h2>FAQ<\/h2><div class=\"faq-item\">\n<div class=\"faq-question\">\n<div>\n      <span class=\"faq-question-span\">01.<\/span> Q: What is a latency budget in trading?\n    <\/div>\n<p>    <span class=\"faq-toggle\">&ndash;<\/span>\n  <\/p><\/div>\n<div class=\"faq-answer\" style=\"display:block\">\n    <strong>A: <\/strong>A latency budget is the total time a trading round trip can take, split across every component that spends part of it. Application code, the NIC and OS stack, switches, transport gear and fiber each take a share. Thinking in budgets shows where savings are largest. Saving 2 &mu;s in code may matter far less than removing 20 km from an optical route.\n  <\/div>\n<\/div><div class=\"faq-item\">\n<div class=\"faq-question\">\n<div>\n      <span class=\"faq-question-span\">02.<\/span> Q: How much latency does fiber add per kilometer?\n    <\/div>\n<p>    <span class=\"faq-toggle\">+<\/span>\n  <\/p><\/div>\n<div class=\"faq-answer\">\n    <strong>A: <\/strong>Light in fiber travels at around 200,000 km\/s, so fiber adds roughly 5 &mu;s per kilometer one-way. That is about 500 &mu;s per 100 km and 5 ms per 1,000 km. New York to London is about 5,500 km along a subsea path, so even at the speed of light the trip takes tens of milliseconds one-way.\n  <\/div>\n<\/div><div class=\"faq-item\">\n<div class=\"faq-question\">\n<div>\n      <span class=\"faq-question-span\">03.<\/span> Q: How much latency does kernel bypass save?\n    <\/div>\n<p>    <span class=\"faq-toggle\">+<\/span>\n  <\/p><\/div>\n<div class=\"faq-answer\">\n    <strong>A: <\/strong>In a standard Linux stack, interrupts, kernel drivers, socket buffers and system calls can add 20&ndash;50 &mu;s per packet in an unloaded system. Kernel bypass techniques such as DPDK, Solarflare\/OpenOnload, Mellanox VMA or AF_XDP let the application exchange packets directly with the NIC. With kernel bypass, round-trip packet processing can drop into the 1&ndash;5 &mu;s range, and latency becomes more predictable.\n  <\/div>\n<\/div><div class=\"faq-item\">\n<div class=\"faq-question\">\n<div>\n      <span class=\"faq-question-span\">04.<\/span> Q: Does co-location eliminate trading latency?\n    <\/div>\n<p>    <span class=\"faq-toggle\">+<\/span>\n  <\/p><\/div>\n<div class=\"faq-answer\">\n    <strong>A: <\/strong>No. Colocation near or inside the exchange&rsquo;s facility replaces kilometers of fiber with meters, but switches, cables, the NIC and the exchange gateway still add delay. Nasdaq advertises that its colocation reduces round-trip latency by an average of 2&ndash;5 microseconds. Colocating in a data center far from the relevant exchange gives none of that benefit.\n  <\/div>\n<\/div><div class=\"faq-item\">\n<div class=\"faq-question\">\n<div>\n      <span class=\"faq-question-span\">05.<\/span> Q: What is the difference between jitter and latency?\n    <\/div>\n<p>    <span class=\"faq-toggle\">+<\/span>\n  <\/p><\/div>\n<div class=\"faq-answer\">\n    <strong>A: <\/strong>Latency is often quoted as an average or best-case number. Jitter is the variability of latency. In trading, jitter can be more critical than the average. A system with a consistent 30 &mu;s response is usually preferable to one that averages 20 &mu;s but occasionally spikes to 200 &mu;s. Dedicated bandwidth, QoS and fixed paths help reduce jitter.\n  <\/div>\n<\/div><div class=\"faq-item\">\n<div class=\"faq-question\">\n<div>\n      <span class=\"faq-question-span\">06.<\/span> Q: Does more bandwidth reduce latency?\n    <\/div>\n<p>    <span class=\"faq-toggle\">+<\/span>\n  <\/p><\/div>\n<div class=\"faq-answer\">\n    <strong>A: <\/strong>Not directly. Upgrading a link from 10G to 100G reduces serialization time for a full frame from 1.2 &mu;s to 0.12 &mu;s. It does not reduce propagation delay or queuing delay. If two locations are connected by a long fiber, the time to travel that fiber, about 5 &mu;s per km, is unchanged by bandwidth.\n  <\/div>\n<\/div><div class=\"faq-item\">\n<div class=\"faq-question\">\n<div>\n      <span class=\"faq-question-span\">07.<\/span> Q: How much latency does DWDM add?\n    <\/div>\n<p>    <span class=\"faq-toggle\">+<\/span>\n  <\/p><\/div>\n<div class=\"faq-answer\">\n    <strong>A: <\/strong>Optical amplifiers and ROADMs in a DWDM path add minimal delay, often nanoseconds. The main delay comes from transponders that apply Forward Error Correction. Each can add on the order of tens of microseconds, and a modern 100G optical module might introduce 10&ndash;30 &mu;s one-way. Over multiple hops or older gear, this can reach hundreds of microseconds.\n  <\/div>\n<\/div><h2 class=\"mt-5\">Sources<\/h2><ol>\n<li>IPTP Networks: About us<\/li>\n<li>IPTP Networks: Low latency routes<\/li>\n<li>IPTP Networks: Best Path tool<\/li>\n<li>IPTP Networks blog: The Complete HFT Infrastructure Solution<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>&#8230;<\/p>\n","protected":false},"author":17,"featured_media":44623,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[45],"tags":[],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/posts\/44619"}],"collection":[{"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/users\/17"}],"replies":[{"embeddable":true,"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/comments?post=44619"}],"version-history":[{"count":13,"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/posts\/44619\/revisions"}],"predecessor-version":[{"id":44633,"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/posts\/44619\/revisions\/44633"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/media\/44623"}],"wp:attachment":[{"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/media?parent=44619"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/categories?post=44619"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.iptp.net\/es_ES\/wp-json\/wp\/v2\/tags?post=44619"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}