VPS Latency Test: Check Broker Ping and Route Quality on Windows

Run a VPS latency test inside your hosted Windows desktop, using the endpoint your broker or data provider approves for your connection. Ninja Mobile Trader VPS specializes in hosting NinjaTrader Desktop: your platform runs on our server while you access the same workspace from your PC, Mac or phone. This test measures the server’s route to the provider, separately from your device’s Remote Desktop connection.

Our included Windows licensing and 24/7 support give you the tools and help to evaluate that route. Use the repeatable procedure below to save a baseline, investigate a change and give our team a dated record.

1. Fix the destination and test conditions#

Ask the provider for the applicable hostname, service role and permitted diagnostic method. Market data and order entry may use different endpoints; the broker’s website is not a substitute. For TCP checks, use only the provider-specified port.

Download our blank route-test worksheet (CSV). Save one copy per run. It contains field labels and instructions, not benchmark results. Record:

• VPS location and plan; run start/end with time zone.
• Approved hostname, resolved IP, service role and protocol.
• Sample count, timeout, workload and any observed symptom.

Repeat the same method during a normal baseline window, a representative busy period and a later comparable window. Thirty requests are a manageable starting sample, not a pass/fail standard. Keep the workload consistent without interrupting live strategies. A changed endpoint IP or method needs its own record.

2. Capture the ping baseline#

Open PowerShell on the VPS. Enter the approved hostname when prompted:

$brokerHost = Read-Host "Enter the provider-approved hostname"
Get-Date -Format o
ping /n 30 /w 1000 $brokerHost
Get-Date -Format o

Copy the complete output, including the destination IP and sent/received/lost summary. This uses 30 ICMP requests and a 1,000 ms reply timeout. Microsoft’s ping reference documents both options.

The summary gives minimum, maximum and average. It does not give median or p95. Use the optional raw capture below when you need those statistics; do not derive them from the summary or turn a <1 ms reply into a made-up decimal.

$targetText = Read-Host "Enter the approved endpoint IP for this run"
try { $targetIp = [System.Net.IPAddress]::Parse($targetText) }
catch { throw 'Enter an approved numeric IP address; no probes were sent.' }
$probe = New-Object System.Net.NetworkInformation.Ping
$samples = @(for ($i = 1; $i -le 30; $i++) {
    $timestamp = [DateTimeOffset]::Now.ToString("o")
    $replyMs = $null
    try {
        $reply = $probe.Send($targetIp, 1000)
        $status = $reply.Status.ToString()
        if ($status -eq "Success") { $replyMs = $reply.RoundtripTime }
    } catch {
        $status = "ProbeError"
    }
    [pscustomobject]@{
        Time = $timestamp
        Destination = $targetIp.ToString()
        Status = $status
        ReplyMs = $replyMs
    }
    if ($i -lt 30) { Start-Sleep -Milliseconds 1000 }
})
$probe.Dispose()
$desktop = [Environment]::GetFolderPath("Desktop")
$file = Join-Path $desktop ("nmt-ping-" + (Get-Date -Format "yyyyMMdd-HHmmss") + ".csv")
$samples | Export-Csv -LiteralPath $file -NoTypeInformation -NoClobber -ErrorAction Stop
"Saved: $file"
$samples | Group-Object Status | Select-Object Name, Count

3. Compare typical delay, tail delay and missing replies#

Use the worksheet to compare individual runs before combining anything. Keep failed attempts visible alongside latency statistics.

A small p95 sample describes that short window only. With no successful replies, latency statistics are unavailable, not zero. ICMP non-replies can reflect filtering or rate limiting, so they are not automatically the loss rate of NinjaTrader’s trading connection. Repeat the same conditions and look for changes that coincide with the actual symptom.

For the location decision behind these measurements, use our CME and Chicago route guide. For a broader plan evaluation, use the trading VPS review checklist.

4. Check the route or TCP service when needed#

To capture the path, reuse the approved destination from your test record:

$traceTarget = Read-Host "Enter the recorded endpoint IP"
tracert /d $traceTarget

Each row reports round trips from the VPS to that hop. Do not add the rows together. An asterisk means no reply arrived within the wait; a silent intermediate router alone does not prove a broken route. See Microsoft’s tracert documentation.

For a provider-approved TCP service, run:

$brokerHost = Read-Host "Enter the provider-approved hostname"
if ([string]::IsNullOrWhiteSpace($brokerHost)) { throw "Enter the approved hostname." }
$portText = Read-Host "Enter its approved TCP port"
$brokerPort = 0
if (-not [int]::TryParse($portText, [ref]$brokerPort) -or $brokerPort -lt 1 -or $brokerPort -gt 65535) {
    throw "Enter the approved whole-number TCP port (1-65535)."
}
Test-NetConnection -ComputerName $brokerHost -Port $brokerPort -InformationLevel Detailed

Save RemoteAddress, RemotePort and TcpTestSucceeded. A successful test establishes TCP reachability, not account authentication or order execution. Any ping RTT shown is a separate ICMP result, not TCP handshake timing. Microsoft documents the diagnostic fields.

Put the record to work with NMT#

Attach the worksheet and raw output to an NMT support conversation, with the incident time and exact symptom. Keep credentials and account numbers out of the worksheet. For dropped feeds or stopped strategies, use our NinjaTrader troubleshooting guide. We recommend our partner Ninja Watchdog for automatic reconnection of supported NinjaTrader connections; recovery still requires the provider to be available.

Ping measures a network round trip; it does not measure fills, slippage or complete order execution. Use the evidence to assess the connection your hosted platform actually needs.