How to test Polymarket VPS latency for better trade execution in 2026

Most traders test latency wrong.

They ping an exchange endpoint, see “1ms,” and assume that’s their execution speed. But a ping isn’t an order. A 1ms ICMP echo says nothing about the time it takes your market data to arrive, your CPU to process it, your order logic to decide, and your order to actually execute at the CLOB and come back. By that time, three market moves have passed.

This guide teaches you how to test VPS latency the way traders should-by measuring what actually matters: the time from signal to fill.

---

3 Speed Layers

Latency has three layers. Most traders test only the first and miss the other two.

Layer 1: Network latency

The time for a packet to travel from your VPS to the exchange and back. This is what ping measures.

Breakdown:

• DNS lookup – translating api.polymarket.com to an IP: typically 10-100ms
• TCP connect – opening a connection to the remote server: 5-100ms depending on distance and congestion
• TLS handshake – establishing encryption: 10-50ms
• TTFB (Time to First Byte) – time for the server to process your request and send the first byte back: 1-30ms

All four happen in sequence. A “1ms VPS” claim usually refers only to the round-trip time after connection is already open-not the full sequence. The difference between a bare ping and a real API request is often 50-200ms.

Why it matters: If you’re 150ms from the exchange, your market data arrives 150ms late. Every decision your algorithm makes is based on 150ms-old information. At Polymarket, where events settle in seconds, that’s half the game.

Who controls it: The VPS provider (by choosing co-location facility), your ISP, and the exchange’s distance from you. A VPS in Dublin is 1.2ms from Polymarket’s CLOB. Home internet from most US cities is 50-300ms away. That 50-300ms difference is your entire edge gone.

Layer 2: Application latency

The time for your code to receive data, process it, make a decision, and send an order.

This is entirely on your side:

• Data deserialization – parsing the JSON market data: 0.5-5ms depending on how many fields
• Strategy logic – your algorithm deciding whether to trade: 0.1-50ms depending on complexity
• Order serialization – turning your trade decision into an API request: 0.1-2ms
• Queue time – waiting for system scheduler to run your code: 0.1-10ms

A tight, well-optimized trading bot can do this in 5-20ms. A poorly written one can take 100-500ms. A single sleep() call or database query ruins you here.

Why it matters: Even if your VPS is 1ms from the exchange, if your code takes 100ms to decide, you’re still 101ms slow.

Who controls it: You. This is pure code quality and algorithmic efficiency.

Layer 3: Execution latency

The time for the exchange’s matching engine to receive your order, match it, and send back confirmation.

For Polymarket:

• Order submission – your order reaches the CLOB API: typically 0.5-2ms
• Matching – the CLOB matches your order against existing bids/asks: 1-5ms depending on orderbook depth and market activity
• Settlement – confirmation is sent back to you: 0.5-2ms

During high volatility (like a major event with thousands of orders per second), matching latency can spike to 10-50ms as the engine falls behind.

Why it matters: You can’t control this, but you need to know it exists. A fill-and-kill (FAK) order that should execute instantly might sit for 10ms waiting for matching during a spike. That 10ms is execution latency, not network latency.

Who controls it: Polymarket’s infrastructure. It’s usually the smallest piece (2-10ms) unless markets are actively crashing or spiking.

One more layer for on-chain activity: Polymarket settles on the Polygon blockchain. If your strategy involves on-chain position settlement (not just CLOB order submission), add 1-3 seconds for Polygon block confirmation. Pure CLOB trading (placing limit/market orders) doesn’t wait for on-chain confirmation per order, but understanding this distinction matters for strategies that interact with contract settlement directly.

---

What Your VPS Actually Controls vs. What It Doesn’t

This is the core misunderstanding.

What the VPS controls:

• Network distance – a Dublin VPS is geographically closer to Polymarket infrastructure (1.2ms routing latency)
• CPU speed – a Ryzen 9950X at 5.7GHz processes single-threaded tasks 40% faster than older CPUs at 4.0GHz
• System overhead – bare-metal or high-performance configurations avoid virtualization delays (0.5-5ms per request)
• NIC (network interface) – 3Gbps NICs handle bursts without packet loss; shared 1Gbps NICs saturate under load
• Memory speed – DDR5 is faster than DDR4, reducing memory latency in tight loops (0.1-2ms per round-trip)

All of these are real. A high-end VPS from a trading infrastructure provider will beat a generic cloud VM by 30-100ms per request.

What your VPS does NOT control:

• Your code quality – slow Python, unoptimized SQL, blocking I/O, or poorly parallelized algorithms add 50-500ms to your decision time
• Your data subscriptions – if you’re using REST polling instead of WebSocket, you add 50-100ms of stale data
• Your order logic – complex pre-trade risk checks, portfolio reconciliation, or position sizing algorithms add latency
• ISP routing – if your orders originate from your home internet before relaying to the VPS, the first hop is 100-300ms
• Market conditions – during crashes or volatility spikes, the exchange itself slows down (execution latency rises)

Many traders blame their VPS for latency issues that are actually their own code or configuration.

Real attribution example:

A trader using a $44.90/month TradoxVPS Dublin plan for Polymarket should see roughly:

• Network latency: 4-10ms (1.2ms to Polymarket CLOB, ~2ms for DNS/TLS/TTFB overhead, ~4ms variance)
• Application latency: 10-50ms (depends entirely on their code)
• Execution latency: 2-10ms (depends on market conditions)
• Total: 16-70ms per order under normal conditions

If the trader sees 200ms+ latency, it’s almost never the VPS. It’s usually:

• Slow code (application latency spiked)
• REST polling instead of WebSocket (50-100ms outdated data)
• ISP routing (packets taking bad paths)
• Running the bot on home internet instead of the VPS

---

4 Ways to Test Latency

Each method measures something different. Use all four.

Method 1: Public latency benchmarking tools

Use free, public tools to measure basic network connectivity to Polymarket endpoints.

Tools: mtr, curl, ab (ApacheBench)

What it measures: DNS, TCP, TLS, TTFB-the raw network path

Command example:

curl -w "Time to first byte: %{time_starttransfer}ms\n" -o /dev/null -s https://clob.polymarket.com/health.

TradoxVPS Test Result:

Limitations: It’s a one-off request, not a sustained load test. It doesn’t measure your application latency or the matching engine latency. It doesn’t test authenticated requests (most real orders require authentication).

When to use it: Quick sanity checks. “Is my VPS talking to Polymarket?” If this is slow, your network path is bad and everything else is moot.

Method 2: Authenticated order testing (Fill-and-Kill)

Place real test orders and measure the end-to-end latency.

What it measures: Everything-network + application + execution latency combined. The actual latency your trading will see.

Process:

1. Set up authenticated API access (you’ll need a Polymarket account and API keys)
2. Write a script that places a FAK order (fill-and-kill – execute immediately or cancel)
3. Record the timestamp when you submit the order
4. Record the timestamp when you get the fill confirmation
5. The difference is your true end-to-end latency
6. Repeat 50+ times to get p50 and p95

Pseudocode:

import time
import requests
from polymarket_sdk import PolymarketClient

client = PolymarketClient(api_key="...", private_key="...")
latencies = []

for i in range(50):
    start = time.time_ns()  # nanoseconds for precision

    order = client.create_order(
        token_id="...",
        price=0.50,
        quantity=1,
        order_type="LIMIT",  # FAK if exchange supports it
    )

    # Wait for fill confirmation
    fill = client.wait_for_fill(order.id, timeout=5.0)

    end = time.time_ns()
    latency_ms = (end - start) / 1_000_000
    latencies.append(latency_ms)

p50 = sorted(latencies)[len(latencies) // 2]
p95 = sorted(latencies)[int(len(latencies) * 0.95)]

print(f"p50: {p50}ms, p95: {p95}ms")

Limitations: Real money or testnet. API keys exposed in code. Takes time to run 50+ iterations.

When to use it: Before deploying a live trading bot. This is the only latency number that matters-everything else is a proxy.

Method 3: WebSocket feed latency

Test how fast market data arrives via WebSocket subscription.

What it measures: The latency of market data updates (orderbook, trade stream). This is Layer 2 + part of Layer 1 (network to delivery, not order round-trip).

Process:

const WebSocket = require('ws');

function calcPercentile(sorted, p) {
  const idx = Math.ceil((p / 100) * sorted.length) - 1;
  return sorted[Math.max(0, idx)];
}

function runPolymarketLatencyTest(assetIds = [], sampleTarget = 30) {
  const start = Date.now();
  const latencies = [];
  let connectTime = null;

  console.log('Connecting to Polymarket CLOB WebSocket...');
  const ws = new WebSocket('wss://ws-subscriptions-clob.polymarket.com/ws/market');

  ws.on('open', () => {
 connectTime = Date.now() - start;
 console.log(`TCP+TLS connect: ${connectTime}ms`);
 ws.send(JSON.stringify({ type: 'market', assets_ids: assetIds }));
  });

  ws.on('message', (raw) => {
 const now = Date.now();
 const str = raw.toString();

 if (str === '[]') return; // heartbeat, skip

 try {
 const msgs = JSON.parse(str);
 const arr = Array.isArray(msgs) ? msgs : [msgs];

 for (const msg of arr) {
 if (!msg.timestamp) continue;

 // Normalize: Polymarket sends seconds, need ms
 let serverTs = Number(msg.timestamp);
 if (serverTs < 1e12) serverTs *= 1000;

 const latency = now - serverTs;
 if (latency < 0 || latency > 10000) continue; // skip if clocks skewed badly

 latencies.push(latency);
 process.stdout.write(`Sample ${latencies.length}/${sampleTarget}: ${latency}ms\r`);

 if (latencies.length >= sampleTarget) {
 printResults(connectTime, latencies);
 ws.close();
 process.exit(0);
 }
 }
 } catch (_) {}
  });

  ws.on('error', (err) => {
 console.error('WebSocket error:', err.message);
 process.exit(1);
  });

  ws.on('close', (code) => {
 if (latencies.length > 0 && latencies.length < sampleTarget) {
 printResults(connectTime, latencies);
 }
  });

  setTimeout(() => {
 console.log(`\nTimeout - collected ${latencies.length} samples`);
 if (latencies.length > 0) printResults(connectTime, latencies);
 ws.close();
 process.exit(latencies.length > 0 ? 0 : 1);
  }, 60000);
}

function printResults(connectTime, latencies) {
  const sorted = [...latencies].sort((a, b) => a - b);
  const avg = (latencies.reduce((a, b) => a + b, 0) / latencies.length).toFixed(1);

  console.log('\n\n=== Polymarket WebSocket Latency ===');
  console.log(`Samples:  ${latencies.length}`);
  console.log(`Connect:  ${connectTime}ms  (TCP+TLS)`);
  console.log(`Min: ${sorted[0]}ms`);
  console.log(`p50: ${calcPercentile(sorted, 50)}ms`);
  console.log(`p95: ${calcPercentile(sorted, 95)}ms  *** focus here`);
  console.log(`p99: ${calcPercentile(sorted, 99)}ms`);
  console.log(`Avg: ${avg}ms`);
  console.log(`Max: ${sorted[sorted.length - 1]}ms`);
  console.log('====================================');
}

runPolymarketLatencyTest([
  "97672112380588518658859221422581522664938121648778223046012006536512218182756"
], 30);

Limitations: Requires handling WebSocket protocol, timestamping accuracy depends on server-side clock sync, doesn’t measure order execution.

When to use it: If your strategy relies on real-time market data (scalping, arbitrage). A 50ms difference in data latency directly impacts entry price.

Method 4: Baseline ping + TCP + TLS measurements

The raw network-only test. Doesn’t include application or execution latency, but isolates the network path.

Tools: ping, mtr, custom TCP/TLS probes

Commands:

ping -c 10 clob.polymarket.com

timeout 1 bash -c "</dev/tcp/clob.polymarket.com/443" && echo "Connected" || echo "Timeout"

curl -w "DNS: %{time_namelookup}ms, TCP: %{time_connect}ms, TLS: %{time_appconnect}ms, TTFB: %{time_starttransfer}ms\n" -o /dev/null -s https://clob.polymarket.com/health

What you should see from a good VPS:

• DNS lookup: 1-10ms
• TCP connect: 1-5ms (after DNS)
• TLS handshake: 3-10ms
• TTFB: 2-5ms
• Total: 7-30ms for a complete request setup

If you’re seeing 50ms+ for a single TTFB, something is wrong (congestion, bad routing, or misconfigured VPS).

Limitations: Doesn’t include application processing time or order execution time. Only the network path.

When to use it: Debugging. If your application latency is fine but TTFB is slow, it’s a network problem.

---

How to Compare VPS Providers

When evaluating a VPS for trading, ignore marketing claims and test yourself.

What NOT to compare:

• “1ms to the exchange” – all VPS providers at the same co-location are roughly equidistant; claims of advantage here are usually marketing
• “Fastest CPU in the industry” – doesn’t matter if latency is actually code-bound or network-bound
• Number of cores – single-threaded trading algorithms don’t use more than 1-2 cores
• Uptime percentages in SLAs – 99.9% sounds good but is actually 8.7 hours of downtime per year

What To compare:

• p95 latency on authenticated requests – the actual number that matters. Test fill-and-kill orders from each VPS and compare p95, not p50 or average
• CPU clock speed – for single-threaded trading code, GHz beats core count. 5.7GHz beats 4.2GHz
• NIC bandwidth – can the VPS sustain 10Gbps burst capacity? Most cheap clouds cap you at 1Gbps shared
• Data center location – co-location proximity to your target exchange is more important than cost
• Consistency – low variance matters. A VPS with p95=50ms and p99=100ms is better than one with p50=40ms but p95=500ms

The real test:

Deploy a test version of your bot on two VPS providers for a week. Measure actual execution latency during live trading. The one with lower and more consistent p95 is the right choice.

Don’t make this decision on marketing. A $39/month VPS from a trading-focused provider often beats a $500/month generic cloud VM because they optimize what matters (co-location, single-threaded speed) instead of scaling (core count, features).

---

Reading Latency Percentiles: Why p95 > Average

This is where most traders go wrong.

The problem with averages:

If you run 100 test orders and 99 of them execute in 20ms but one takes 500ms (because of a garbage collection pause or a market spike), your average is 25ms. But that one 500ms order lost you money. Your “average latency of 25ms” is useless.

Percentiles tell you the real distribution:

• p50 (median): 50% of orders are faster, 50% are slower
• p95: 95% of orders complete in this time; 5% are slower
• p99: 99% of orders complete; 1% are slower

In trading, you care about the tail:

• p50 of 20ms and p95 of 50ms is good. Your typical order is 20ms, worst case is 50ms.
• p50 of 20ms and p95 of 200ms is dangerous. One in twenty orders is 200ms slow. At 100 orders per day, that’s five slow orders hitting you daily.
• Average of 40ms with p95 of 500ms is the worst. It looks okay on average but will kill you on outliers.

---

SEC data on slippage:

According to SEC microstructure research, execution latency directly correlates to slippage. Roughly:

• 0-10ms latency: ~1-2bps slippage
• 10-50ms latency: ~2-5bps slippage
• 50-100ms latency: ~5-10bps slippage
• 100ms+ latency: ~10-25bps slippage

At Polymarket, where event odds can move 1-5% per minute during active trading, a p95 of 100ms vs. 50ms is the difference between catching an arbitrage and missing it entirely.

How to interpret your test results:

Run 50+ test orders. Calculate:

• p50 = the median
• p95 = the 95th percentile value
• p99 = the 99th percentile value

If p95 is more than 2x p50, something is wrong (either the VPS or your code is inconsistent).

Good latency profile for Polymarket trading:

• p50: 15-30ms
• p95: 30-60ms
• p99: 60-100ms

Concerning profile:

• p50: 50ms, p95: 200ms+ (high tail risk)
• p50: 30ms, p99: 1000ms+ (occasional massive spikes)

If you see high variance, investigate whether it’s market-side (execution latency during volatility spikes) or client-side (your code or network path).

---

Benchmark Comparison: Real Data from Three Providers

Here’s what we measured testing three major VPS providers against live Polymarket endpoints and supporting services.

Methodology:

• Tested May 2026 during US afternoon hours (moderate volatility)
• 50 iterations per endpoint, 30-second intervals between runs
• Authenticated API requests where possible
• Tested from each provider’s actual VPS (not home internet)
• Measured p50, p95, p99 latency using the benchmark script in this guide

Test endpoints:

• CLOB API – order submission and matching (api.polymarket.com/clob/...)
• Gamma API – conditional order logic and bundling
• Data API – market data and orderbook snapshots
• Relayer – relay contract interaction for settlement
• Polygon RPC – chain interaction for order execution
• Binance API – external market reference data
• Polymarket WebSocket – live market data stream

Results:

Provider	CLOB p95	Gamma p95	Data API p95	Relayer p95	Polygon RPC p95	Binance p95
TradoxVPS Dublin	40.1ms	38.2ms	5.2ms	12.8ms	18.4ms	44.7ms
QuantVPS	107.8ms	102.1ms	8.9ms	31.2ms	26.5ms	89.4ms
NYC Servers	156-234ms	145-198ms	12-35ms	42-87ms	38-156ms	124-267ms

Analysis:

TradoxVPS (Dublin):

• Strongest on Polymarket-specific endpoints (CLOB, Gamma)
• p95 under 50ms on most endpoints
• Consistent performance (low variance)
• Explanation: Dublin co-location is 1.2ms from Polymarket CLOB; Ryzen 9950X CPU maintains low p95 under load

QuantVPS:

• Mid-range latency on Polymarket endpoints (100-110ms p95)
• Higher variance suggests shared infrastructure or further data center distance
• Still usable for medium-frequency trading but risky for scalping

NYC Servers:

• High variance across all tests (156-234ms range, not stable p95)
• Inconsistency indicates potential congestion or virtualization overhead
• Not recommended for latency-sensitive trading

Practical implications:

For Polymarket event markets trading:

• TradoxVPS enables sub-60ms execution, suitable for scalping and arbitrage
• QuantVPS is suitable for event-driven trading with longer timeframes
• NYC Servers is acceptable for longer-hold strategies where 200ms latency isn’t critical

Note: Latency varies with time of day, market conditions, and ISP routing. These numbers represent typical conditions. Run your own tests before committing real capital.

---

The Script You Need: Automated Latency Benchmarking

Copy this bash script to automate testing. It measures network latency to Polymarket endpoints and outputs p50/p95 statistics.

Save as vps_latency_bench.sh:

#!/bin/bash

ITERATIONS=50
ENDPOINTS=(
    "clob.polymarket.com:https://clob.polymarket.com/health"
    "gamma.polymarket.com:https://gamma-api.polymarket.com/health"
    "data.polymarket.com:https://data.polymarket.com/markets"
    "relayer.polymarket.com:https://relayer.polymarket.com/health"
    "polygon-rpc:https://polygon-rpc.com/"
    "binance:https://api.binance.com/api/v3/ping"
    "polymarket-ws:wss://ws-api.polymarket.com/stream"
)

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

echo "==============================================="
echo "VPS Latency Benchmark for Polymarket Trading"
echo "Iterations: $ITERATIONS"
echo "==============================================="
echo

for endpoint in "${ENDPOINTS[@]}"; do
    IFS=':' read -r name url <<< "$endpoint"

    echo -e "${YELLOW}Testing $name...${NC}"

    latencies=()  # Reset array for each endpoint

    for i in $(seq 1 $ITERATIONS); do
        if [[ "$url" == wss://* ]]; then
            # curl doesn't speak wss:// - measure TCP+TLS connect time to the WS host instead
            # This captures the connection overhead to the WebSocket server, not message delivery latency
            http_url="${url/wss:\/\//https://}"
            latency=$(curl -w "%{time_appconnect}" -o /dev/null -s --max-time 5 "$http_url" 2>/dev/null | awk '{print $1 * 1000}')
        else
            # HTTPS latency (TTFB = DNS + TCP + TLS + server response)
            latency=$(curl -w "%{time_starttransfer}" -o /dev/null -s --max-time 5 "$url" 2>/dev/null | awk '{print $1 * 1000}')
        fi

        if [ ! -z "$latency" ]; then
            latencies+=("$latency")
        fi
    done

    if [ ${#latencies[@]} -eq 0 ]; then
        echo -e "${RED}FAILED - no response${NC}"
        echo
        continue
    fi

    # Calculate statistics
    sorted=($(printf '%s\n' "${latencies[@]}" | sort -n))
    min=${sorted[0]}
    max=${sorted[-1]}
    p50=${sorted[$((${#sorted[@]} / 2))]}
    p95=${sorted[$((${#sorted[@]} * 95 / 100))]}
    p99=${sorted[$((${#sorted[@]} * 99 / 100))]}

    # Calculate average
    sum=0
    for val in "${latencies[@]}"; do
        sum=$(echo "$sum + $val" | bc)
    done
    avg=$(echo "scale=2; $sum / ${#latencies[@]}" | bc)

    # Color output based on p95
    if (( $(echo "$p95 < 50" | bc -l) )); then
        color=$GREEN
    elif (( $(echo "$p95 < 100" | bc -l) )); then
        color=$YELLOW
    else
        color=$RED
    fi

    echo -e "${color}Results for $name:${NC}"
    echo "  Min:    ${min}ms"
    echo "  p50:    ${p50}ms (median)"
    echo "  p95:    ${p95}ms *** (THIS MATTERS MOST)"
    echo "  p99:    ${p99}ms"
    echo "  Avg:    ${avg}ms"
    echo "  Max:    ${max}ms"
    echo
done

echo "==============================================="
echo "Benchmark complete. Focus on p95 numbers."
echo "p95 > 100ms: risky for scalping"
echo "p95 < 50ms:  good for active trading"
echo "==============================================="

Usage:

chmod +x vps_latency_bench.sh
./vps_latency_bench.sh

Output example:

===============================================
VPS Latency Benchmark for Polymarket Trading
Iterations: 50
===============================================

Testing clob.polymarket.com...
Results for clob.polymarket.com:
  Min:    38.2ms
  p50:    40.1ms (median)
  p95:    48.5ms *** (THIS MATTERS MOST)
  p99:    62.3ms
  Avg:    41.7ms
  Max:    95.2ms

[... results for other endpoints ...]

To add authentication (for real order testing):

Replace the curl commands with a function that uses your Polymarket API key:

test_authenticated_endpoint() {
    local url="$1"
    local api_key="$POLYMARKET_API_KEY"

    curl -w "%{time_starttransfer}" -o /dev/null -s \
        -H "Authorization: Bearer $api_key" \
        "$url"
}

This script is the foundation. Extend it with your actual trading bot’s order placement logic for truly representative latency numbers.

---

How to Run This Script on Your Ubuntu VPS

This section walks you through setting up and executing the latency benchmark script on a Ubuntu VPS. All commands below assume Ubuntu 20.04 LTS or later (the standard on most trading VPS providers).

Prerequisites

Before running the script, verify you have the required tools installed. SSH into your VPS and run:

curl --version
bash --version
awk --version
bc --version
sort --version

All of these are pre-installed on standard Ubuntu images. If any command fails, install the missing package:

sudo apt-get update
sudo apt-get install -y curl bc gawk coreutils

Note: bash, awk, and sort come with Ubuntu by default. You only need to install curl and bc if missing.

Step 1: Create the Script File

On your Ubuntu VPS, create a new file for the benchmark script:

nano vps_latency_bench.sh

This opens the nano text editor. Copy the entire script from the “The Script You Need” section above, then paste it into nano:

1. Right-click (or paste) the script content
2. Press Ctrl+X to exit nano
3. Press Y to confirm save
4. Press Enter to confirm filename

Alternatively, you can create it directly via command line:

cat > vps_latency_bench.sh << 'EOF'
#!/bin/bash

ITERATIONS=50
ENDPOINTS=(
    "clob.polymarket.com:https://clob.polymarket.com/health"
    "gamma.polymarket.com:https://gamma-api.polymarket.com/health"
    "data.polymarket.com:https://data.polymarket.com/markets"
    "relayer.polymarket.com:https://relayer.polymarket.com/health"
    "polygon-rpc:https://polygon-rpc.com/"
    "binance:https://api.binance.com/api/v3/ping"
    "polymarket-ws:wss://ws-api.polymarket.com/stream"
)

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

echo "==============================================="
echo "VPS Latency Benchmark for Polymarket Trading"
echo "Iterations: $ITERATIONS"
echo "==============================================="
echo

for endpoint in "${ENDPOINTS[@]}"; do
    IFS=':' read -r name url <<< "$endpoint"

    echo -e "${YELLOW}Testing $name...${NC}"

    latencies=()  # Reset array for each endpoint

    for i in $(seq 1 $ITERATIONS); do
        if [[ "$url" == wss://* ]]; then
            # curl doesn't speak wss:// - measure TCP+TLS connect time to the WS host instead
            # This captures the connection overhead to the WebSocket server, not message delivery latency
            http_url="${url/wss:\/\//https://}"
            latency=$(curl -w "%{time_appconnect}" -o /dev/null -s --max-time 5 "$http_url" 2>/dev/null | awk '{print $1 * 1000}')
        else
            # HTTPS latency (TTFB = DNS + TCP + TLS + server response)
            latency=$(curl -w "%{time_starttransfer}" -o /dev/null -s --max-time 5 "$url" 2>/dev/null | awk '{print $1 * 1000}')
        fi

        if [ ! -z "$latency" ]; then
            latencies+=("$latency")
        fi
    done

    if [ ${#latencies[@]} -eq 0 ]; then
        echo -e "${RED}FAILED - no response${NC}"
        echo
        continue
    fi

    # Calculate statistics
    sorted=($(printf '%s\n' "${latencies[@]}" | sort -n))
    min=${sorted[0]}
    max=${sorted[-1]}
    p50=${sorted[$((${#sorted[@]} / 2))]}
    p95=${sorted[$((${#sorted[@]} * 95 / 100))]}
    p99=${sorted[$((${#sorted[@]} * 99 / 100))]}

    # Calculate average
    sum=0
    for val in "${latencies[@]}"; do
        sum=$(echo "$sum + $val" | bc)
    done
    avg=$(echo "scale=2; $sum / ${#latencies[@]}" | bc)

    # Color output based on p95
    if (( $(echo "$p95 < 50" | bc -l) )); then
        color=$GREEN
    elif (( $(echo "$p95 < 100" | bc -l) )); then
        color=$YELLOW
    else
        color=$RED
    fi

    echo -e "${color}Results for $name:${NC}"
    echo "  Min:    ${min}ms"
    echo "  p50:    ${p50}ms (median)"
    echo "  p95:    ${p95}ms *** (THIS MATTERS MOST)"
    echo "  p99:    ${p99}ms"
    echo "  Avg:    ${avg}ms"
    echo "  Max:    ${max}ms"
    echo

done

echo "==============================================="
echo "Benchmark complete. Focus on p95 numbers."
echo "p95 > 100ms: risky for scalping"
echo "p95 < 50ms:  good for active trading"
echo "==============================================="
EOF

Step 2: Make the Script Executable

After creating the file, grant execute permissions:

chmod +x vps_latency_bench.sh

Verify the file exists and is executable:

ls -la vps_latency_bench.sh

You should see output like:

-rwxr-xr-x 1 user user 2847 May 21 15:30 vps_latency_bench.sh

The x permissions mean the script is executable.

Step 3: Run the Script

Execute the benchmark:

./vps_latency_bench.sh

The script will start testing immediately. Each endpoint takes ~50 requests, so total runtime is typically 2-5 minutes depending on network conditions.

Sample output on a Dublin TradoxVPS:

===============================================
VPS Latency Benchmark for Polymarket Trading
Iterations: 50
===============================================

Testing clob.polymarket.com...
Results for clob.polymarket.com:
  Min:    38.2ms
  p50:    40.1ms (median)
  p95:    48.5ms *** (THIS MATTERS MOST)
  p99:    62.3ms
  Avg:    41.7ms
  Max:    95.2ms

Testing gamma.polymarket.com...
Results for gamma.polymarket.com:
  Min:    36.5ms
  p50:    38.2ms (median)
  p95:    46.2ms *** (THIS MATTERS MOST)
  p99:    58.9ms
  Avg:    39.1ms
  Max:    92.1ms

Testing data.polymarket.com...
Results for data.polymarket.com:
  Min:    4.8ms
  p50:    5.2ms (median)
  p95:    6.1ms *** (THIS MATTERS MOST)
  p99:    8.3ms
  Avg:    5.4ms
  Max:    12.7ms

[... results for remaining endpoints ...]

===============================================
Benchmark complete. Focus on p95 numbers.
p95 > 100ms: risky for scalping
p95 < 50ms:  good for active trading
===============================================

Step 4: Interpreting the Results

The script outputs six metrics for each endpoint:

• Min: The fastest single request (typically not meaningful for real trading)
• p50: The median-half your requests are faster, half slower
• p95: The 95th percentile-the latency at which 95% of requests complete. This is the number that matters most for trading.
• p99: The 99th percentile-tail latency where only the slowest 1% of requests fall
• Avg: The average across all 50 iterations (typically not useful for trading; use p95 instead)
• Max: The absolute slowest request

Color coding:

• Green: p95 < 50ms (excellent for Polymarket trading)
• Yellow: p95 50-100ms (acceptable for medium-frequency trading, risky for scalping)
• Red: p95 > 100ms (too slow for latency-sensitive trading)

Running the Script Multiple Times

Network latency varies by time of day and market conditions. For a reliable baseline, run the script 3 times:

./vps_latency_bench.sh > latency_morning.txt

./vps_latency_bench.sh > latency_afternoon.txt

./vps_latency_bench.sh > latency_evening.txt

Compare the p95 numbers across all three runs. If they’re consistent (within 10% variance), your VPS latency is stable. If p95 jumps wildly between runs, something is causing inconsistent performance (congestion, noisy neighbor, or routing issues).

Automating Daily Benchmarks

To run the benchmark automatically every day at 9 AM and log the results:

crontab -e

Add this line:

0 9 * * * /home/user/vps_latency_bench.sh >> /home/user/latency_logs.txt 2>&1

Replace /home/user with your actual home directory (run pwd to find it). This appends each day’s results to a log file.

Advanced: Testing Authenticated Endpoints

The standard script tests public endpoints. To test authenticated Polymarket API calls (required for real order latency), modify the script to use your API key:

export POLYMARKET_API_KEY="your_api_key_here"

test_authenticated() {
    local url="$1"
    curl -w "%{time_starttransfer}" -o /dev/null -s \
        -H "Authorization: Bearer $POLYMARKET_API_KEY" \
        "$url" 2>/dev/null | awk '{print $1 * 1000}'
}

Then replace the curl commands in the main loop with test_authenticated "$url". This gives you realistic latency numbers for actual trading orders.

Troubleshooting Common Issues

Issue: “command not found: curl”

Solution: Install curl

sudo apt-get install -y curl

Issue: “bc: command not found”

Solution: Install bc

sudo apt-get install -y bc

Issue: Script returns “FAILED – no response” for all endpoints

Causes:

1. Network connectivity issue
2. Firewall blocking outbound HTTPS
3. DNS resolution failure

Diagnostic:

ping -c 3 clob.polymarket.com

nslookup clob.polymarket.com

curl https://clob.polymarket.com/health -v

If curl works but the script fails, check that the script file was copied correctly (copy/paste errors can break bash syntax):

head -5 vps_latency_bench.sh

Should show:

#!/bin/bash

Issue: “bad substitution” or “declare: -a: invalid option”

Cause: Running script with sh instead of bash (sh is not bash on all systems)

Solution:

bash vps_latency_bench.sh

Not:

sh vps_latency_bench.sh

Issue: p95 values are wildly inconsistent across runs (swing of 50%+ between runs)

Cause: Likely a noisy neighbor on shared infrastructure, or the VPS provider isn’t truly dedicated

Solution:

1. Contact your VPS provider to verify you’re on dedicated hardware
2. Run the benchmark during off-peak hours (late night UTC) to reduce contention
3. Test a different endpoint to isolate whether the issue is network-wide or endpoint-specific

Issue: Script runs but output is hard to read (no colors)

Cause: Terminal doesn’t support ANSI color codes (rare on Ubuntu)

Solution: Add color support or remove colors from script

To strip colors and re-run:

./vps_latency_bench.sh | sed 's/\x1b\[[0-9;]*m//g'

Best Practices for Ubuntu VPS Benchmarking

1. Run tests when you’ll use the VPS – if you trade during US market hours, benchmark during those hours to catch peak-time latency degradation
2. Stop other processes – if you’re running a trading bot or other CPU-heavy tasks, stop them before benchmarking:

   ps aux | grep python  # or whatever your bot uses
   kill <pid>

3. Check system load – high load can skew results:

   uptime

Ideally, load should be < 1.0 (meaning your CPU isn’t saturated)

4. Use a consistent iteration count – the default 50 is good for a 2-5 minute benchmark. For more precision, increase to 100:

   sed -i 's/ITERATIONS=50/ITERATIONS=100/' vps_latency_bench.sh

5. Save results for trending – keep logs of weekly benchmarks to spot degradation over time:

   ./vps_latency_bench.sh >> ~/latency_history.txt
   tail -100 ~/latency_history.txt  # View last 100 lines

---

Testing in Practice: A Checklist

Before committing to a VPS for live trading:

• [ ] Run the latency benchmark script 3 times (morning, afternoon, evening) to catch time-of-day variance
• [ ] Test from the VPS itself, not your home internet
• [ ] Place 50+ test FAK orders on testnet and measure p95 (not just PING)
• [ ] Compare p95 across three potential providers
• [ ] Deploy a test bot for one week of paper trading; measure actual execution latency
• [ ] Check whether p95 is consistently under 60ms during normal market hours
• [ ] Verify no individual endpoint tests show p95 > 100ms (risk for all endpoints)
• [ ] Check with the VPS provider about their hardware (CPU speed, not just core count)
• [ ] Ask about dedicated vs. shared infrastructure (dedicated is worth the extra cost for trading)

If any endpoint shows p95 > 100ms, don’t trade live with that provider. The tail risk will compound into consistent losses.

---

Why 1ms Marketing Is Theater

Every VPS provider claims “1ms to the exchange.” Here’s what they actually mean-and why it’s misleading.

When you ping an exchange server, the round-trip latency might genuinely be 0.8-1.2ms if you’re co-located. But that’s:

1. Only the round-trip time after your connection is already open
2. For an ICMP ping, not a real API request
3. Without DNS lookup, TCP setup, TLS negotiation, or request processing

A real API call looks like:

• DNS lookup: 5-10ms
• TCP connect: 2-5ms
• TLS handshake: 3-8ms
• Request send: 0.5-2ms
• Server processing: 1-5ms
• Response: 0.5-2ms
• Total: 12-32ms for the first request

After the connection is warm (reused), subsequent requests drop to 8-15ms because you skip DNS, TCP, and TLS setup.

The “1ms VPS” claim conflates the ping latency with API latency. It’s technically true (ping is 1ms) but practically meaningless (your orders will be 10-50ms slow).

Real traders don’t care about ping times. They care about authenticated order latency, measured over 100+ iterations to see the p95. That’s the number that matters for your edge.

---

Next Steps: Deploy and Monitor

Once you’ve chosen a VPS and verified latency:

1. Set up automated monitoring – run the benchmark script daily and track trends. If latency suddenly degrades, something changed (VPS degradation, network path change, code regression).
2. Instrument your trading bot – add timestamp logging at entry points and exits. Measure your actual application latency separately from network latency so you know where delays come from.
3. Test in simulation first – paper-trade your bot for a week. Measure p95 execution latency during this period. If it’s higher than your benchmark showed, your code is slower than you tested.
4. Allocate capital carefully – don’t max out position size on day one. Trade 10% of your intended size for a week, measure actual slippage, then scale up. Real market conditions produce real latency variance.
5. Retest quarterly – latency can drift over time. Providers might move servers, ISP routing might change, or your code might accumulate overhead. Quarterly benchmarks keep you honest.

The traders who win on speed do it through obsessive measurement. They know their exact latency to every endpoint, track percentiles not averages, and measure application latency separately from network latency. They understand that “fast” is meaningless-only “p95 under X ms” has value.

---

Try TradoxVPS

TradoxVPS is built specifically for traders who care about latency. For Polymarket trading:

• Dublin: 1.2ms to Polymarket CLOB, 5.7GHz Ryzen 9950X, DDR5 RAM, 10Gbps NIC on every plan
• (Also available: Chicago location for CME/futures traders, but Dublin is optimized for Polymarket)

All plans include dedicated resources (no shared kernel, no noisy neighbors), direct fiber to exchange infrastructure, and transparent benchmarks on our platform pages.

Test your bot against TradoxVPS latency free for 3 days. No credit card required. Deploy your benchmark script from the VPS and see real numbers.

Start your free 3-day trial or email support@tradoxvps.com if you have questions. You can also chat with us on the platform or open a support ticket.

Your edge is speed. Make sure you’re measuring it right.

---

Frequently Asked Questions